SQL Server Tasarımında Dikkat Edilmesi Gerekenler

Makale
10/31/2024

System Center Operations Manager işletimsel, veri ambarı ve ACS denetim veritabanlarını desteklemek için Microsoft SQL Server'a dayanır. Bu veritabanları önemlidir ve yönetim grubunuzdaki ilk yönetim sunucusunun veya ACS toplayıcısının dağıtımı sırasında oluşturulur.

Operations Manager'ın laboratuvar ortamında veya küçük ölçekli dağıtımında, SQL Server yönetim grubundaki ilk yönetim sunucusunda birlikte bulunabilir.

Orta ölçekli ve kurumsal ölçekli dağıtılmış dağıtımda, SQL Server örneği ayrılmış bir tek başına sunucuda veya SQL Server yüksek kullanılabilirlik yapılandırmasında bulunmalıdır. Her iki durumda da, ilk yönetim sunucusunun veya ACS toplayıcısının yüklenmesine başlamadan önce SQL Server'ın zaten mevcut olması ve erişilebilir olması gerekir.

G/Ç ve diğer donanım kaynağı kısıtlamalarıyla ilgili olası sorunları önlemek için başka uygulama veritabanlarına sahip bir SQL Örneğinden Operations Manager veritabanlarının kullanılması önerilmez.

Önemli

Operations Manager, Azure SQL Yönetilen Örneği veya Amazon relational Database Service (AWS RDS) gibi ürünler de dahil olmak üzere SQL'in Hizmet Olarak Platform (PaaS) örneklerini desteklemez. Lütfen Windows makinesinde yüklü bir SQL Server örneği kullanın. Bunun tek istisnası, Azure SQL MI kullanan ve yeniden yapılandırılamayan Azure İzleyici SCOM Yönetilen Örneği'dir.

SQL Server gereksinimleri

Aşağıdaki SQL Server Enterprise &Standard Sürümü sürümleri, Reporting Server, Operational, Data Warehouse ve ACS veritabanını barındırmak için system center operations manager sürümünün mevcut yüklemesi için desteklenir:

En düşük Toplu Güncelleştirme 8 (CU8) veya sonraki bir güncelleştirmeye sahip SQL Server 2019 burada kullanılabilir
SQL Server 2016 ve burada sunulan en son güncelleştirmeler

En düşük Toplu Güncelleştirme 11 (CU11) veya sonraki bir güncelleştirme ile SQL Server 2022 burada kullanılabilir
En düşük Toplu Güncelleştirme 8 (CU8) veya sonraki bir güncelleştirmeye sahip SQL Server 2019 burada kullanılabilir
Sql Server 2017 ve burada sağlanan en son güncelleştirme

SQL Server'ı yükseltmeden önce bkz . 2017+ için yükseltme bilgileri ve SQL 2019 yükseltme bilgileri.

Aşağıdaki SQL Server Enterprise &Standard Sürümü sürümleri, Reporting Server, Operasyonel, Veri Ambarı ve ACS veritabanını barındırmak için System Center 2016 - Operations Manager'ın yeni veya mevcut bir yüklemesi için desteklenir:

SQL Server 2016 ve burada sunulan en son güncelleştirmeler
SQL Server 2014 ve burada sunulan en son güncelleştirmeler
SQL Server 2012 ve burada sunulan en son güncelleştirmeler

SQL Server sürücüleri

Ole DB ve ODBC SQL Server Sürücülerinin tüm yönetim sunucularına ve web konsolu sunucusuna yüklenmesi gerekir çünkü bu bileşenler veritabanlarıyla doğrudan arabirim oluşturur ve bu sürücüler SQL'e API düzeyinde erişim sağlar.

Operations Manager ile kullanmak için önerilen sürümler şunlardır:

Microsoft ODBC Sürücüsü sürüm 17.10.6.
Microsoft OLE DB Sürücüsü sürüm 18.7.4.

Şifrelenmiş bir SQL Server bağlantısı kullanıyorsanız, bunun yerine sürücünün en son sürümlerini yüklemeniz gerekir:

Microsoft OLE DB Sürücüsü en son sürümü.
Microsoft ODBC Sürücüsü en son sürümü.

SQL bağlantı şifrelemesini yapılandırma hakkında daha fazla bilgiyi burada bulabilirsiniz: BAĞLANTıLARı şifrelemek için SQL Server Veritabanı Altyapısı'nı yapılandırma

SQL Server güncelleştirmeleri

Operations Manager altyapısını destekleyen aşağıdaki SQL Server bileşenlerinin her birinin aynı SQL Server ana sürümünde olması gerekir:

Aşağıdakiler dahil olmak üzere Operations Manager veritabanlarından herhangi birini barındıran SQL Server veritabanı altyapısı örnekleri:
- OperationManager
- OperationManagerDW
- SSRS veritabanları ReportServer ve ReportServerTempDB
SQL Server Reporting Services (SSRS) örneği.

SQL Server kimlik doğrulama modu

Varsayılan olarak, SQL Karma Mod kimlik doğrulaması yapılandırmasında çalışır. Ancak Operations Manager, SQL Server ile iletişim kurmak için yalnızca Windows kimlik doğrulamasını kullanır. Varsayılan olarak bırakılırsa, rolü yerel hesap db_owner yoksa SQL Karma Mod Kimlik Doğrulaması ayarı çalışmaya devam eder. Rolü olan yerel hesapların db_owner Operations Manager ile ilgili sorunlara neden olduğu bilinmektedir.

Ürünü yüklemeden önce rolü tüm yerel hesaplardan kaldırmanız db_owner ve yüklemeden sonra bu rolü yerel hesaplara eklememek db_owner kesinlikle önerilir.

Dikkat edilecek diğer noktalar

Tasarım planlamanızda diğer donanım ve yazılım konuları geçerlidir:

SQL disklerinin NTFS dosya biçiminde olması önerilir.
İşletimsel ve veri ambarı veritabanı için en az 1 GB boş disk alanınız olmalıdır; bu, veritabanı oluşturulurken zorlanır. Kurulumdan sonra veritabanlarının disk kullanımının önemli ölçüde büyüyeceğini unutmayın, bu temel gereksinimin üzerinde bol miktarda boş disk alanı olduğundan emin olun.
.NET Framework 4 gereklidir.
.NET Framework 4.8, Operations Manager 2022'de desteklenir.
Raporlama Sunucusu, Windows Server Core'da desteklenmez.
SQL Server harmanlama ayarı, SQL Server harmanlama ayarı bölümünde açıklandığı gibi desteklenen türlerden biri olmalıdır.
Operations Manager veritabanlarından herhangi birini barındıran tüm SQL Server veritabanı altyapısı örnekleri için SQL Server Tam Metin Araması gereklidir.
Operations Manager veritabanı bileşenleri tarafından desteklenen Windows Server yükleme seçenekleri (Sunucu Çekirdeği, Masaüstü Deneyimi ile Sunucu ve Nano Sunucu), SQL Server tarafından desteklenen yükleme seçeneklerini temel alır.

Daha fazla bilgi için sql server yükleme ve planlama belgelerinin altındaki Donanım ve Yazılım Gereksinimleri bölümüne bakın: SQL Server yüklemesini planlama

SQL Server harmanlama ayarı

System Center Operations Manager'da aşağıdaki SQL Server ve Windows harmanlamaları desteklenir.

Not

İşlemleri karşılaştırma veya kopyalama ile ilgili uyumluluk sorunlarını önlemek için SQL ve Operations Manager VERITABANı için aynı harmanlamayı kullanmanızı öneririz.

SQL Server harmanlaması

SQL_Latin1_General_CP1_CI_AS

Windows alfabe düzeni

Latin1_General_100_CI_AS
French_CI_AS
French_100_CI_AS
Cyrillic_General_CI_AS
Chinese_PRC_CI_AS
Chinese_Simplified_Pinyin_100_CI_AS
Chinese_Traditional_Stroke_Count_100_CI_AS
Japanese_CI_AS
Japanese_XJIS_100_CI_AS
Traditional_Spanish_CI_AS
Modern_Spanish_100_CI_AS
Latin1_General_CI_AS
Cyrillic_General_100_CI_AS
Korean_100_CI_AS
Czech_100_CI_AS
Hungarian_100_CI_AS
Polish_100_CI_AS
Finnish_Swedish_100_CI_AS

SQL Server örneğiniz daha önce listelenen desteklenen harmanlamalardan biriyle yapılandırılmadıysa yeni bir Operations Manager kurulumu başarısız olur. Ancak yerinde yükseltme başarıyla tamamlar.

Güvenlik duvarı yapılandırması

Operations Manager, veritabanlarını barındırmak için SQL Server'a ve geçmiş işletimsel verileri analiz etmek ve sunmak için bir raporlama platformuna bağlıdır. Yönetim sunucusu, İşlemler ve Web konsolu rollerinin SQL Server ile başarılı bir şekilde iletişim kurabilmesi gerekir ve ortamınızı doğru yapılandırmak için iletişim yolunu ve bağlantı noktalarını anlamak önemlidir.

SQL Always On Kullanılabilirlik Gruplarını kullanan bir dağıtılmış dağıtım tasarlarsanız, güvenlik duvarı güvenlik stratejinize eklenmesi gereken ek güvenlik duvarı yapılandırma ayarları vardır.

Aşağıdaki tabloda, yönetim sunucularının veritabanlarıyla iletişim kurabilmesi için SQL Server'ın gerektirdiği güvenlik duvarı bağlantı noktaları tanımlanmıştır:

Senaryo	Bağlantı noktası	Yön	Operations Manager Rolü
Operations Manager veritabanlarını barındıran SQL Server	TCP 1433 *	Gelen	yönetim sunucusu ve Web konsolu (Uygulama Danışmanı ve Uygulama Tanılama için)
SQL Server Browser hizmeti	UDP 1434	Gelen	yönetim sunucusu
SQL Server Ayrılmış Yönetici Bağlantısı	TCP 1434	Gelen	yönetim sunucusu
SQL Server tarafından kullanılan diğer bağlantı noktaları - Microsoft uzaktan yordam çağrıları (MS RPC) - Windows Yönetim Araçları (WMI) - Microsoft Dağıtılmış İşlem Düzenleyicisi (MS DTC)	TCP 135	Gelen	yönetim sunucusu
SQL Server Always On Kullanılabilirlik Grubu Dinleyicisi	Yönetici tarafından yapılandırılan bağlantı noktası	Gelen	yönetim sunucusu
Operations Manager Raporlama Sunucusu'nu barındıran SQL Server Reporting Services	TCP 80 (varsayılan)/443 (SSL)	Gelen	yönetim sunucusu ve İşletim konsolu

Not

TCP 1433, Veritabanı Altyapısı'nın varsayılan örneği için standart bağlantı noktası olsa da, tek başına bir SQL Server'da adlandırılmış bir örnek oluşturduğunuzda veya sql Always On Kullanılabilirlik Grubu dağıttığınızda, özel bir bağlantı noktası tanımlanır ve güvenlik duvarlarınızı düzgün yapılandırıp kurulum sırasında bu bilgileri girebilmeniz için başvuru için belgelenmelidir.

SQL Server güvenlik duvarı gereksinimlerine daha ayrıntılı bir genel bakış için bkz . Windows Güvenlik Duvarı'nı SQL Server Erişimine İzin Verecek Şekilde Yapılandırma.

Kapasite ve depolama ile ilgili dikkat edilmesi gerekenler

Operations Manager veritabanı

Operations Manager veritabanı, Operations Manager'ın günlük izleme için ihtiyaç duyduğu tüm verileri içeren bir SQL Server veritabanıdır. Veritabanı sunucusunun boyutlandırması ve yapılandırması, yönetim grubunun genel performansı için kritik önem taşır. Operations Manager veritabanı tarafından kullanılan en kritik kaynak depolama alt sistemidir, ancak CPU ve RAM de önemlidir.

Operations Manager veritabanındaki yükü etkileyen faktörler şunlardır:

İşletimsel veri toplama oranı.
- İşletimsel veri toplama hızı, içeri aktarılan yönetim paketlerinin sayısı, eklenen aracı sayısı ve izlenen bilgisayar türü gibi faktörlerden etkilenir. Örneğin, iş açısından kritik bir masaüstü bilgisayarı izleyen bir aracı, birden çok veritabanı olan SQL Server çalıştıran bir sunucuyu izleyen bir aracıya kıyasla daha az veri toplar.
Örnek alanı değişikliklerinin oranı.
- Operations Manager veritabanındaki mevcut verilerin güncelleştirilmesi, yeni işletimsel veriler yazmaya kıyasla yoğun kaynak kullanır. Ayrıca, örnek alan verilerinde değişiklikler olduğunda yönetim sunucularının yapılandırma ve grup değişikliklerini hesaplamak için veritabanında daha fazla sorgu yapması gerekir. Yeni yönetim paketleri içeri aktarılırken veya yönetim grubuna yeni aracılar eklenirken örnek alanı değişim hızı artar.
Aynı anda çalışan İşletim Konsolları ve diğer SDK bağlantılarının sayısı da veritabanındaki yükü etkiler.
- Her İşletim konsolu Operations Manager veritabanındaki verileri okur. Bu verilerin sorgulanması büyük miktarda depolama G/Ç kaynağı, CPU süresi ve RAM tüketir. Olaylar Görünümü, Durum Görünümü, Uyarılar Görünümü ve Performans Verileri Görünümü'nde büyük miktarda işletimsel veri görüntüleyen işlem konsolları, veritabanındaki en büyük yüke neden olma eğilimindedir.

Operations Manager veritabanı, yönetim grubu için tek bir hata kaynağı olduğundan SQL Server AlwaysOn Kullanılabilirlik Grupları veya Yük Devretme Kümesi Örnekleri gibi desteklenen yük devretme yapılandırmaları kullanılarak yüksek oranda kullanılabilir hale getirilebilir.

Yapılandırma sonrası değişikliklere gerek kalmadan Mevcut SQL Always-On kurulumuyla Operations Manager veritabanlarını ayarlayabilir ve yükseltebilirsiniz.

Operations Manager veritabanında SQL Aracısı'nı etkinleştirme

System Center Operations Manager, tüm görev işlemlerinin uygulanması için SQL Server Hizmet Aracısı'na bağlıdır. SQL Server Hizmet Aracısı devre dışı bırakılırsa, tüm görev işlemleri etkilenir. Sonuçta elde edilen davranış, başlatılan göreve göre değişebilir. Bu nedenle, System Center Operations Manager'daki bir görevin etrafında beklenmeyen davranışlar gözlemlendiğinde SQL Server Hizmet Aracısı'nın durumunu denetlemek önemlidir.

SQL Server Hizmet Aracısı'nı etkinleştirmek için şu adımları izleyin:

Alanda 1 (bir) sonucuyla gösterilen aracının zaten etkin olup olmadığını denetlemek için aşağıdaki SQL sorgusunu is_broker_enabled çalıştırın:
```
SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
```

Alanda görüntülenen is_broker_enabled değer 0 (sıfır) ise aracıyı etkinleştirmek için aşağıdaki SQL deyimini çalıştırın:

ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER

Operations Manager Veri Ambarı veritabanı

Not

Operations Manager Veri Ambarı, "Raporlama Veri Ambarı" veritabanı veya bazı belgelerde yalnızca "Veri Ambarı" olarak da adlandırılır.

System Center - Operations Manager verileri neredeyse gerçek zamanlı olarak veri ambarına ekler, bu sunucuda toplanan tüm verilerin veri ambarına yazılmasını destekleyen yeterli kapasiteye sahip olmak önemlidir. Operations Manager veritabanında olduğu gibi, veri ambarı üzerindeki en kritik kaynak depolama G/Ç alt sistemidir. Çoğu sistemde, veri ambarı üzerindeki yükler Operations Manager veritabanına benzer, ancak bunlar farklılık gösterebilir. Ayrıca, raporlama yoluyla veri ambarında yer alan iş yükü, operations konsolu kullanımına göre Operations Manager veritabanına yüklenen yükten farklıdır.

Veri ambarı yükünü etkileyen faktörler şunlardır:

İşletimsel veri toplama oranı.
- Veri ambarı, daha verimli raporlama sağlamak için sınırlı miktarda ham veriyle birlikte hesaplamalar gerçekleştirir ve toplanan verileri depolar. Sonuç olarak, işletimsel verileri veri ambarı için toplama maliyeti Operations Manager veritabanına kıyasla biraz daha yüksektir. Ancak bu maliyet, Operations Manager veritabanıyla karşılaştırıldığında veri ambarı içindeki bulma verilerinin daha düşük işleme maliyetine göre dengelenmiş olur.
Eşzamanlı raporlama kullanıcılarının veya zamanlanmış rapor oluşturmanın sayısı.
- Raporlar genellikle büyük hacimli verileri özetlediğinden, her raporlama kullanıcısı sisteme önemli bir yük ekleyebilir. Genel kapasite gereksinimleri, aynı anda çalıştırılan rapor sayısından ve çalıştırılan raporların türünden etkilenir. Büyük tarih aralıklarını veya çok sayıda nesneyi sorgulayan raporlar için ek sistem kaynakları gerekir.

Bu faktörlere bağlı olarak, veri ambarını boyutlandırırken göz önünde bulundurmanız gereken birkaç önerilen uygulama vardır:

Uygun bir depolama alt sistemi seçin.
- Veri ambarı, yönetim grubu aracılığıyla genel veri akışının ayrılmaz bir parçası olduğundan, veri ambarı için uygun bir depolama alt sistemi seçmek önemlidir. Operations Manager veritabanında olduğu gibi, RAID 0 + 1 genellikle en iyi seçenektir. Genel olarak, veri ambarı için depolama alt sistemi Operations Manager veritabanının depolama alt sistemine benzer olmalıdır ve Operations Manager veritabanı için geçerli olan yönergeler de veri ambarı için geçerlidir.
Veri günlüklerinin ve işlem günlüklerinin uygun yerleşimini göz önünde bulundurun.
- Operations Manager veritabanına gelince, aracı sayısının ölçeğini artırdıkça SQL verilerini ve işlem günlüklerini ayırmak genellikle uygun bir seçimdir. Hem Operations Manager veritabanı hem de veri ambarı aynı sunucuda bulunuyorsa ve verileri ve işlem günlüklerini ayırmak istiyorsanız, herhangi bir avantaj elde etmek için Operations Manager veritabanının işlem günlüklerini ayrı bir fiziksel birime ve veri ambarından disk iş akışlarına yerleştirmeniz gerekir. Birim yeterli kapasite sağladığı ve disk G/Ç performansı izleme ve raporlama işlevini olumsuz etkilemediği sürece Operations Manager veritabanı ve veri ambarı için veri dosyaları aynı fiziksel birimi paylaşabilir.
Veri ambarını Operations Manager veritabanından ayrı bir sunucuya yerleştirmeyi göz önünde bulundurun.
- Daha küçük ölçekli dağıtımlar genellikle Operations Manager veritabanını ve veri ambarını aynı sunucuda birleştirebilir, ancak aracı sayısını ve gelen işlem verilerinin hacmini artırdıkça bunları ayırmak daha avantajlıdır. Veri ambarı ve Raporlama Sunucusu Operations Manager veritabanından ayrı bir sunucuda olduğunda daha iyi raporlama performansıyla karşılaşırsınız.

Operations Manager Veri Ambarı veritabanı, yönetim grubu için tek bir hata kaynağı olduğundan SQL Server AlwaysOn Kullanılabilirlik Grupları veya Yük Devretme Kümesi Örnekleri gibi desteklenen yük devretme yapılandırmaları kullanılarak yüksek oranda kullanılabilir hale getirilebilir.

SQL Server AlwaysOn

SQL Server Always On kullanılabilirlik grupları, ayrık bir kullanıcı veritabanı kümesi (kullanılabilirlik veritabanları) için yük devretme ortamlarını destekler. Her kullanılabilirlik veritabanı kümesi bir kullanılabilirlik çoğaltmasında barındırılır.

System Center 2016 ve üzeri - Operations Manager ile veritabanları için yüksek kullanılabilirlik sağlamak üzere yük devretme kümelemesi yerine SQL AlwaysOn tercih edilir. Kalıcı veri depolama alanını geçici depolama gereksinimlerinden ayırmak için iki veritabanı kullanan yerel mod Reporting Services yüklemesi dışındaki tüm veritabanları Bir AlwaysOn Kullanılabilirlik Grubunda barındırılabilir.

Kullanılabilirlik grubu ayarlamak için, kullanılabilirlik çoğaltmasını barındırmak için bir Windows Server Yük Devretme Kümelemesi (WSFC) kümesi dağıtırsınız ve küme düğümlerinde Always On'u etkinleştirirsiniz. Ardından Operations Manager SQL Server veritabanını kullanılabilirlik veritabanı olarak ekleyebilirsiniz.

Always On önkoşulları hakkında daha fazla bilgi edinin.
Always On kullanılabilirlik grupları için WSFC ayarlama hakkında daha fazla bilgi edinin.
Kullanılabilirlik grubu ayarlama hakkında daha fazla bilgi edinin.

İpucu

Operations Manager 2022'de başlayarak, yapılandırma sonrası değişikliklere gerek kalmadan operations manager veritabanlarını mevcut bir SQL Always-On kurulumuyla ayarlayabilir ve yükseltebilirsiniz.

Always On önkoşulları hakkında daha fazla bilgi edinin.
Always On kullanılabilirlik grupları için WSFC ayarlama hakkında daha fazla bilgi edinin.
Kullanılabilirlik grubu ayarlama hakkında daha fazla bilgi edinin.

Not

SQL Always On'a katılan SQL sunucu düğümlerine Operations Manager dağıtıldıktan sonra CLR sıkı güvenliğini sağlamak için her Operations Manager veritabanında SQL betiğini çalıştırın.

Multisubnet dizesi

Operations Manager bağlantı dizesi anahtar sözcüklerini (MultiSubnetFailover=True ) desteklemez. Bir kullanılabilirlik grubunun bir dinleyici adı (WSFC Küme Yöneticisi'nde ağ adı veya İstemci Erişim Noktası olarak bilinir) olduğundan, siteler arası yük devretme yapılandırmasında dağıtım yaptığınızda olduğu gibi, farklı alt ağlardan gelen birden çok IP adresine bağlı olarak yönetim sunucularından kullanılabilirlik grubu dinleyicisine istemci bağlantı istekleri bağlantı zaman aşımına uyacaktır.

Çok alt ağlı bir ortamda dağıtılan kullanılabilirlik grubu sunucu düğümleriyle ilgili bu sınırlamayı geçici olarak çözmek için önerilen yaklaşım:

Kullanılabilirlik grubu dinleyicinizin ağ adını, DNS'de yalnızca tek bir etkin IP adresini kaydedecek şekilde ayarlayın.
Kümeyi kayıtlı DNS kaydı için düşük bir TTL değeri kullanacak şekilde yapılandırın.

Bu ayarlar, farklı bir alt ağdaki bir düğüme yük devredildiğinde küme adının yeni IP adresiyle daha hızlı kurtarılmasını ve çözülmesini sağlar.

Bu ayarları değiştirmek için SQL düğümlerinden herhangi birinde aşağıdaki PowerShell komutlarını çalıştırın:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Always On'ı dinleyici adıyla kullanıyorsanız, bu yapılandırma değişikliklerini dinleyicide de yapmalısınız. Kullanılabilirlik grubu dinleyicisini yapılandırma hakkında daha fazla bilgi için buradaki belgelere bakın: Kullanılabilirlik grubu dinleyicisini yapılandırma - SQL Server AlwaysOn.

Şu anda dinleyiciyi barındıran SQL düğümünde aşağıdaki PowerShell komutları çalıştırılabilir ve ayarlarını değiştirebilir:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Yüksek kullanılabilirlik için kümelenmiş veya Always On SQL örneği kullanıldığında, düğümler arasında yük devretme gerçekleştiğinde Operations Manager Veri Erişimi hizmetinin yeniden başlatılmasını önlemek için yönetim sunucularınızda otomatik kurtarma özelliğini etkinleştirmeniz gerekir. Yapılandırma bilgileri için, bir SQL Server örneği çevrimdışı olduktan sonra System Center Management hizmeti yanıt vermeyi durduruyor başlıklı aşağıdaki KB makalesine bakın.

SQL Server'ın iyileştirilmesi

Destek deneyimleri, performans sorunlarının genellikle SQL Server'ın kendisiyle yüksek kaynak kullanımından (işlemci veya bellek) kaynaklandığını göstermiştir; bunun yerine sorun doğrudan depolama alt sisteminin yapılandırmasıyla ilgilidir. Performans sorunları genellikle SQL Server veritabanı örneği için sağlanan depolama ile önerilen yapılandırma yönergelerini takip etmemeye atfedilir. Bu örnekler şunlardır:

Operations Manager'ın GÇ gereksinimlerini desteklemek üzere LUN'lar için iş mili ayırması yetersiz.
İşlem günlüklerini ve veritabanı dosyalarını aynı birimde barındırma. Bu iki iş yükü farklı GÇ ve gecikme süresi özelliklerine sahiptir.
TempDB yapılandırması yerleştirme, boyutlandırma vb. açısından yanlıştır.
Veritabanı işlem günlüklerini, veritabanı dosyalarını ve TempDB'yi barındıran birimlerin disk bölümü yanlış hizalanması.
Veritabanı ve işlem günlüğü dosyaları için AUTOGROW kullanma, sorgu paralelliği için MAXDOP ayarı, CPU çekirdeği başına birden çok TempDB veri dosyası oluşturma gibi temel SQL Server yapılandırmasına göz atma.

Depolama yapılandırması, Operations Manager için SQL Server dağıtımının kritik bileşenlerinden biridir. Veritabanı sunucuları yoğun veritabanı okuma ve yazma etkinliği ve işlem günlüğü işleme nedeniyle yoğun G/Ç bağlı olma eğilimindedir. Operations Manager'ın G/Ç davranış düzeni genellikle %80 yazma ve %20 okuma şeklindedir. Sonuç olarak, G/Ç alt sistemlerinin yanlış yapılandırılması SQL Server sistemlerinin performansının ve çalışmasının düşmesine neden olabilir ve Operations Manager'da fark edilebilir hale gelebilir.

SQL Server'ı dağıtmadan önce GÇ alt sisteminin aktarım hızı testini gerçekleştirerek SQL Server tasarımını test etmek önemlidir. Bu testlerin GÇ gereksinimlerinize kabul edilebilir bir gecikme süresiyle ulaşabildiğinden emin olun. SQL Server'ı destekleyen depolama alt sisteminin G/Ç kapasitesini değerlendirmek için Diskspd Yardımcı Programı'nı kullanın. Ürün grubundaki Dosya Sunucusu ekibinin bir üyesi tarafından yazılan aşağıdaki blog makalesinde DiskSpd, PowerShell ve depolama performansı gibi bu aracı kullanarak stres testi gerçekleştirme hakkında ayrıntılı yönergeler ve öneriler sağlanır: hem yerel diskler hem de SMB dosya paylaşımları için IOP'leri, aktarım hızını ve gecikme süresini ölçme.

NTFS ayırma birimi boyutu

Bir RAID cihazında birim oluşturulduğunda, genellikle kesim hizalaması olarak adlandırılan birim hizalaması dosya sisteminde (NTFS) gerçekleştirilmelidir. Bunun yapılmaması önemli performans düşüşlerine yol açabilir ve en yaygın olarak şeritli birim sınırlarıyla bölüm yanlış hizalamasının sonucudur. Ayrıca donanım önbelleğinin yanlış hizalanmasına yol açarak dizi önbelleğinin verimsiz kullanımına neden olabilir.

SQL Server veri dosyaları için kullanılan bölümü biçimlendirirken, veriler, günlükler ve TempDB için 64 KB ayırma birimi boyutu (65.536 bayt) kullanılması önerilir. Ancak, 4 KB'tan büyük ayırma birimi boyutlarının kullanılması, birim üzerinde NTFS sıkıştırmasının kullanılamayacağı anlamına gelir. SQL Server sıkıştırılmış birimlerdeki salt okunur verileri desteklese de önerilmez.

Bellek ayırma

Not

Bu bölümdeki bilgilerin çoğu, blog gönderisindeki Jonathan Kehayias'tan geliyor SQL Server'ımın gerçekte ne kadar belleğe ihtiyacı var? (sqlskills.com).

System Center Operations Manager'ı (veya bu ürünün dışındaki diğer iş yüklerini) desteklemek üzere SQL Server'a ayırmak üzere doğru miktarda fiziksel bellek ve işlemci tanımlamak her zaman kolay değildir. Ürün grubu tarafından sağlanan boyutlandırma hesaplayıcısı, iş yükü ölçeğine göre rehberlik sağlar, ancak önerileri gerçek iş yükünüz ve yapılandırmanızla uyumlu olabilecek veya uymayan bir laboratuvar ortamında gerçekleştirilen testlere dayanır.

SQL Server, işlemi tarafından ayrılacak ve kullanılacak en düşük ve en yüksek bellek miktarını yapılandırmanıza olanak tanır. Varsayılan olarak, SQL Server kullanılabilir sistem kaynaklarına göre bellek gereksinimlerini dinamik olarak değiştirebilir. En düşük sunucu belleği için varsayılan ayar 0'dır ve en fazla sunucu belleği için varsayılan ayar 2.147.483.647 MB'tır.

Maksimum sunucu belleği için uygun bir değer ayarlamazsanız performans ve bellekle ilgili sorunlar ortaya çıkabilir. birçok faktör, işletim sisteminin HBA kartı, yönetim aracıları ve virüsten koruma gerçek zamanlı tarama gibi o sistemde çalışan diğer işlemleri destekleyeebilmesini sağlamak için SQL Server'a ne kadar bellek ayırmanız gerektiğini etkiler. Yeterli bellek ayarlanmadıysa işletim sistemi ve SQL diske sayfalanır. Bu, disk G/Ç'nin performansı artırmasına, performansı daha da azaltmasına ve Operations Manager'da fark edilebilir hale geldiği bir dalgalanma etkisi oluşturmasına neden olabilir.

En az sunucu belleği için en az 4 GB RAM belirtmenizi öneririz. Bu işlem Operations Manager veritabanlarından birini (işletimsel, veri ambarı, ACS) barındıran her SQL düğümü için yapılmalıdır.

En fazla sunucu belleği için başlangıçta toplam şunları ayırmanızı öneririz:

İşletim sistemi için 1 GB RAM
Yüklenen her 4 GB RAM başına 1 GB RAM (16 GB RAM'e kadar)
Yüklenen her 8 GB RAM başına 1 GB RAM (16 GB'ın üzerinde RAM)

Bu değerleri ayarladıktan sonra Windows'ta Memory\Available MBytes sayacını izleyerek SQL Server için kullanılabilir belleği artırabileceğinizi belirleyin. Windows kullanılabilir fiziksel belleğin 96 MB'de azaldığını belirtir, bu nedenle ideal olarak bir arabelleğe sahip olduğunuzdan emin olmak için sayacın yaklaşık 200-300 MB'tan daha düşük çalışmaması gerekir. 256 GB veya daha yüksek RAM'e sahip sunucular için 1 GB'tan düşük çalışmadığından emin olun.

Bu hesaplamaları, diğer uygulamaları hesaba eklemek için değiştirmediğiniz sürece SQL Server'ın tüm kullanılabilir belleği kullanabilmesini istediğinizi unutmayın. İşletim sisteminiz, diğer uygulamalarınız, SQL Server iş parçacığı yığınınız ve diğer çok sayfalı ayırıcılarınız için belirli bellek gereksinimlerini göz önünde bulundurun. Tipik bir formül, iş parçacığı yığını için belleğin = ((max worker threads) (stack size))olduğu şeklinde olur((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)). Yığın boyutu x86 sistemleri için 512 KB, x64 sistemleri için 2 MB ve IA64 sistemleri için 4 MB'tır ve sys.dm_os_sys_info max_worker_count sütununda maksimum çalışan iş parçacıklarının değerini bulabilirsiniz.

Bu noktalar, SQL Server'ın bir sanal makinede çalışması için bellek gereksinimleri için de geçerlidir. SQL Server arabellek havuzundaki verileri önbelleğe almak için tasarlandığından ve mümkün olduğunca çok bellek kullandığından, gereken ideal RAM miktarını belirlemek zor olabilir. BIR SQL Server örneğine ayrılan belleği azaltırken, daha düşük bellek ayırma işleminin daha yüksek disk G/Ç erişimi için takas edildiği bir noktaya ulaşabilirsiniz.

Aşırı sağlanmış bir ortamda SQL Server belleğini yapılandırmak için, sql Server Buffer Manager sayfa ömrü beklentisi ve sayfa okuma/sn ve Fiziksel Disk disk okuma/sn değerleri dahil olmak üzere ortamı ve geçerli performans ölçümlerini izleyerek başlayın. Ortamda fazla bellek varsa, önbelleğe alma nedeniyle sayfa ömrü beklentisi iş yükü altında herhangi bir azalma olmadan saniye başına bir değer artar; önbellek artırıldıktan sonra SQL Server Arabellek Yöneticisi sayfa okuma/sn değeri düşük olur ve Fiziksel Disk disk okuma/sn değeri de düşük kalır.

Ortam temelini anladıktan sonra en fazla sunucu belleğini 1 GB azaltabilir ve ardından bunun performans sayaçlarınızı nasıl etkilediğini görebilirsiniz (herhangi bir ilk önbellek temizleme işlemi tamamlandıktan sonra). Ölçümler kabul edilebilir durumda kalırsa, 1 GB daha azaltın, ardından ideal yapılandırmayı belirleyene kadar istediğiniz gibi tekrarlayarak yeniden izleyin.

Daha fazla bilgi için bkz . Sunucu belleği yapılandırma seçenekleri.

TempDB'i en iyi duruma getirme

TempDB veritabanının boyutu ve fiziksel yerleşimi Operations Manager'ın performansını etkileyebilir. Örneğin, TempDB için tanımlanan boyut çok küçükse, SQL Server örneğini her yeniden başlattığınızda TempDB'nin iş yükünü desteklemek için gereken boyuta otomatik olarak büyütülerek sistem işleme yükünün bir kısmı alınabilir. En iyi TempDB performansını elde etmek için üretim ortamında TempDB için aşağıdaki yapılandırmayı öneririz:

TempDB'nin kurtarma modelini SIMPLE olarak ayarlayın.
- Bu model, alan gereksinimlerini küçük tutmak için günlük alanını otomatik olarak geri alır.
Dosya boyutunu ortamdaki tipik iş yükünü barındıracak kadar büyük bir değere ayarlayarak tüm TempDB dosyaları için önceden yer ayırın. TempDB'nin çok sık genişlemesini engeller ve bu da performansı etkileyebilir. TempDB veritabanı otomatik olarak büyütülecek şekilde ayarlanabilir, ancak planlanmamış özel durumlar için disk alanını artırmak için bu kullanılmalıdır.
Disk bant genişliğini en üst düzeye çıkarmak için gerektiği kadar dosya oluşturun.
- Birden çok dosya kullanmak TempDB depolama çekişmesini azaltır ve geliştirilmiş ölçeklenebilirlik sağlar. Ancak, performansı düşürebileceği ve yönetim ek yükünü artırabileceği için çok fazla dosya oluşturmayın.
- Genel bir yönerge olarak, sunucudaki her mantıksal işlemci için bir veri dosyası oluşturun (benşim maskesi ayarlarını dikkate alır) ve ardından dosya sayısını gerektiği gibi yukarı veya aşağı ayarlayın.
- Genel bir kural olarak, mantıksal işlemci sayısı 8'den küçük veya buna eşitse, mantıksal işlemcilerle aynı sayıda veri dosyası kullanın.
  - Mantıksal işlemci sayısı 8'den büyükse sekiz veri dosyası kullanın ve çekişme devam ederse, çekişme kabul edilebilir düzeylere düşürülene veya iş yükünde/kodda değişiklik yapıncaya kadar veri dosyası sayısını 4'ün katları (mantıksal işlemci sayısına kadar) artırın.
  - Çekişme azaltılmadıysa veri dosyası sayısını daha fazla artırmanız gerekebilir.
Her veri dosyasını aynı boyuta getirerek en uygun oransal doldurma performansını elde edin.
- Orantılı doldurma algoritması dosyaların boyutuna bağlı olduğundan veri dosyalarının eşit boyutlandırılması kritik önem taşır. Veri dosyaları eşit olmayan boyutlarda oluşturulursa orantılı doldurma algoritması, ayırmaları tüm dosyalar arasında yaymak yerine GAM ayırmaları için en büyük dosyayı daha fazla kullanmaya çalışır ve böylece birden çok veri dosyası oluşturma amacını alt eder.
En iyi performans için katı hal sürücülerini kullanarak TempDB veritabanını hızlı bir G/Ç alt sistemine yerleştirin.
- Doğrudan bağlı çok sayıda disk varsa disk şeritleme kullanın.
TempDB veritabanını, kullanıcı veritabanları tarafından kullanılan disklerden farklı disklere yerleştirin.

TempDB'yi yapılandırmak için aşağıdaki sorguyu çalıştırabilir veya Management Studio'da özelliklerini değiştirebilirsiniz.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

TempDB veritabanı için sayfa ayırma çekişmesi algılamak için T-SQL sorgusunu SELECT * from sys.sysprocesses çalıştırın. Sistem tablosu çıkışında, bekleme kaynağı "2:1:1" (PFS Sayfası) veya "2:1:3" (Paylaşılan Genel Ayırma Eşleme Sayfası) olarak görünebilir. Çekişme derecesine bağlı olarak, bu ayar SQL Server'ın kısa süreler boyunca yanıt vermemesine neden olabilir. Bir diğer yaklaşım da Dinamik Yönetim Görünümlerini [sys.dm_exec_request veya sys.dm_os_waiting_tasks] incelemektir. Sonuçlar, bu isteklerin veya görevlerin TempDB kaynaklarını beklediğini ve sorguyu yürütürken daha önce vurgulandığı gibi benzer değerlere sys.sysprocesses sahip olduğunu gösterir.

Önceki öneriler ayırma çekişmesini önemli ölçüde azaltmıyorsa ve çekişme SGAM sayfalarındaysa, SQL Server geri dönüştürüldükten sonra bile izleme bayrağının -T1118 etkin kalması için SQL Server'ın Başlangıç parametrelerine izleme bayrağı uygulayın. Bu izleme bayrağı altında, SQL Server her veritabanı nesnesine tam kapsam ayırarak SGAM sayfalarında çekişme ortadan kaldırır.

Not

Bu izleme bayrağı, SQL Server örneğindeki tüm veritabanlarını etkiler.

En yüksek paralellik derecesi

İpucu

SQL Server ekibinin en son en iyi uygulamaları ve önerileri için buradaki belgelerine bakın: En iyi performans için en yüksek paralellik derecesini ayarlama

Operations Manager'ın küçük ve orta ölçekli dağıtımları için SQL Server'ın varsayılan yapılandırması çoğu gereksinim için yeterlidir. Ancak, yönetim grubunun iş yükü bir kurumsal sınıf senaryosuna (genellikle 2.000'den fazla aracıyla yönetilen sistem ve gelişmiş yapay işlemler, ağ cihazı izleme, platformlar arası vb.) hizmet düzeyinde izleme içeren gelişmiş izleme yapılandırmasına göre ölçeklendirildiğinde, belgenin bu bölümünde açıklanan SQL Server yapılandırmasını iyileştirmek gerekir. Önceki kılavuzda ele alınmayan bir yapılandırma seçeneği MAXDOP'dur.

Microsoft SQL Server maksimum paralellik derecesi (MAXDOP) yapılandırma seçeneği, bir sorgunun paralel planda yürütülmesi için kullanılan işlemci sayısını denetler. Bu seçenek, işi paralel olarak gerçekleştiren sorgu planı işleçleri için kullanılan bilgi işlem ve iş parçacığı kaynaklarını belirler. SQL Server'ın simetrik çok işlemcili (SMP) bir bilgisayarda mı, tek biçimli bellek erişimi (NUMA) bilgisayarında mı yoksa hiper iş parçacığı özellikli işlemcilerde mi kurulu olduğuna bağlı olarak, en yüksek paralellik derecesini uygun şekilde yapılandırmanız gerekir.

SQL Server birden fazla mikro işlemci veya CPU'ya sahip bir bilgisayarda çalıştığında, her paralel plan yürütmesi için en iyi paralellik derecesini, yani tek bir deyimi çalıştırmak için kullanılan işlemci sayısını algılar. Varsayılan olarak, bu seçenek için değeri 0'dır ve SQL Server'ın en yüksek paralellik derecesini belirlemesine olanak tanır.

İşletim sistemi, veri ambarı ve hatta denetim veritabanıyla ilgili olarak Operations Manager'da önceden tanımlanmış saklı yordamlar ve sorgular MAXDOP seçeneğini içermez çünkü yükleme sırasında işletim sistemine kaç işlemcinin sunulduğunu dinamik olarak sorgulamanın hiçbir yolu yoktur ve bu ayar için değeri sabit kodlamaya çalışmaz ve bu da sorgu yürütülürken olumsuz sonuçlara neden olabilir.

Not

En yüksek paralellik yapılandırma derecesi seçeneği, SQL Server'ın kullandığı işlemci sayısını sınırlamaz. SQL Server'ın kullandığı işlemci sayısını yapılandırmak için benşim maskesi yapılandırma seçeneğini kullanın.

Sekizden fazla işlemci kullanan sunucular için şu yapılandırmayı kullanın: MAXDOP=8
Sekiz veya daha az işlemci kullanan sunucular için şu yapılandırmayı kullanın: MAXDOP=0 - N

İpucu

Bu yapılandırmada işlemci N sayısını temsil eder.
NUMA'nın yapılandırıldığı sunucular için MAXDOP, her NUMA düğümüne atanan CPU sayısını aşmamalıdır.
Hiper iş parçacığı kullanımı etkinleştirilmiş sunucular için MAXDOP değeri fiziksel işlemci sayısını aşmamalıdır.
NUMA yapılandırılmış ve hiper iş parçacığı kullanımı etkinleştirilmiş sunucular için MAXDOP değeri, NUMA düğümü başına fiziksel işlemci sayısını aşmamalıdır.

sorgulayarak select * from sys.dm_os_tasksparalel çalışan sayısını izleyebilirsiniz.

Bu örnekte, sunucunun donanım yapılandırması 24 çekirdekli işlemci ve 196 GB RAM'e sahip bir HP Blade G6'ydı. Operations Manager veritabanını barındıran örneğin MAXMEM ayarı 64 GB'tır. Bu bölümde önerilen iyileştirmeler gerçekleştirildikten sonra performans iyileştirildi. Ancak, sorgu paralelliği performans sorunu hala devam ediyor. Farklı değerler test edildikten sonra en uygun performans MAXDOP=4 ayarıyla bulundu.

İlk veritabanı boyutlandırması

Dağıtımdan sonraki ilk birkaç ay içinde Operations Manager veritabanlarının, özellikle de işletimsel ve veri ambarı veritabanlarının gelecekteki büyümesini tahmin etmeye çalışmak basit bir alıştırma değildir. Operations Manager Boyutlandırma Yardımcısı, laboratuvardaki testlerinden ürün grubu tarafından türetilen formüle göre olası büyümeyi tahmin etmek için makul olsa da, yakın dönemdeki büyümeyi uzun vadeliye göre etkiebilen çeşitli faktörleri hesaba katmamaktadır.

Boyutlandırma Yardımcısı tarafından önerilen ilk veritabanı boyutu, parçalanmayı ve buna karşılık gelen ek yükü azaltmak için tahmin edilen bir boyuta ayrılmalıdır. Bu boyut İşletimsel ve Veri Ambarı veritabanları için kurulum zamanında belirtilebilir. Kurulum sırasında yeterli depolama alanı yoksa veritabanları daha sonra SQL Management Studio kullanılarak genişletilebilir ve ardından birleştirilip uygun şekilde iyileştirmek için yeniden dizinlenebilir. Bu öneri ACS veritabanı için de geçerlidir.

operasyonel ve veri ambarı veritabanının büyümesinin proaktif izlenmesi günlük veya haftalık bir döngüde yapılmalıdır. Bu, bir yönetim paketi iş akışındaki bir hata (bulma kuralı, performans veya olay toplama kuralı ya da izleme veya uyarı kuralı) ya da yayın yönetimi sürecinin test ve kalite güvencesi aşamasında tanımlanmayan bir yönetim paketiyle ilgili diğer belirtilere göre beklenmeyen ve önemli büyüme artışlarını belirlemek ve nedenselliği belirlemek için sorun gidermeye başlamak için gereklidir.

Veritabanı otomatik büyütme

Ayrılmış veritabanlarının dosya boyutu dolduğunda, SQL Server boyutu otomatik olarak yüzde veya sabit bir miktar artırabilir. Ayrıca, diskte kullanılabilir tüm alanın dolmasını önlemek için maksimum veritabanı boyutu yapılandırılabilir. Varsayılan olarak, Operations Manager veritabanı otomatik büyütme etkin olarak yapılandırılmaz; yalnızca Veri Ambarı ve ACS veritabanlarıdır.

Beklenmeyen büyüme için yalnızca otomatik büyümeyi bir olasılık olarak kullanın. Otomatik büyütme, yüksek oranda işlemsel bir veritabanıyla ilgilenirken dikkate alınması gereken bir performans cezasına neden olur. Performans cezaları şunlardır:

Uygun bir büyüme artışı sağlamazsanız, günlük dosyasının veya veritabanının parçalanması oluşabilir.
Kullanılabilirden daha fazla günlük alanı gerektiren bir işlem çalıştırırsanız ve bu veritabanının işlem günlüğü için otomatik büyütme etkinleştirilirse, işlemin tamamlanması için geçen süre, işlem günlüğünün yapılandırılan tutara göre büyümesi için gereken süreyi içerir.
Günlüğün büyümesini gerektiren büyük bir işlem çalıştırırsanız, işlem günlüğüne yazma gerektiren diğer işlemlerin de büyüme işlemi tamamlanana kadar beklemesi gerekir.

Otomatik büyütme ve otomatikshrink seçenekleri birleştirilirse, bu gereksiz ek yük oluşturabilir. Büyütme ve küçültme işlemlerini tetikleyen eşiklerin sık sık yukarı ve aşağı boyut değişikliklerine neden olmayacağından emin olun. Örneğin, işlem günlüğünün işlemeye göre 100 MB büyümesine neden olan bir işlem çalıştırabilirsiniz; bir süre sonra otomatik ifade başlatılır ve işlem günlüğü 100 MB küçültür. Ardından aynı işlemi çalıştırırsınız ve işlem günlüğünün yeniden 100 MB büyümesine neden olur. Bu örnekte gereksiz ek yük oluşturup günlük dosyasının parçalanma olasılığını oluşturuyorsunuz ve bu işlemlerden biri performansı olumsuz etkileyebilir.

Bu iki ayarı dikkatle yapılandırın. Belirli bir yapılandırma gerçekten ortamınıza bağlıdır. Genel öneri, disk parçalanmasını azaltmak için veritabanı boyutunu sabit bir miktar artırmaktır. Örneğin, otomatik büyütme gerektiğinde veritabanının 1.024 MB büyüyecek şekilde yapılandırıldığı aşağıdaki şekile bakın.

Küme yük devretme ilkesi

Windows Server Yük Devretme Kümelemesi, bir kümedeki düğümlerin ağ bağlantılarını ve sistem durumunu sürekli izleyen yüksek kullanılabilirlik platformudur. Bir düğüme ağ üzerinden erişilemiyorsa, uygulamaları ve hizmetleri kurtarmak ve kümedeki başka bir düğümde çevrimiçi duruma getirmek için kurtarma eylemi gerçekleştirilir. Varsayılan ayarlar, "sabit" hata olarak kabul edilen bir sunucu kaybı olduğunda hatalar için iyileştirilir. Bunlar, yedekli olmayan donanım veya güç hatası gibi kurtarılamaz hata senaryoları olabilir. Bu gibi durumlarda sunucu kaybolur ve amaç Yük Devretme Kümelemesi'nin sunucu kaybını hızla algılaması ve kümedeki başka bir sunucuda hızla kurtarılmasıdır. Sabit hatalardan bu hızlı kurtarmayı gerçekleştirmek için, küme durumu izleme için varsayılan ayarlar oldukça agresiftir. Ancak, çeşitli senaryolarda esneklik sağlamak için tamamen yapılandırılabilir.

Bu varsayılan ayarlar çoğu müşteri için en iyi davranışı sunar; ancak kümeler inçten kilometrelere kadar uzatıldığından, küme düğümler arasında daha fazla ve güvenilir olmayabilecek ağ bileşenlerine maruz kalabilir. Bir diğer faktör de, yedekli bileşenler (çift güç kaynakları, NIC grubu oluşturma ve çok G/Ç gibi) aracılığıyla artırılmış dayanıklılıkla birlikte ticari sunucuların kalitesinin sürekli artmasıdır. Yedekli olmayan donanım arızalarının sayısı oldukça nadir olabilir. Sabit hatalar daha az sıklıkta olabileceğinden, bazı müşteriler kümeyi düğümler arasındaki kısa ağ hatalarına karşı daha dayanıklı olduğu geçici hatalar için ayarlamak isteyebilir. Varsayılan hata eşiklerini artırarak, kısa bir süre süren kısa ağ sorunlarına duyarlılığı azaltabilirsiniz.

Burada doğru yanıtın olmadığını ve iyileştirilmiş ayarın iş gereksinimlerinize ve hizmet düzeyi sözleşmelerinize göre farklılık gösterebileceğini anlamak önemlidir.

SQL Server'ın sanallaştırılması

Sanal ortamlarda, performans nedenleriyle işletimsel veritabanını ve veri ambarı veritabanını sanal diskte değil, doğrudan bağlı bir depolamada depolamanız önerilir. Doğrulamak üzere gerekli IOPS'yi tahmin etmek ve veri disklerinizi stres test etmek için Operations Manager 2012 için yayımlanan Operations Manager Boyutlandırma Yardımcısı yardımcı programını kullanabilirsiniz. Depolama performansı DiskSpd yardımcı programıyla test edilebilir. Ayrıca sanallaştırılmış Operations Manager ortamı hakkında ek yönergeler için bkz. Operations Manager sanallaştırma desteği .

AlwaysOn ve kurtarma modeli

Tamamen bir iyileştirme olmasa da Always On Kullanılabilirlik Grubu ile ilgili önemli bir nokta, bu özelliğin tasarım gereği veritabanlarının "Tam" kurtarma modelinde ayarlanmasını gerektirmesidir. Başka bir deyişle, tam yedekleme yapılana veya yalnızca işlem günlüğü yapılana kadar işlem günlükleri hiçbir zaman atılır. Bu nedenle yedekleme stratejisi isteğe bağlı değildir ancak Operations Manager veritabanları için AlwaysOn tasarımının gerekli bir parçasıdır. Aksi takdirde, zaman içinde işlem günlüklerini içeren diskler dolar.

Yedekleme stratejisi, ortamınızın ayrıntılarını dikkate almalıdır. Aşağıdaki tabloda tipik bir yedekleme zamanlaması verilmiştir.

Yedekleme Türü	Zamanla
Yalnızca işlem günlüğü	Bir saatte bir
Tam	Haftalık, Pazar saat 03:00'te

SQL Server raporlama hizmetlerini iyileştirme

Reporting Services örneği, Veri Ambarı veritabanındaki verilere erişim için ara sunucu işlevi görür. Yönetim paketlerinin içinde depolanan şablonları temel alan raporlar oluşturur ve görüntüler.

Operations Manager Raporlama rolü, Raporlama rolünün önceki bir sürümüyle yan yana yüklenemez ve yalnızca yerel modda yüklenmelidir (SharePoint tümleşik modu desteklenmez).

Reporting Services'in arka planda, ReportServer ve ReportServerTempDB veritabanlarını barındıran bir SQL Server Veritabanı örneği vardır. Bu örneğin performans ayarlaması ile ilgili genel öneriler geçerlidir.

Not

SQL Server Reporting Services (SSRS) 2017 sürüm 14.0.600.1274 ve sonraki sürümlerden, varsayılan güvenlik ayarları kaynak uzantısının karşıya yüklenmesine izin vermez. Bu, raporlama bileşenlerinin dağıtımı sırasında Operations Manager'da ResourceFileFormatNotAllowedException özel durumlarına yol açar.

Bunu düzeltmek için:

SQL Management Studio'yu açın.
Reporting Services örneğine bağlanın.
Nesne Gezgini penceresinde sunucu örneğine sağ tıklayın.
Özellikleri'i seçin.
Sol kenar çubuğunda Gelişmiş'i seçin.
AllowedResourceExtensionsForUpload listesine ekleyin*.*.

Alternatif olarak, Operations Manager'ın raporlama uzantılarının tam listesini SSRS'deki izin verme listesine ekleyebilirsiniz. Liste şu şekilde açıklanmıştır: "Çözüm 2": Operations Manager raporları dağıtılamaz

Sonraki adımlar

(Raporlama) Veri Ambarı'nı bir güvenlik duvarının arkasında barındırmayı yapılandırmak için bkz . (Raporlama) Veri Ambarını Güvenlik Duvarı Üzerinden Bağlama.

Aracılığıyla paylaş