SQL Server - raporlar için ayrı bir veritabanı?

SQL Server'ımızda, web uygulamalarımızın her biri için bir veritabanımız var. Raporlar için Reporting Services'ı kullanırız ve tüm rapor verileri (rapor parametreleri dahil) saklı yordamlardan gelir.

Saklı yordamlar, rapordaki verilerle aynı veritabanındadır. Bu nedenle, örneğin, Stok raporlarına hizmet eden prokslar Stok veritabanındadır. Bazı raporlar birden fazla veritabanından bilgi gösterir ve daha sonra proc bu kaynak veritabanlarından birinde olacaktır. Rapor parametreleri, verilerini mağazalar, çalışanlar vb. Verileri bulunan bir Enterprise veritabanındaki procs'tan alır.

Bu, tüm raporların en azından Enterprise veritabanına ve başka bir veritabanına başka bir bağlantıya ve bazen bundan daha fazlasına sahip olduğu anlamına gelir.

Sorum şu: raporlama süreçlerini ayrı bir "Raporlar" veritabanına taşımanın bir yararı var mı ? Raporları başka bir sunucuya taşımanın faydalarını biliyorum ve bundan bahsetmiyorum - bu aynı sunucuda olacaktır.

Bunu etkileyebilecek şeyler şunlardır:

• Bir rapor için birden fazla veritabanı bağlantısına sahip olmak raporun hızını etkiler mi?
• Raporlama işleminin verilerden ayrı bir veritabanında bulunması dizinlenmiş görünümleri kullanmamızı engeller mi?
• Raporları ayrı bir veritabanında yönetmenin daha kolay / zor olduğunu mu buldunuz?

Lütfen ne düşündüğünü bilmeme izin ver.

Cevap: evet, bunu yapmanın bir yararı var. Operasyonel veritabanındaki raporlar çok fazla kaynak kullanacak ve operasyonel sistemin performansını etkileyecektir. Veritabanı performansının mekanik kısıtlamalara tabi olduğunu unutmayın (doğru sektörün başın altında görünmesini beklerken ileri geri hareket eden disk kafaları ve dönme gecikmesi). Bir raporlama stratejisi için iki geniş seçeneğiniz vardır:

1. Veritabanınızı başka bir sunucuya çoğaltın ve raporlama zincirlerini üzerine taşıyın. Raporlar çoğaltılmış sunucudan çalıştırılır. Bu en az çabadır ve mevcut raporlarınızı ve saklı prosedürlerinizi yeniden kullanabilir.
2. Üretim sistemlerinizdeki verileri birleştiren ve bunları raporlama için daha kolay bir forma dönüştüren bir Veri Ambarı oluşturun . 'Dün işin kapanması' nedeniyle anlık olarak alınabilecek çok sayıda geçici istatistik raporunuz varsa, veri ambarı daha iyi bir yaklaşım olabilir.

Bence bu, koştuğunuz SP türüne bağlıdır. Eğer ağırlarsa ve veritabanı sunucusunda çalışan diğer şeyleri etkileyebilselerdi onları hareket ettirirdim. Aksi takdirde, bakımı ve takibini yapmak daha kolay olursa, aslında rapor ettikleri veritabanına yakın tutmaya çalışırım. Sadece gerçek veritabanına yakın rapor olması da performansı etkileyebilir, ancak standart bir kurulum ve sanırım küçük bir fark olacağını çok büyük miktarda veri taşıma değil sanırım.

Ben de buldum bu makaleyi de yararlı .

Saklı yordamlar çeşitli nedenlerle başka bir veritabanına taşınmasını öneriyoruz. Geliştirme perspektifinden, her değişiklik yapmak istediğinizde iki veritabanını yeniden oluşturmanız gerekir. Sonuç olarak, şemayı "veri" veritabanından ve ikincisinden saklı yordamları üretim sürümleriyle nasıl senkronize edeceksiniz. Olağanüstü durum kurtarma ve yedekleme / geri yükleme ile ilgili olarak, şimdi sadece sisteminizi çalıştırmak ve çalıştırmak için 2 veritabanının geri yüklenmesi ile ilgilenmelisiniz.

Test yaparken de karmaşıklıklar eklediniz. İzinler, sürümler, vb. İle ilgili olarak daha fazla başarısızlığa sahip olacaksınız. Artık veritabanlarında farklı girişimler üzerinde çalışan 1'den fazla kişi varsa, çabaları koordine etmek için daha fazla zaman harcıyorsunuz. Şimdi saat 3'te olduğunu düşünün, sistem kapalıdır ve tüm veritabanlarındaki izinleri araştırmanız ve geliştirme sırasında hiç kimsenin yanlış veritabanında bir işlev veya prosedür bırakmadığından emin olmanız gerekir.

İki veritabanı kullanmanızı tavsiye ederim.

'Canlı' bir veritabanından rapor türetmek performans sorunlarına neden olur.

Ayrıca, raporlama veritabanı öncelikle aramalar için olduğundan, daha iyi performans için buradaki dizinleri özelleştirebilirsiniz. (Canlı veritabanı, belirli dizinlerden olumsuz etkilenecek eklentilere sahip olacaktır)

Başka bir yaklaşım, raporlama tablolarını ayrı şemaya ve ayrı dosya grubuna taşımaktır. Raporlama dosya grubundaki dosyalar veri sabit disklerinden uzağa taşınabilir. Bu, yönetim, gelecekteki geliştirme ve erişim yönetimi için çok daha kolay bir şekilde dikiş yapar.