SQL Server Tasarımında Dikkat Edilmesi Gerekenler

System Center Operations Manager işletimsel, veri ambarı ve ACS denetim veritabanını desteklemek için Microsoft SQL Server çalıştıran bir sunucu örneğine erişim gerektirir. İşletimsel ve veri ambarı veritabanları gereklidir ve yönetim grubunuzdaki ilk yönetim sunucusunu dağıttığınızda oluşturulurken, yönetim grubunuzda bir ACS toplayıcısı dağıttığınızda ACS veritabanı oluşturulur.

Bir laboratuvar ortamında veya Operations Manager'ın 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.

Diğer uygulama veritabanlarına sahip bir SQL Örneğinden Operations Manager veritabanlarının kullanılması önerilmez. Bu, G/Ç ve diğer donanım kaynağı kısıtlamalarıyla ilgili olası sorunları önlemektir.

Ö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:

• SQL Server 2022

• Toplu Güncelleştirme 8 (CU8) veya sonraki bir sürüme sahip SQL Server 2019 burada ayrıntılı olarak açıklandı

  Not

  • Operations Manager 2022, CU8 veya üzeri ile SQL 2019'i destekler; ancak SQL 2019 RTM'yi desteklemez.
  • ODBC 17.3 veya 17.10.6 ve MSOLEDBSQL 18.2 veya 18.7.2 kullanın.

• Burada ayrıntılı olarak açıklandığı gibi SQL Server 2017 ve Toplu Güncelleştirmeler

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

Not

• SCOM altyapısını destekleyen aşağıdaki SQL Server bileşenlerinin her birinin aynı SQL Server ana sürümünde olması gerekir:
  • SCOM veritabanlarından herhangi birini barındıran SQL Server veritabanı altyapısı örnekleri (OperationManager, OperationManagerDW ve SSRS veritabanları ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services (SSRS) örneği.
• SQL Server harmanlama ayarı, aşağıdaki SQL Server harmanlama ayarı bölümünde açıklandığı gibi desteklenen türlerden biri olmalıdır.
• SCOM 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 2016 yükleme seçenekleri (Sunucu Çekirdeği, Masaüstü Deneyimi ile Sunucu ve Nano Sunucu) SQL Server tarafından desteklenen Windows Server yükleme seçeneklerini temel alır.

Not

System Center Operations Manager Raporlama, 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).

Tasarım planlamanızda ek donanım ve yazılım konuları geçerlidir:

• SQL Server'ı NTFS dosya biçimindeki bilgisayarlarda çalıştırmanızı öneririz.
• İşletimsel ve veri ambarı veritabanı için en az 1024 MB boş disk alanı olmalıdır. Veritabanı oluşturulurken uygulanır ve kurulumdan sonra büyük olasılıkla önemli ölçüde büyüyecektir.
• .NET Framework 4 gereklidir.
• .NET Framework 4.8, Operations Manager 2022'de desteklenir.
• Raporlama Sunucusu, Windows Server Core'da desteklenmez.

Daha fazla bilgi için bkz . SQL Server'ı Yüklemek için Donanım ve Yazılım Gereksinimleri.

Not

Operations Manager yükleme sırasında yalnızca Windows kimlik doğrulamasını kullansa da, db_owner rolüne sahip yerel hesap yoksa SQL Karma Mod Kimlik Doğrulaması ayarı çalışmaya devam eder. db_owner rolüne sahip yerel hesapların System Center Operations Manager ile ilgili sorunlara neden olduğu bilinmektedir. Ürünü yüklemeden önce tüm yerel hesaplardan db_owner rolünü kaldırın ve yüklemeden sonra db_owner rolünü yerel hesapların hiçbirine eklemeyin.

SQL Server harmanlama ayarı

Aşağıdaki SQL Server ve Windows harmanlamaları System Center Operations Manager tarafından 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ılmamışsa yeni bir Operations Manager kurulumu gerçekleştirilemez. Ancak yerinde yükseltme başarıyla tamamlanır.

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.

Operations Manager veritabanları için yük devretme işlevselliği sağlamak için SQL Always On Kullanılabilirlik Gruplarını gerektirecek 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 tablo, Operations Manager yönetim grubunuzdaki sunucu rollerinin başarılı bir şekilde iletişim kurabilmesi için SQL Server'ın gerektirdiği güvenlik duvarı bağlantı noktalarını belirlemenize yardımcı olur.

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 ek 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

* 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 veriler aracılar tarafından toplanan tüm olaylardan, uyarılardan, durum değişikliklerinden ve performans verilerinden oluşur. Operations Manager veritabanı tarafından kullanılan kaynakların çoğu, sisteme geldiğinde bu verileri diske yazmak için kullanılır. Ek yönetim paketleri içeri aktarılıp ek aracılar eklendikçe toplanan işletimsel verilerin oranı artma eğilimindedir. Bir aracının izlediği bilgisayar türü, işletimsel veri toplamanın genel oranını belirlerken kullanılan önemli bir faktördür. Örneğin, iş açısından kritik bir masaüstü bilgisayarı izleyen bir aracının, çok sayıda veritabanı olan bir SQL Server örneğini çalıştıran bir sunucuyu izleyen bir aracıdan daha az veri toplaması beklenebilir.
• Örnek alanı değişikliklerinin oranı. Operations Manager veritabanında bu verilerin güncelleştirilmesi, yeni işletimsel veriler yazmaya göre maliyetlidir. Ayrıca, örnek alanı verileri değiştiğinde yönetim sunucuları yapılandırma ve grup değişikliklerini hesaplamak için Operations Manager veritabanında ek sorgular yapar. Ek yönetim paketlerini bir yönetim grubuna aktardıkça örnek alanı değişim hızı artar. Bir yönetim grubuna yeni aracılar eklemek, örnek alanı değişikliklerinin hızını da geçici olarak artırır.
• Aynı anda çalışan İşletim Konsollarının ve diğer SDK bağlantılarının sayısı. 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 farklılık gösterebilir. 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:

1. Aşağıdaki SQL sorgusunu çalıştırın:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Alanda görüntülenen is_broker_enabled değer 1 (bir) ise bu adımı atlayın. Aksi takdirde aşağıdaki SQL sorgularını ç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ı

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

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

• İşletimsel veri toplama oranı. Raporlama veri ambarı, daha verimli raporlamaya olanak sağlamak için sınırlı miktarda ham veriye ek olarak toplanan verileri hesaplar ve depolar. Bu ek çalışma, Raporlama veri ambarı için işlemsel veri toplama işleminin Operations Manager veritabanına göre biraz daha maliyetli olabileceği anlamına gelir. Bu ek maliyet genellikle Raporlama veri ambarı ile Operations Manager veritabanı arasındaki bulma verilerini işleme maliyetinin azalmasıyla dengelenmiş olur.
• Eşzamanlı raporlama kullanıcılarının veya zamanlanmış rapor oluşturmanın sayısı. Raporlar sık sık büyük hacimli verileri özetlediğinden, her raporlama kullanıcısı sisteme önemli bir yük ekleyebilir. Aynı anda çalıştırılan rapor sayısı ve çalıştırılan raporların türü genel kapasite gereksinimlerini etkiler. Genel olarak, büyük tarih aralıklarını veya çok sayıda nesneyi sorgulayan raporlar ek sistem kaynakları gerektirir.

Bu faktörlere bağlı olarak, Raporlama 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. Raporlama veri ambarı, yönetim grubu aracılığıyla genel veri akışının ayrılmaz bir parçası olduğundan, Raporlama 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, Raporlama 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 kılavuz Raporlama veri ambarı için de 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 Raporlama 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 Raporlama veri ambarından ayrı bir fiziksel birime ve disk iş akışlarına yerleştirmeniz gerekir. Operations Manager veritabanı ve Raporlama veri ambarı için veri dosyaları, birim yeterli kapasite sağladığı ve disk G/Ç performansı izleme ve raporlama işlevini olumsuz etkilemediği sürece aynı fiziksel birimi paylaşabilir.
• Raporlama 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 Raporlama 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 avantajlıdır. Raporlama 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ı tarafından 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.

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

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ğıtmanız ve küme düğümlerinde Always On'u etkinleştirmeniz gerekir. 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.

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 kullanılabilirlik grubuna sunucu düğümleri dağıttığınızda bu sınırlamayı geçici olarak çözmek için önerilen yaklaşım aşağıdakileri yapmaktır:

1. Kullanılabilirlik grubu dinleyicinizin ağ adını, DNS'de yalnızca tek bir etkin IP adresini kaydedecek şekilde ayarlayın.
2. 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 devretme yapıldığında küme adının yeni IP adresiyle daha hızlı kurtarılmasını ve çözümlenmesine olanak sağlar.

Ayarlarını 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 Always On

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

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. Bunu yapılandırma hakkında bilgi için aşağıdaki KB makalesine bakın: System Center Management hizmeti, SQL Server örneği çevrimdışı olduktan sonra yanıt vermeyi durduruyor.

SQL Server'ın iyileştirilmesi

Genel olarak, müşterilerle önceki dağıtım deneyimi performans sorunlarının genellikle SQL Server ile yüksek kaynak kullanımından (işlemci veya bellek) kaynaklanmadığını gösterir; bunun yerine 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 makalesi, bazı PowerShell kodlarıyla bu aracı kullanarak stres testi gerçekleştirme ve PerfMon kullanarak sonuçları yakalama hakkında ayrıntılı rehberlik ve öneriler sağlar. İlk yönergeler için Operations Manager Boyutlandırma Yardımcısı'na da başvurabilirsiniz.

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ılacak bölümü biçimlendirirken, veriler, günlükler ve tempdb için 64 KB ayırma birimi boyutu (65.536 bayt) kullanmanız ö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ılamamayla sonuçlandığını unutmayın. 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 üzeri RAM'e sahip sunucular için büyük olasılıkla 1 GB'tan düşük çalışmadığından emin olmak istersiniz.

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 alacak şekilde tasarlandığından ve genellikle mümkün olduğunca çok bellek kullanacağı için, 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şırsınız.

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 önler 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şmiş ö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ılanlardan 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 durum SQL Server'ın kısa süreler boyunca yanıt vermemesine de 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 sys.sysprocesses sorgusunu yürütürken daha önce vurgulandığı gibi benzer değerlere 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 etkin kalması için SQL Server'ın Başlangıç parametrelerinde -T1118 izleme bayrağını 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

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ınmamış 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ı, tekdüzen olmayan bir 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 olduğundan 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

  Not

  Bu yapılandırmada N, işlemci sayısını temsil eder.