SQL Server Tasarımı Konuları

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 grubunuzda ilk yönetim sunucusunu dağıttığınızda oluşturulur. ACS veritabanı, yönetim grubunuza bir ACS toplayıcısı dağıttığınızda oluşturulur.

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

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

Başka 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 Bir Windows makinesinde yüklü SQL Server örneğini 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

SQL Server Enterprise & Standard Edition'ın aşağıdaki 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üklemesinde desteklenir:

• SQL Server 2022

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

  Not

  • Operations Manager 2022, CU8 veya üzeri ile SQL 2019'un desteklemektedir; ancak SQL 2019 RTM'yi desteklemez.
  • ODBC 17.3 veya üzerini ve MSOLEDBSQL 18.2 veya üzerini kullanın.

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

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

Not

• Bir SCOM altyapısını destekleyen aşağıdaki SQL Server bileşenlerinin her birinin aynı SQL Server ana sürümde olması gerekir:
  • SCOM veritabanlarından herhangi birini barındıran veritabanı altyapısı örneklerini SQL Server (yani, 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.
• SQL Server SCOM veritabanlarından herhangi birini barındıran tüm SQL Server veritabanı altyapısı örnekleri için 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) windows server'ın hangi yükleme seçeneklerinin SQL Server tarafından desteklendiğine bağlıdı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 donanım ve yazılım ile ilgili ek konular var:

• NTFS dosya biçimine sahip bilgisayarlarda SQL Server ç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 zorunlu kılınmıştı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 sırasında 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 operations manager kurulumunun yeni bir kurulumu başarısız olur. Ancak, yerinde bir yükseltme başarıyla tamamlanır.

Güvenlik duvarı yapılandırması

Operations Manager, veritabanlarını barındırmak için SQL Server ve geçmiş işletimsel verileri analiz etmek ve sunmak için bir raporlama platformu kullanı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 kurması için SQL Server için izin verilmesi gereken 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 Adanmış 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 Sunucusunu 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 üzerinde adlandırılmış bir örnek oluşturduğunuzda veya sql AlwaysOn 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şime İzin Verecek Şekilde Yapılandırma.

Kapasite ve depolama ile ilgili önemli noktalar

Operations Manager veritabanı

Operations Manager veritabanı, günlük izleme görevleri için Operations Manager tarafından ihtiyaç duyulan tüm verileri içeren bir SQL Server veritabanıdır. Veritabanı sunucusunun boyutu ve yapılandırması yönetim grubunun genel performansı için kritik öneme sahiptir. Operations Manager veritabanı tarafından kullanılan en kritik kaynak depolama alt sistemidir, ancak CPU ve RAM de önemlidir.

Operations Manager veritabanı üzerindeki yükü etkileyen faktörler aşağıdakileri içerir:

• İşlemsel veri toplama hızı. İşletimsel veriler aracıların topladığı tüm olaylar, uyarılar, durum değişiklikleri ve performans verilerinden oluşur. Operations Manager veritabanı tarafından kullanılan kaynakların çoğu bu veriler sisteme geldikçe diske yazmak için kullanılır. İşletimsel veri toplama hızı, ek yönetim paketleri içeri aktarıldıkça ve ek aracılar eklendikçe artma eğilimi gösterir. Aracının izlediği bilgisayar türü de işletimsel veri toplama genel hızı belirlenirken kullanılan önemli bir faktördür. Örneğin, iş kritik bir masaüstü bilgisayarı izleyen bir aracının çok sayıda veritabanı içeren bir SQL Server örneği çalıştıran bir sunucuyu izleyen bir aracıdan daha az veri toplaması beklenir.
• Örnek alanı değişiklik hızı. Operations Manager veritabanında bu verilerin güncelleştirilmesi yeni işletimsel veriler yazmaya göre daha fazla 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ına ek sorgular gönderirler. Ek yönetim paketleri bir yönetim grubuna içeri aktarıldıkça örnek alanı değişiklik hızı artar. Bir yönetim grubuna yeni aracılar eklemek de örnek alanı değişiklik hızını geçici olarak artırır.
• Aynı anda çalışan İşletim Konsolu ve diğer SDK bağlantıları sayısı. Her İşletim konsolu Operations Manager veritabanından verileri okur. Bu verilerin sorgulanması potansiyel olarak büyük depolama G/Ç kaynakları, 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ü içinde yüksek miktarda işletimsel veri görüntüleyen işletim konsolları genellikle veritabanı üzerindeki yükün en büyük bölümüne neden olur.

Operations Manager veritabanı yönetim grubu için tekli bir başarısızlık kaynağıdır, bu nedenle SQL Server Always On Kullanılabilirlik Grupları veya Yük Devretme Kümeleme Örnekleri gibi desteklenen yük devretme yapılandırmaları kullanılarak yüksek kullanılabilirlik sağlanabilir.

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

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

System Center Operations Manager, tüm görev işlemlerini uygulamak 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'da 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 neredeyse gerçek zamanlı olarak Raporlama veri ambarına veri ekler. Bu sunucuda, toplanan tüm verilerin Raporlama veri ambarına yazılmasını destekleyen yeterli kapasiteye sahip olmak önemlidir. Operations Manager veritabanı ile benzer şekilde, Raporlama veri ambarındaki en kritik kaynak depolama G/Ç alt sistemidir. Çoğu sistemdeki Raporlama veri ambarı yükleri Operations Manager veritabanına benzer ancak farklılık gösterebilir. Ayrıca, Raporlama veri ambarı tarafından raporlanarak oluşturulan yük, Operations Manager veritabanında İşletim konsolu kullanımı ile oluşan yükten farklıdır.

Raporlama veri ambarı yükünü etkileyen faktörler şunları içerir:

• İşlemsel veri toplama hızı. Daha verimli raporlama sağlamak için Raporlama veri ambarı sınırlı bir miktar ham veriye ek olarak toplanan verileri hesaplar ve depolar. Bu ek işin yapılması, işletimsel verilerin Raporlama veri ambarında toplanmasının Operations Manager veritabanına göre biraz daha yüksek maliyetli olabileceği anlamına gelir. Bu ek maliyet genellikle Raporlama veri ambarının Operations Manager veritabanına göre bulma verilerini işleme maliyetinin daha düşük olmasıyla dengelenir.
• Eş zamanlı rapor veren kullanıcılar veya zamanlanmış rapor oluşturma. Raporlar genellikle yüksek veri hacimlerini özetlediğinden, rapor gönderen her kullanıcı sisteme önemli bir yük ekleyebilir. Aynı anda çalıştırılan rapor sayısı ve çalıştırılan rapor türü genel kapasite ihtiyaçlarını etkiler. Genellikle geniş veri aralıklarını sorgulayan veya çok sayıda nesne içeren raporlar ek sistem kaynakları gerektirir.

Bu faktörlere bağlı olarak, Raporlama veri ambarını boyutlandırırken dikkate alınması önerilen birkaç uygulama vardır:

• Uygun bir depolama alt sistemi seçin. Raporlama veri ambarı, yönetim grubundaki 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çimdir. Genel olarak, Raporlama ver ambarı için alt depolama sistemi Operations Manager veritabanı için alt sisteme benzer olmalıdır ve Operations Manager veritabanı için geçerli olan yönergeler ayrıca Raporlama veri ambarı için de geçerlidir.
• Veri günlükleri 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. Operations Manager veritabanı ve Raporlama veri ambarı aynı sunucuda bulunuyorsa ve veriler ile işlem günlüklerinizi ayırmak istiyorsanız, Raporlama veri ambarının bu durumdan yararlanması için Operations Manager veritabanı işlem günlüklerini ayrı bir fiziksel birime yerleştirmeniz gerekir. Birim yeterli kapasite sağladığı ve disk G/Ç performansı izleme ve raporlama işlevselliğini olumsuz etkilemediği sürece Operations Manager veritabanı ve Raporlama veri ambarı için veri dosyaları aynı fiziksel birimi paylaşabilir.
• Raporlama veri ambarını Operations Manager veritabanından ayrı bir sunucuya yerleştirmeyi düşünün. 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 tekli bir başarısızlık kaynağıdır, bu nedenle SQL Server Always On Kullanılabilirlik Grupları veya Yük Devretme Kümeleme Örnekleri gibi desteklenen yük devretme yapılandırmaları kullanılarak yüksek kullanılabilirlik sağlanabilir.

SQL Server Always On

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 bir 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 Always On tercih edilir. Kalıcı veri depolamayı geçici depolama gereksinimlerinden ayırmak için iki veritabanı kullanan yerel mod Raporlama Hizmetleri yüklemesi hariç, tüm veritabanları bir Always On 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 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. Daha sonra Operations Manager SQL Server veritabanını bir 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üğümlerinde Operations Manager'ı dağıttığınızda, CLR sıkı güvenliğini etkinleştirmek için her Operations Manager veritabanında SQL betiğini çalıştırın.

Çok abonelikli dize

Operations Manager bağlantı dizesi anahtar sözcükleri (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, 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'u 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. Bunun nasıl yapılandırılması hakkında bilgi için, system center yönetim hizmeti bir SQL Server örneği çevrimdışı olduktan sonra yanıt vermeyi durduruyor başlıklı aşağıdaki KB makalesine bakın.

SQL Server’ı en iyi duruma getirme

Genel olarak, müşterilerle önceki dağıtım deneyimi performans sorunlarının genellikle SQL Server yüksek kaynak kullanımından (işlemci veya bellek) kaynaklanmadığını, bunun yerine doğrudan depolama alt sisteminin yapılandırmasıyla ilgili olduğunu gösterir. Performans sorunları genellikle SQL Server veritabanı örneği için sağlanan depolama alanıyla ilgili önerilen yapılandırma yönergelerini takip etmemeye bağlanır. Bu tür örnekler şunlardır:

• Operations Manager’ın G/Ç gereksinimlerini desteklemek üzere LUN’lar için yetersiz iğne ayırma.
• İşlem günlükleri 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ı göz ardı edilir.

Depolama yapılandırması Operations Manager için bir SQL Server dağıtımının en kritik bileşenlerinden biridir. Veritabanı sunucuları ayrıntılı veritabanı okuma ve yazma etkinliği ve işlem günlüklerinin işlenmesi nedeniyle G/Ç yoğun 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 edilir 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 kabul edilebilir bir gecikme süresiyle GÇ gereksinimlerinize 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, bu aracı powershell koduyla 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

Genellikle bölüm ayırma olarak adlandırılan birim ayırma, bir RAID cihaz üzerinde bir birim oluşturulduğunda dosya sistemi (NTFS) üzerinde gerçekleştirilmelidir. Bunun yapılmaması önemli performans düşüşlerine yol açabilir ve en yaygın olarak şerit 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 yol açabilir. 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ış birimlerde salt okunur verileri destekler ancak bu önerilmez.

Bellek ayırma

Not

Bu bölümdeki bilgilerin çoğu Jonathan Kehayias'ın blog gönderisindeki SQL Server 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 ayırmak için doğru miktarda fiziksel bellek ve işlemciyi 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 bellek gereksinimlerini kullanılabilir sistem kaynaklarına göre dinamik olarak değiştirebilir. En düşük sunucu belleği için varsayılan ayar 0 ve maksimum 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 ayırmanız gereken belleği etkiler. Yeterli bellek ayarlanmazsa işletim sistemi ve SQL diske sayfalanır. Bu, disk G/Ç'nin artmasına, performansın daha da düşmesine ve Operations Manager'da fark edilebilir hale geldiği bir dalgalanma etkisine 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üklü her 4 GB RAM başına 1 GB RAM (16 GB'a kadar RAM)
• Yüklü her 8 GB RAM başına 1 GB RAM (16 GB RAM'in üzerinde)

Bu değerleri ayarladıktan sonra, SQL Server için kullanılabilir belleği artırabileceğinizi belirlemek için Windows'ta Memory\Available MBytes sayacını izleyin. Windows kullanılabilir fiziksel belleğin 96 MB'de azaldığını gösterir, 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 büyük olasılıkla 1 GB'tan düşük çalışmadığından emin olmak istersiniz.

Bu hesaplamalarda, diğer uygulamaları dikkate almak için değiştirmediğiniz sürece SQL Server tüm kullanılabilir belleği kullanabilmesini istediğinizi varsayalım. İşletim sisteminiz, diğer uygulamalar, SQL Server iş parçacığı yığını ve diğer çok sayfalı ayırıcılar için belirli bellek gereksinimlerini göz önünde bulundurun. Tipik bir formül , ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))burada iş parçacığı yığını için bellek = ((max worker threads) (stack size))olur. 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 maksimum çalışan iş parçacıklarının değerini sys.dm_os_sys_info max_worker_count sütununda bulabilirsiniz.

Bu noktalar, SQL Server sanal makinede çalıştırılması 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, sonunda daha düşük bellek ayırmanın daha yüksek disk G/Ç erişimiyle takas edildiği bir noktaya ulaşırsınız.

Aşırı sağlanmış bir ortamda SQL Server belleği yapılandırmak için ortamı ve SQL Server Arabellek Yöneticisi sayfa ömrü beklentisi ve sayfa okuma/sn ve Fiziksel Disk disk okuma/sn değerleri dahil olmak üzere 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 her saniye bir değer artacaktır; önbellek artırıldıktan sonra SQL Server Arabellek Yöneticisi sayfasının 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ğine bakabilirsiniz (ilk önbellek boşaltma alt düzeylerinden sonra). Ölçümler kabul edilebilir durumda kalırsa, 1 GB daha azaltın, ardından ideal yapılandırmayı belirleyene kadar istediğiniz şekilde tekrarlayarak yeniden izleyin.

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

TempDB’yi en iyi duruma getirme

Tempdb veritabanının boyutu ve fiziksel yerleşimi Operations Manager’ın performansını etkileyebilir. Örneğin, tempdb için belirlenen sayı çok küçükse, SQL Server örneğini her yeniden başlattığınızda sistem işlem yükünün bir bölümü tempdb’nin iş yükünü desteklemek için gerekli boyuta kadar otomatik olarak büyütülmesine harcanabilir. En iyi tempdb performansı için üretim ortamında tempdb için aşağıdaki yapılandırmayı öneririz:

• tempdb kurtarma modelini BASİT 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ü destekleyebilecek kadar büyük bir değer olarak 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 genişletilmek için ayarlanabilir, ancak bu planlanmamış özel durumlarda disk alanını artırmak için kullanılmalıdır.
• Disk bant genişliğini en üst düzeye çıkarmak için gereken sayıda 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 yükünü artırabileceği için çok fazla dosya oluşturmayın. Genel bir kılavuz olarak, sunucudaki her mantıksal işlemci için bir veri dosyası oluşturun (benzeşim maskesi ayarlarını hesaba katarak) ve ardından dosya sayısını gerektiği şekilde artırın veya azaltın. Genel bir kural olarak, mantıksal işlemci sayısı 8 veya daha azsa, mantıksal işlemci sayısı kadar 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ılmıyorsa, veri dosyalarının sayısını daha fazla artırmanız gerekebilir.
• Her veri dosyasını aynı boyuta getirerek en uygun orantılı doldurma performansını elde edin. Orantılı dolgu algoritması dosyaların boyutuna bağlı olduğu için veri dosyalarının eşit boyutta olması kritiktir. Veri dosyaları eşit olmayan boyutlarda oluşturulursa, orantılı dolgu algoritması ayırmaları tüm dosyalar arasında yaymak yerine daha fazla GAM ayırması için en büyük dosyayı kullanır ve birden çok veri dosyası oluşturulmuş olmasını anlamsız hale getirir.
• En iyi performans için katı hal sürücülerini kullanarak tempdb veritabanını hızlı bir G/Ç alt sistemine yerleştirin. Çok sayıda eklenmiş disk varsa disk bölümlemesi kullanın.
• Tempdb veritabanını kullanıcı veritabanları için kullanılan disklerden ayrı disklere yerleştirin.

Tempdb’yi yapılandırmak için aşağıdaki sorgusu ç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 SQL Server’ın kısa sürelerle yanıt vermiyor gibi görünmesine neden olabilir. Diğer bir yaklaşım Dinamik Yönetim Görünümlerini [sys.dm_exec_request or 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 için Başlangıç parametrelerinde -T1118 izleme bayrağını uygulayın. Bu izleme bayrağı altında, SQL Server her bir veritabanı nesnesine tam kapsam ayırarak SGAM sayfalarındaki çekişmeyi giderir.

Not

Bu izleme bayrağı, SQL Server örneğindeki her veritabanını etkiler.

Maksimum paralellik derecesi

Küçük ve orta boyutta Operations Manager dağıtımları için varsayılan SQL Server yapılandırması çoğu ihtiyaç 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 doğru ö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ınmadığı bir yapılandırma seçeneği MAXDOP'dur.

Microsoft SQL Server maksimum paralellik derecesi (MAXDOP) yapılandırma seçeneği, paralel bir plandaki bir sorgunun yürütülmesinde 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 işleme ve iş parçacığı kaynaklarını belirler. SQL Server bir simetrik çok işlemcili (SMP) bilgisayarda mı, tekdüzen olmayan bellek erişimi (NUMA) bilgisayarında mı yoksa hiper iş parçacığı özellikli işlemcilerde mi ayarlandıysa, 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, en iyi paralellik derecesini, yani her paralel plan yürütme için tek bir deyim çalıştırmak üzere kullanılan işlemci sayısını algılar. Varsayılan olarak, bu seçenek için değeri 0’dır, bu maksimum paralellik derecesini SQL Server’ın belirlemesine izin verir.

İşletimsel, 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. Yükleme sırasında işletim sistemine sunulan işlemci sayısını 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çlar doğurabilir.

Not

En yüksek paralellik derecesi yapılandırma seçeneği, SQL Server kullandığı işlemci sayısını sınırlamaz. SQL Server’ın kullandığı işlemci sayısını yapılandırmak için benzeş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.