Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bu makale, Sql Server'da Always On kullanılabilirlik gruplarıyla (AG) çalışmak üzere Reporting Services'i yapılandırma hakkında bilgi içerir. Reporting Services ve Always On kullanılabilirlik gruplarını kullanmaya yönelik üç senaryo, rapor veri kaynaklarına, rapor sunucusu veritabanlarına ve rapor tasarımına yönelik veritabanlarıdır. Desteklenen işlevsellik ve gerekli yapılandırma üç senaryo için farklıdır.
Always On kullanılabilirlik gruplarını Reporting Services veri kaynaklarıyla kullanmanın temel avantajlarından biri, okunabilir ikincil çoğaltmaları raporlama veri kaynağı olarak kullanırken, ikincil çoğaltmaların da birincil veritabanı için yük devretme sağlamasıdır.
Daima Açık yüksek kullanılabilirlik grupları hakkında genel bilgi için, SQL Server 2012 için Daima Açık Sıkça Sorulan Sorular (../../../sql-server/index.yml) bölümüne bakın.
Reporting Services ve Always On Kullanılabilirlik Gruplarını kullanma gereksinimleri
SQL Server Reporting Services ve Power BI Rapor Sunucusu .NET framework 4.0'ı kullanır ve Veri kaynaklarıyla kullanılmak üzere Always On kullanılabilirlik grupları bağlantı dizesi özelliklerini destekler.
Always On kullanılabilirlik gruplarını Reporting Services 2014 ve önceki sürümlerle kullanmak için .NET 3.5 SP1 için bir düzeltme indirip yüklemeniz gerekir. Düzeltme, AG özellikleri için SQL İstemcisi'ne destek ve ApplicationIntent ve MultiSubnetFailover bağlantı dizesi özellikleri desteği ekler. Bir rapor sunucusunu barındıran her bilgisayarda Düzeltme yüklü değilse, raporları önizlemeye çalışan kullanıcılar aşağıdakine benzer bir hata iletisi görür ve hata iletisi rapor sunucusu izleme günlüğüne yazılır:
Hata mesajı: "Anahtar sözcük 'applicationintent' desteklenmiyor"
İleti, Reporting Services bağlantı dizesine Always On kullanılabilirlik grupları özelliklerinden birini eklediğinizde oluşur, ancak sunucu özelliği tanımaz. Raporlama Hizmetleri kullanıcı arabirimlerinde 'Bağlantıyı Sına' düğmesini seçtiğinizde ve rapor sunucularında uzak hatalar etkinleştirildiyse raporun önizlemesini gördüğünüzde, not edilen hata iletisi görüntülenir.
Gerekli düzeltme hakkında daha fazla bilgi için bkz. KB 2654347A düzeltmesi, SQL Server 2012'den .NET Framework 3.5 SP1'e Always On özellikleri için destek sunar.
Diğer Always On kullanılabilirlik grupları gereksinimleri hakkında bilgi için bkz. Always On Kullanılabilirlik Grupları (SQL Server) için Önkoşullar, Kısıtlamalar ve Öneriler.
Uyarı
RSreportserver.config gibi Reporting Services yapılandırma dosyaları Always On kullanılabilirlik grupları işlevselliğinin bir parçası olarak desteklenmez. Rapor sunucularından birinde yapılandırma dosyasında el ile değişiklik yaparsanız, çoğaltmaları el ile güncelleştirmeniz gerekir.
Rapor Veri Kaynakları ve Kullanılabilirlik Grupları
Always On kullanılabilirlik gruplarını temel alan Reporting Services veri kaynaklarının davranışı, yöneticinizin AG ortamını nasıl yapılandırdığına bağlı olarak değişebilir.
Rapor veri kaynakları için Always On kullanılabilirlik gruplarını kullanmak için rapor veri kaynağı bağlantı dizesini yapılandırmanız gereken kullanılabilirlik grubu Dinleyici DNS adını kullanmaktır. Desteklenen veri kaynakları şunlardır:
SQL Yerel İstemcisi'nin kullanıldığı ODBC veri kaynağı.
RAPOR sunucusuna .NET düzeltmesi uygulanmış SQL İstemcisi.
Bağlantı dizesi, rapor sorgu isteklerini salt okunur raporlama için ikincil çoğaltma kullanacak şekilde yapılandıran yeni Always On bağlantı özelliklerini de içerebilir. Raporlama talepleri için ikincil replikayı kullanmak, okuma-yazma birincil replikasının yükünü azaltır. Aşağıdaki çizimde, Reporting Services veri kaynağı bağlantı dizelerinin ApplicationIntent=ReadOnly ile yapılandırıldığı üç çoğaltma AG yapılandırması örneği verilmiştir. Bu örnekte, rapor sorgusu istekleri birincil çoğaltma yerine ikincil çoğaltmaya gönderilir.
Aşağıda, çoğaltmalar oluşturulduğunda yapılandırılan Dinleyici DNS Adı olan [AvailabilityGroupListenerName] adlı örnek bağlantı dizesi verilmiştir:
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly
Reporting Services kullanıcı arabirimlerindeki Bağlantıyı Sına düğmesi, bağlantı kurup kurulamadığını doğrular ancak AG yapılandırmasını doğrulamaz. Örneğin, AG'nin parçası olmayan bir sunucuya bir bağlantı dizesine ApplicationIntent eklerseniz, ek parametre yoksayılır ve Bağlantıyı Sına düğmesi yalnızca belirtilen sunucuya bağlantı kurulabildiğini doğrular.
Raporlarınızın nasıl oluşturulduğuna ve yayımlandığına bağlı olarak, bağlantı dizesini nerede düzenleyeceğiniz belirlenir:
Yerel mod: Yerel mod rapor sunucusunda zaten yayımlanmış olan paylaşılan veri kaynakları ve raporlar için web portalını kullanın.
SharePoint Modu: Zaten bir SharePoint sunucusunda yayımlanmış olan raporlar için belge kitaplıkları içindeki SharePoint yapılandırma sayfalarını kullanın.
Rapor Tasarımı: Yeni raporlar oluştururken Rapor Oluşturucusu veya SQL Server Veri Araçları (SSDT). Bu makaledeki 'Rapor Tasarımı' bölümüne veya daha fazla bilgiye bakın.
Ek Kaynaklar:
Kullanılabilir bağlantı dizesi özellikleri hakkında daha fazla bilgi için bkz. SQL Server Yerel İstemcisi ile Bağlantı Dizesi Anahtar Sözcüklerini Kullanma.
Kullanılabilirlik grubu dinleyicileri hakkında daha fazla bilgi için bkz. Kullanılabilirlik Grubu Dinleyicisi (SQL Server) oluşturma veya yapılandırma.
Husus -lar: İkincil çoğaltmalar genellikle birincil çoğaltmadan veri değişikliklerini almada gecikme yaşar. Aşağıdaki faktörler birincil ve ikincil çoğaltmalar arasındaki güncelleştirme gecikmesini etkileyebilir:
İkincil çoğaltmaların sayısı. Yapılandırmaya eklenen her ikincil kopyayla birlikte gecikme artar.
Birincil ve ikincil çoğaltmalar arasındaki coğrafi konum ve uzaklık. Örneğin, ikincil çoğaltmalar birincil çoğaltmayla aynı binada değil, farklı bir veri merkezindeyse gecikme genellikle daha fazla olur.
Her bir replica için erişilebilirlik modunun yapılandırılması. Kullanılabilirlik modu, birincil çoğaltmanın, ikincil çoğaltma işlemi diske yazana kadar veritabanındaki işlemleri işlemeyi bekleyip beklemediğini belirler. Daha fazla bilgi için AlwaysOn Kullanılabilirlik Gruplarına (SQL Server) Genel Bakış'ın 'Kullanılabilirlik Modları' bölümüne bakın.
Reporting Services veri kaynağı olarak salt okunur bir ikincil kullanırken, veri güncelleştirme gecikmesinin rapor kullanıcılarının gereksinimlerini karşıladığından emin olmak önemlidir.
Rapor Tasarımı ve Kullanılabilirlik Grupları
Rapor Oluşturucusu'nda veya SQL Server Veri Araçları'nda (SSDT) bir rapor projesi tasarlarken, kullanıcı bir rapor veri kaynağı bağlantı dizesini Always On kullanılabilirlik grupları tarafından sağlanan yeni bağlantı özelliklerini içerecek şekilde yapılandırabilir. Yeni bağlantı özellikleri için destek, kullanıcının raporu nerede ön izlemesine bağlıdır.
Yerel önizleme: Rapor Oluşturucusu ve SQL Server Veri Araçları (SSDT), .NET framework 4.0'ı kullanır ve Always On kullanılabilirlik grupları bağlantı dizesi özelliklerini destekler.
Uzak veya sunucu modu önizlemesi: Raporları rapor sunucusuna yayımladıktan veya Rapor Oluşturucusu'nda önizlemeyi kullandıktan sonra aşağıdakine benzer bir hata görürseniz, bu rapor sunucusunda raporların önizlemesini yaptığınıza ve Her Zaman Açık kullanılabilirlik grupları için .NET Framework 3.5 SP1 Düzeltmesi'nin rapor sunucusuna yüklenmediğinin göstergesidir.
Hata mesajı: "Anahtar sözcük 'applicationintent' desteklenmiyor"
Rapor Sunucusu Veritabanları ve Kullanılabilirlik Grupları
Reporting Services ve Power BI Rapor Sunucusu, rapor sunucusu veritabanlarıyla Always On kullanılabilirlik gruplarını kullanmak için sınırlı destek sunar. Rapor sunucusu veritabanları AG'de bir kopyanın parçası olacak şekilde yapılandırılabilir; ancak bir yük devretme gerçekleştiğinde Reporting Services, rapor sunucusu veritabanları için otomatik olarak farklı bir kopya kullanmaz. Rapor sunucusu veritabanlarıyla MultiSubnetFailover kullanımı desteklenmez.
Yük devretme ve kurtarma işlemlerini tamamlamak için manuel işlemler veya özel otomasyon betikleri kullanılmalıdır. Bu eylemler tamamlanana kadar, Her Zaman Açık kullanılabilirlik grupları yük devretme işleminden sonra rapor sunucusunun bazı özellikleri düzgün çalışmayabilir.
Uyarı
Rapor sunucusu veritabanları için yük devretme ve olağanüstü durum kurtarma planlarken, her zaman rapor sunucusu şifreleme anahtarının bir kopyasını yedeklemeniz tavsiye edilir.
SharePoint Yerel Modu arasındaki farklar
Bu bölümde, SharePoint modu ile Yerel mod rapor sunucularının Always On kullanılabilirlik gruplarıyla etkileşim kurma şekli arasındaki farklar özetleniyor.
SharePoint rapor sunucusu, oluşturduğunuz her Reporting Services hizmet uygulaması için 3 veritabanı oluşturur. SharePoint modunda rapor sunucusu veritabanlarına bağlantı, hizmet uygulamasını oluşturduğunuzda SharePoint Yönetim Merkezi'nde yapılandırılır. Veritabanlarının varsayılan adları, hizmet uygulamasıyla ilişkili bir GUID içerir. SharePoint modu rapor sunucusu için örnek veritabanı adları aşağıda verilmiştir:
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
Yerel mod rapor sunucuları 2 veritabanı kullanır. Yerel mod rapor sunucusu için örnek veritabanı adları aşağıda verilmişti:
Rapor Sunucusu
ReportServerTempDB
Uyarı
Raporlama Hizmetleri'ni bir kullanılabilirlik grubuyla (AG) çalışacak şekilde yapılandırdığınızda, ReportServerTemp veritabanının kurtarma modeli Tam olarak değişir. Sonuç olarak, veritabanının boyutunun ReportServerTemp artmaya devam ettiği senaryolar vardır. Veritabanını AG yapılandırmanızdan kaldırmak ReportServerTemp ve kurtarma modelinin Basit olarak ayarlanması en iyi yöntemdir. Veritabanı ReportServerTemp yalnızca geçici verileri depolar. AG'den kaldırılması, Reporting Services'i etkilemez.
Yerel mod Uyarı veritabanlarını ve ilgili özellikleri desteklemez veya kullanmaz. Yerel mod rapor sunucularını Reporting Services Configuration Manager'da yapılandırabilirsiniz. SharePoint modu için, hizmet uygulaması veritabanı adını SharePoint yapılandırmasının bir parçası olarak oluşturduğunuz "istemci erişim noktasının" adı olacak şekilde yapılandırabilirsiniz. SharePoint'i Always On kullanılabilirlik gruplarıyla yapılandırma hakkında daha fazla bilgi için bkz. SharePoint Server için SQL Server kullanılabilirlik gruplarını yapılandırma ve yönetme (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).
Uyarı
SharePoint modu rapor sunucuları, Reporting Services hizmet uygulaması veritabanları ile SharePoint içerik veritabanları arasında bir eşitleme işlemi kullanır. Rapor sunucusu veritabanlarını ve içerik veritabanlarını birlikte tutmak önemlidir. Bunları, yük devretme ve küme olarak kurtarma sağlamak için aynı kullanılabilirlik gruplarında bir set olarak yapılandırmanız önerilir. Aşağıdaki senaryoyu göz önünde bulundurun:
- Rapor sunucusu veritabanının aldığı son güncelleştirmelerin aynısını almamış içerik veritabanının bir kopyasına geri yükler veya yük devretme yaparsınız.
- Reporting Services eşitleme işlemi, içerik veritabanındaki öğe listesi ile rapor sunucusu veritabanları arasındaki farkları algılar.
- Eşitleme işlemi içerik veritabanındaki öğeleri siler veya güncelleştirir.
Rapor Sunucusu Veritabanlarını Kullanılabilirlik Grupları için Hazırlama
Rapor sunucusu veritabanlarını hazırlamanın ve Always On kullanılabilirlik gruplarına eklemenin temel adımları aşağıdadır:
Kullanılabilirlik Grubunuzu oluşturun ve bir Dinleyici DNS adı yapılandırın.
Birincil Çoğaltma: Rapor sunucusu veritabanlarını tek bir kullanılabilirlik grubunun parçası olacak şekilde yapılandırın ve tüm rapor sunucusu veritabanlarını içeren bir birincil çoğaltma oluşturun.
İkincil Çoğaltmalar: Bir veya daha fazla ikincil çoğaltma oluşturun. Veritabanlarını birincil çoğaltmadan ikincil çoğaltmalara kopyalamanın yaygın yaklaşımı, veritabanlarını 'NORECOVERY ile GERI YÜKLE' kullanarak her ikincil çoğaltmaya geri yüklemektir. İkincil çoğaltmalar oluşturma ve veri eşitlemenin çalıştığını doğrulama hakkında daha fazla bilgi için bkz. Her Zaman Açık İkincil Veritabanında (SQL Server) Veri Taşımayı Başlatma.
Rapor Sunucusu Kimlik Bilgileri: Birincil çoğaltmada oluşturduğunuz ikincil çoğaltmalarda uygun rapor sunucusu kimlik bilgilerini oluşturmanız gerekir. Tam adımlar, Reporting Services ortamınızda kullandığınız kimlik doğrulaması türüne bağlıdır; Windows Reporting Services hizmet hesabı, Windows kullanıcı hesabı veya SQL Server kimlik doğrulaması. Daha fazla bilgi için bkz. Rapor Sunucusu Veritabanı Bağlantısı Yapılandırma (SSRS Configuration Manager)
Veritabanı bağlantısını Dinleyici DNS Adı'nı kullanacak şekilde güncelleştirin. yerel mod rapor sunucuları için Reporting Services yapılandırma yöneticisinde Rapor Sunucusu Veritabanı Adı'nı değiştirin. SharePoint modu için Reporting Services hizmet uygulamalarının Veritabanı sunucu adını değiştirin.
Rapor Sunucusu Veritabanlarında olağanüstü durum kurtarmayı tamamlama adımları
Always On kullanılabilirlik gruplarının ikincil çoğaltmaya yük devretmesi sonrasında aşağıdaki adımların tamamlanması gerekir:
Reporting Services veritabanlarını barındıran birincil veritabanı altyapısı tarafından kullanılan SQL Aracısı hizmetinin örneğini durdurun.
Yeni birincil çoğaltma olan bilgisayarda SQL Aracısı hizmetini başlatın.
Rapor Sunucusu hizmetini durdurun.
Rapor sunucusu yerel moddaysa Raporlama Hizmetleri yapılandırma yöneticisini kullanarak rapor sunucusu Windows sunucusunu durdurun.
Rapor sunucusu SharePoint modu için yapılandırılmışsa, SharePoint Yönetim Merkezi'nde Reporting Services paylaşılan hizmetini durdurun.
Rapor sunucusu hizmetini veya Reporting Services SharePoint hizmetini başlatın.
Raporların yeni birincil çoğaltmaya karşı çalışabildiğini doğrulayın.
Yük Devretme Gerçekleştiğinde Rapor Sunucusu Davranışı
Rapor sunucusu veritabanları yük devretmesi gerçekleştiğinde ve rapor sunucusu ortamını yeni birincil replikayı kullanacak şekilde güncelleştirdiğinizde, yük devretme ve kurtarma işleminden kaynaklanan bazı işlem sorunları vardır. Bu sorunların etkisi, yük devretme sırasında Reporting Services yüküne ve Always On kullanılabilirlik gruplarının ikincil çoğaltmaya yük devretmesi ve rapor sunucusu yöneticisinin raporlama ortamını yeni birincil çoğaltmayı kullanacak şekilde güncelleştirme süresine bağlı olarak değişir.
Arka plan işlemenin yürütülmesi, yeniden deneme mantığı ve rapor sunucusunun zamanlanmış çalışmayı yük devretme süresi boyunca tamamlandı olarak işaretleyemeyebilir olması nedeniyle birden çok kez gerçekleşebilir.
SQL Server Aracısı rapor sunucusu veritabanına veri yazamayacağından ve bu veriler yeni birincil çoğaltmayla eşitlenmeyeceğinden, genellikle yük devretme sırasında çalıştırılması tetiklenen arka plan işlem yürütmesi gerçekleşmeyecektir.
Veritabanı yük devretmesi tamamlandıktan ve rapor sunucusu hizmeti yeniden başlatıldıktan sonra SQL Server Agent işleri otomatik olarak yeniden oluşturulur. SQL Server Ajan işleri yeniden oluşturulana kadar, SQL Server Ajan işleri ile ilişkili arka plan yürütmeleri işlenmeyecektir. Bu, Reporting Services aboneliklerini, zamanlamalarını ve anlık görüntülerini içerir.
Ayrıca bakınız
- Yüksek Kullanılabilirlik, Olağanüstü Durum Kurtarma için SQL Server Yerel İstemci Desteği
- Always On Kullanılabilirlik Grupları (SQL Server)
- AlwaysOn Kullanılabilirlik Grupları ile Çalışmaya Başlama (SQL Server)
- SQL Server Yerel İstemcisi ile Bağlantı Dizesi Anahtar Sözcüklerini Kullanma
- Yüksek Kullanılabilirlik, Olağanüstü Durum Kurtarma için SQL Server Yerel İstemci Desteği
- Erişilebilirlik Replikalarına İstemcinin Bağlantı Erişimi (SQL Server) Hakkında