Table of contents
TOC
İçindekiler tablosunu daralt
İçindekiler tablosunu genişlet

SQL Server Tasarımı Konuları

Matt Goedtel|Son Güncellenme Tarihi: 24.04.2017
|
1 Katkıda Bulunan

Uygulama Hedefi: System Center 2016 - Operations Manager

System Center 2016 - Operations Manager’ın, işletimsel veritabanını, veri ambarı veritabanını ve ACS denetim veritabanını desteklemesi için Microsoft SQL Server 2012, 2014 veya SQL Server 2016 çalıştıran bir sunucu örneğine erişebilmesi gerekir. İş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.

SQL Server gereksinimleri

Aşağıdaki SQL Server sürümleri yeni veya mevcut Operations Manager yüklemeleri için desteklenir.

BileşenSQL Server 2012, SP3 Enterprise/Standard (x64)SQL Server 2014, SP2 Enterprise/Standart (x64)SQL Server 2016 Enterprise/Standart (x64)
Operations Manager İşletimsel Veritabanıevetevetevet
Operations Manager Veri Ambarı Veritabanıevetevetevet
Operations Manager ACS Veritabanıevetevetevet
Operations Manager Raporlama Sunucusuevetevetevet
Not

System Center 2016 – Operations Manager veritabanları aynı SQL Server sürümünü kullanmalıdır, SQL Server harmanlama ayarı bu bölümde açıklandığı gibi aşağıdaki desteklenen türlerden biri olmalıdır ve SQL Server Tam Metin Arama işletimsel ve veri ambarı veritabanları için gereklidir. Operations Manager veritabanı bileşenleri tarafından desteklenen Windows Server 2016 yükleme seçenekleri (Server Core, Masaüstü Deneyimi sunan Server ve Nano Server), hangi Windows Server yükleme seçeneklerinin SQL Server tarafından desteklendiğine bağlıdır.

Not

System Center 2016 – Operations Manager Raporlama, System Center Operations Manager 2012 R2 Raporlama ile yan yana yüklenemez ve yalnızca yerel modda yüklenmesi gerekir. (SharePoint tümleşik modu desteklenmiyor.)

Tasarım planlamanızda donanım ve yazılım ile ilgili ek konular var:

  • NTFS dosya biçimine sahip bilgisayarlarda SQL Server 2012, 2014 ve 2016 çalıştırmanızı öneririz.
  • İşletimsel ve veri ambarı veritabanı için en az 1024 MB boş disk alanı olmalıdır. Bu, veritabanı oluşturulurken zorunlu kılınır ve kurulumdan sonra önemli oranda artma ihtimali bulunur.
  • .NET Framework 4 gereklidir.
  • Windows Server Core’da Raporlama Sunucusu desteklenmez.

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

Not

İşletimsel veritabanını ilk kez yüklerken, Operations Manager işletimsel veritabanını barındıran SQL Server’da yalnızca Windows Kimlik Doğrulaması kullanın. İşletimsel veritabanının ilk yüklemesinde SQL Server Kimlik Doğrulamasının kullanılması sorunlara yol açabileceğinden Karma Mod (Windows Kimlik Doğrulaması ve SQL Server Kimlik Doğrulaması) kullanmayın. Operations Manager işletimsel veritabanını barındıran SQL Server üzerinde Karma Mod güvenliği etkinleştirilebilmekle birlikte, veritabanı ile tüm temas sadece Windows hesapları kullanılarak gerçekleştirildiğinden desteklenmez.

SQL Server harmanlama ayarı

Aşağıdaki SQL Server ve Windows harmanlamaları System Center 2016 - Operations Manager tarafından desteklenir.

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ğinizin daha önce listelenen desteklenen harmanlamalardan biri ile yapılandırılmamış olması durumunda, yeni Operations Manager kurulumu gerçekleştirmenin başarısız olacağını unutmayın. 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 yolları ve bağlantı noktalarını anlamak önemlidir.

Operations Manager veritabanları için yük devretme işlevi sağlamak için SQL Always On Kullanılabilirlik Grupları’nı gerektiren bir dağıtım tasarlıyorsanız, güvenlik duvarı güvenliği 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.

SenaryoBağlantı NoktasıYönOperations Manager Rolü
Operations Manager veritabanlarını barındıran SQL ServerTCP 1433 *Gelenyönetim sunucusu ve Web konsolu (Uygulama Danışmanı ve Uygulama Tanılama için)
SQL Server Browser hizmetiUDP 1434Gelenyönetim sunucusu
SQL Server Adanmış Yönetici BağlantısıTCP 1434Gelenyönetim sunucusu
SQL Server Always On Kullanılabilirlik Grubu DinleyicisiYönetici tarafından yapılandırılan bağlantı noktasıGelenyönetim sunucusu
Operations Manager Raporlama Sunucusunu barındıran SQL Server Reporting ServicesTCP 80 (varsayılan)/443 (SSL)Gelenyönetim sunucusu ve İşletim konsolu

* Varsayılan Veritabanı Altyapısı için standart bağlantı noktası TCP 1433 olsa da, tek başına bir SQL Server’da adlandırılmış bir örnek oluşturursanız veya bir SQL Always On Kullanılabilirlik Grubu dağıttıysanız, özel bir bağlantı noktası tanımlanır ve kurulum sırasında güvenlik duvarlarınızı doğru bir şekilde yapılandırmanız ve bu bilgileri girmeniz için başvuru olarak belgelenmelidir.

SQL Server için güvenlik duvarı gereksinimlerine daha detaylı bir bakış için bkz.SQL Server Erişimine İzin Vermek için Windows Güvenlik Duvarı’nı 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 veri ambarı veritabanı

System Center 2016 – Operations Manager verileri neredeyse gerçek zamanda Raporlama veri ambarına yerleştirir, Raporlama veri ambarında toplanan tüm bu verileri yazmayı destekleyen bu sunucunun yeterli kapasiteye sahip olması önemlidir. Operations Manager veritabanı ile benzer şekilde, Raporlama veri ambarındaki en kritik kaynak depolama G/Ç alt sistemidir. Çoğu sistemde, Raporlama veri ambarındaki yükler Operations Manager veritabanındakilere benzer ancak farklı olabilir. 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 etkenlere bağlı olarak, Raporlama veri ambarı için boyutlandırma yaparken dikkate alınması gereken birkaç en iyi yöntem vardır:

  • Uygun bir depolama alt sistemi seçin. Raporlama veri ambarı, yönetim grubu içindeki genel veri akışının ayrılmaz bir parçasıdır. Raporlama verileri için uygun bir depolama alt sistemi seçmek çok ö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ı için aracı sayısı arttıkça SQL verileri ile 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/G performansı izleme ve raporlama işlevselliğini 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 Operations Manager veritabanı ve Raporlama veri ambarını aynı sunucuda barındırabilse de, aracı sayısı ve gelen işletimsel veri hacmi arttıkça bunları birbirinden ayırmak daha avantajlıdır. Bunun nedeni Raporlama veri ambarı ve Raporlama Sunucusu Operations Manager veritabanından ayrı bir sunucuda olduğunda daha iyi raporlama performansı alınmasıdır.

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 - Operations Manager ile, veritabanları için yüksek kullanılabilirlik sunmak üzere SQL Always On yük devretme kümelemesine 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.

Bir kullanılabilirlik grubu ayarlamak için kullanılabilirlik çoğaltmasını barındırmak üzere 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.

SQL Server’ı en iyi duruma getirme

Genel olarak, müşterilerle önceki dağıtım deneyimleri performans sorunlarının SQL Server’ın kendisinden kaynaklanan yüksek kaynak kullanımından (yani işlemci veya bellek) kaynaklanmadığını gösteriyor. Bu sorunlar doğrudan depolama alt sisteminin yapılandırılması ile ilgilidir. Bun genellikle SQL Server veritabanı örneği için sağlanan depolama için önerilen yapılandırma kılavuzlarına uymama nedeniyle gerçekleşir.
Bu duruma örnekler,

  • 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ü çok farklı G/Ç ve gecikme karakterlerine sahiptir.
  • TempDB yapılandırması yerleşim, boyut vb. nedeniyle yanlış.
  • Veritabanı işlem günlükleri, veritabanı dosyaları ve TempDB’yi barındıran birimlerde disk bölümünün yanlış hizalanması
  • Veritabanı ve işlem günlük dosyaları için AUTOGROW ve sorgu paralelliği için MAXDOP kullanmak, CPU çekirdeği başına birden fazla TempDB veri dosyası oluşturmak vb. temel SQL Server yapılandırmasını ihmal etmek.

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ış deseni genellikle %80 yazma ve %20 okumadır. Sonuç olarak, G/Ç alt sistemlerinin hatalı yapılandırılması SQL Server sistemlerinin kötü performans göstermesine neden olabilir ve Operations Manager’da oldukça belirgin olur.

SQL Server dağıtılmadan önce G/Ç alt sisteminin çıkış testi gerçekleştirilerek SQL Server tasarımını test etmek çok önemlidir. Bu testlerin kabul edilebilir bir gecikme süresiyle G/Ç gereksinimlerinizi karşıladığından emin olun. SQL Server’ı destekleyen depolama alt sisteminin G/Ç kapasitesini belirlemek için SQLIO disk alt sistemi ölçme aracını kullanın. Ürün grubundaki File Server ekibinin bir üyesi tarafından yazılmış aşağıdaki blog makalesi, bu aracın bazı PowerShell kodlarıyla stres testi gerçekleştirmek için nasıl kullanılacağı ve sonuçların PerfMon kullanarak nasıl yakalanacağı hakkında çok ayrıntılı yönerge ve öneriler içerir. Başlangıç düzeyi bir kılavuz 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 bir performans düşüşüne neden olabilir. Bu genellikle bölümün şerit birim sınırlarıyla hatalı hizalanması sonucunda oluşur. Bu ayrıca donanım önbelleğinin hatalı hizalanmasına neden olarak dizi önbelleğinin yetersiz kullanımına yol açabilir. SQL Server veri dosyaları için kullanılacak bölüm biçimlendirilirken, veriler, günlükler ve tempdb için 64 KB ayırma birim boyut (yani 65.536 bayt) kullanmanız önerilir. Ancak 4 KB’den daha büyük ayırma birimlerinin kullanılmasının birim üzerinde NTFS sıkıştırmasının kullanılamamasına neden olacağını unutmayın. SQL Server sıkıştırılmış birimlerde salt okunur verileri desteklese de bu önerilmez.

Bellek ayırma

System Center 2016 - Operations Manager’ı desteklemek üzere SQL Server 2014 ve 2016 için Windows Server’a ayrılması gereken doğru fiziksel bellek miktarını belirlemek yanıtlaması kolay bir soru değildir (bu, bu ürün dışındaki iş yükleri için bile geçerlidir). Ürün grubu tarafından sağlanan boyutlandırma hesaplayıcı, gerçek dünyadaki tipik iş yükleri ve yapılandırmalara uygun olabilen veya olmayabilen bir laboratuvar ortamında gerçekleştiren testler temel alınarak oluşturulmuştur ve iş yükü ölçeğini (yani 500 sistem, 1000 sistem vb.) temel alarak kılavuz sağlar, ancak sonucun bütünlüğü genellikle şüphelidir. Başlangıç için bir ilk öneri sunar ancak son yapılandırma değildir ve bu şekilde değerlendirilemez.

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 varsayılanı 0 ve en yüksek sunucu belleği varsayılanı 2147483647’dir. En yüksek sunucu belleği için belirtebileceğiniz en düşük bellek miktarı 16 megabayt’tır (MB). Performans ve bellekle ilgili sorunlardan bazıları müşterilerin En Yüksek Sunucu Belleği değerini ayarlamamasından kaynaklanır. Müşteriler burada ne ayarlayacaklarını bilmedikleri için bir değer ayarlamaz. Birkaç diğer faktör daha SQL’e ayırdığınız maksimum bellek miktarını etkileyerek işletim sisteminin bu sistemde çalışan HBA kartı, yönetim aracıları, virüsten koruma gerçek zamanlı tarama vb. diğer işlemleri desteklemek için yeterli bellek bulunmasını sağlar. Aksi takdirde, işletim sistemi ve SQL diske uyarı gönderir ve disk G/Ç artar, bu da performansı daha da azaltarak Operations Manager’da hissedilebilen bir dalga etkisine neden olur.

SQL Server, ayrılması ve işlemleri tarafından kullanılması gereken en düşük ve en yüksek bellek miktarını yapılandırmanıza olanak sağlar. En düşük miktar olarak en az 4 GB RAM belirtmeniz önerilir. Bu, Operations Manager veritabanlarından birini (İşletimsel, Veri ambarı, ACS) barındıran her bir SQL düğümü için yapılmalıdır.

İşletim sistemi için 1 GB RAM, 4-16 GB arasında yüklü her 4 GB RAM için 1 GB ve 16 GB’den itibaren yüklü her 8 GB RAM için 1 GB ayırarak başlamanız önerilir. Daha sonra SQL Server’a ayrılabilecek bellek miktarının başlangıç değerinin üzerine çıkarıp çıkaramayacağınızı öğrenmek için Windows’da Bellek\Kullanılabilir MBayt performans sayacını izleyin. (Not: Bu sayaç en az 150-300 MB’nin üzerinde kalmalıdır, Windows 96 MB’de LowMemoryResourceNotification sinyali gönderir ve bu değerle bir ara bölge oluşturmak isteyebilirsiniz. 256 GB veya daha yüksek RAM’e sahip daha büyük sunucularda 1 GB’den yukarıda başlamayı düşünün). Bu genellikle SQL Server için ayrılmış sunucular için işe yarar. Ayrıca 'en yüksek sunucu belleği' değerini belirlemek için işletim sistemi, diğer uygulamalar, SQL Server iş parçacığı yığını ve diğer çok sayfalı ayırıcılar için belirli bellek gereksinimlerini hesaplayarak daha teknik bir değere ulaşabilirsiniz. Bu genellikle şöyledir: ((Toplam sistem belleği) – (iş parçacığı yığını için bellek) – (işletim sistemi bellek gereksinimleri ~ 2-4 GB) – (diğer uygulamalar için bellek) – (çok sayfalı ayırmalar için bellek; SQLCLR, bağlı sunucular, vb.)), iş parçacığı yığını için bellek = ((en fazla çalışan iş parçacığı sayısı) *(yığın boyutu)) yığın boyutu x86 sistemler için 512 KB, x64 sistemler için 2 MB ve IA64 sistemler için 4 MB’dir. 'max worker threads' değeri sys.dm_os_sys_info öğesinin max_worker_count column sütununda bulunabilir. Ancak, bu yöntemler diğer uygulamalar için hesaplamalarınızda ayırmalar yapmadıysanız makinede kullanılabilir olan tüm kaynakları SQL Server’ın kullanmasını istediğinizi varsayar.

Giderek daha fazla müşteri ortamlarında SQL Server’ı sanallaştırmaya yönelirken, bu soru SQL Server’ın bir sanal makinede çalışmak için ihtiyaç duyacağı en düşük bellek miktarını belirleme konusunda her zamankinden daha geçerlidir. SQL Server verileri arabellek havuzunda önbelleğe almak için tasarlandığından ve genellikle ayırdığınız belleğin tamamını kullanacağından, ne yazık ki belirli bir SQL Server örneği için ideal bellek miktarının ne olduğunu hesaplamanın bir yolu yoktur. Bir SQL Server örneğine ayrılan bellek miktarını azaltmayı düşünürken göz önünde bulundurmanız gereken şeylerden biri, sonunda daha düşük belleğin daha yüksek G/Ç erişimi ile değişeceği bir noktaya ulaşacak olmanızdır.

Aşırı sağlanmış bir ortamda SQL Server belleği için ideal yapılandırmayı bulmanız gerekiyorsa, bunu denemenin en iyi yolu ortamın taban çizgisi ve geçerli performans ölçümleriyle başlamaktır. İzlemeye başlayabileceğiniz sayaçlar aşağıdakileri içerir:

  • SQL Server:Buffer Manager\Page Life Expectancy
  • SQL Server:Buffer Manager\Page reads/sec
  • Physical Disk\Disk Reads/sec

Genellikle ortamda arabellek havuzu için fazla bellek varsa, Sayfa Ömrü değeri her saniye bir değerinde artar ve tüm veri sayfaları önbelleğe alındığı için iş yükünün altına düşmez. Aynı zamanda, SQL Server:Buffer Manager\Page reads/sec sayısı önbellek artışı gerçekleştikten sonra düşük olur, bu da düşük bir Physical Disk\Disk Reads/sec değerine karşılık gelir.

Ortamınız için taban çizgisini öğrendiğinizde, arabellek havuzunun boyutunu 1 GB düşürmek için sp_configure 'max server memory' seçeneğinde değişiklik yapın ve ardından ortamda RECONFIGURE çalıştırıldıktan sonraki ilk önbellek temizlemesinden sonra değerler sabitlendiğinde performans sayaçlarındaki etkiyi izleyin. Sayfa Ömrü değeri ortamınız için kabul edilebilir kalırsa (sabit >= 300 değerinin fazla miktarda RAM yüklü sunucular için abartılı olacağını aklınızda bulundurun) ve SQL Server:Buffer Manager\Page reads/sec sayısı disk G/Ç alt sisteminin performans düşüşü olmadan destekleyebileceği bir aralıktaysa 'max server memory' için sp_configure value değerini 1 GB düşürün ve değişikliğin ortamdaki etkisini izlemeye devam edin.

Ayrıca SQL 2014 için MSDN kılavuzuna da başvurabilirsiniz.

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. Bu, tempdb’nin çok sık genişleyerek performans sorunlarına neden olmasını önler. 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 fazla dosya kullanmak tempdb depolama çekişmesini azaltır ve önemli ölçüde daha iyi ölçeklenebilirlik sağlar. Ancak, performansı azaltabileceğ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 fazlaysa, 8 veri dosyası kullanın ve çekişme devam ederse çekişme kabul edilebilir düzeylere inene veya iş yükü/kodda değişiklik yapılana kadar veri dosyası sayısını 4’ün katları olarak artırın (en fazla mantıksal işlemci sayısı kadar). Çekişme azalmıyorsa, veri dosyalarının sayısını daha fazla artırmanız gerekebilir.
  • Tüm veri dosyalarını aynı boyutta yapın, bu en iyi orantılı dolgu performansını sağlar. 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şmesini algılamak için sys.sysprocesses öğesinden SELECT * T-SQL sorgusunu çalıştırın. Sistem tablosu çıkışında, waitresource "2:1:1" (PFS Sayfası) veya "2:1:3" (Paylaşılan Genel Ayırma Haritası 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örevin tempdb kaynaklarını beklediğini ve sys.sysprocesses sorgusunu yürüttüğünüzde önceden vurgulanan değerler ile benzer değerlere sahip olduğunu gösterir.
Önceki öneriler ayırma çekişmesini önemli ölçüde azaltmıyorsa ve çekişme SGAM sayfalarında yaşanıyorsa, SQL Server için Başlangıç parametrelerinde SQL Server geri yüklendikten sonra bile izleme bayrağı kalacak şekilde -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. Bu izleme bayrağının SQL Server örneğindeki tüm veritabanlarını etkilediğini unutmayın.

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ü artarak kurumsal sınıf senaryoya yaklaştıkça (genellikle 2000’den fazla aracı tarafından yönetilen sistemler ve gelişmiş sentetik işlemler, ağ cihazı izleme, platformlar arası vb. içeren hizmet düzeyi izleme), SQL Server yapılandırmasını belgenin bu bölümünde açıklandığı şekilde en iyi duruma getirmek gerekir. Kılavuzun önceki bölümlerinde açıklanmayan bir yapılandırma seçeneği MAXDOP’tur.

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’ın simetrik çoklu işlem (SMP) bilgisayarı, tekdüzen olmayan bellek erişimi (NUMA) bilgisayarı veya hiper iş parçacıklı işlemciler üzerinde kurulup kurulmadığına bağlı olarak, maksimum paralellik derecesini uygun bir ş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.

Operations Manager’da işletimsel, veri ambarı ve hatta denetim veritabanları için önceden tanımlı saklı yordamlar ve sorgular MAXDOP seçeneğini içermez çünkü yükleme sırasında işletim sistemine kaç işlemci sunulduğunu dinamik olarak sorgulamanın bir yolu yoktur ve sorgu yürütüldüğünde olumsuz etkileri olabileceği için bu ayar için değer sabit kodlanmamıştır.

Not

Maksimum paralellik derecesi yapılandırma seçeneği SQL Server’ın kullandığı işlemci sayısını kısıtlamaz. 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 Bu yapılandırmada, N işlemci sayısını gösterir.
  • NUMA yapılandırılmış sunucular için MAXDOP her bir NUMA düğümüne atanan CPU sayısını aşmamalıdır.
  • Hiper iş parçacıklı sunucular için MAXDOP değeri fiziksel işlemcilerin sayısını aşmamalıdır.
  • NUMA yapılandırılmış ve hiper iş parçacıklı sunucular için MAXDOP değeri NUMA düğümü başına fiziksel işlemcilerin sayısını aşmamalıdır.

Paralel çalışanların sayısını sys.dm_os_tasks sorgusunu çalıştırarak öğrenebilirsiniz.
Beş bin Windows aracıyla yönetilen sistemi kapsayan birden fazla veri merkezli iş yükünü izleyen bir müşteri Operations Manager 2012 dağıtımında, işletimsel veritabanını barındıran SQL Server örneği önemli performans düşüşleri gösteriyordu. Bu sunucunun donanım yapılandırması 24 çekirdekli işlemci ve 196 GB RAM ile bir HP Blade G6’dır. OperationsManager veritabanını barındıran örnekte MAXMEM 64 GB olarak ayarlanmıştır. Bu bölümde önerilen iyileştirmeler uygulandıktan sonra genel performans iyileşti, ancak sorgu paralelliğinde performans sorunları devam ediyordu. Farklı değerler test edildikten sonra en iyi performansın MAXDOP=4 ayarıyla elde edildiği belirlendi.

Başlangıç veritabanı boyutu

Operations Manager veritabanlarının, özellikle de işletimsel ve veri ambarı veritabanlarının dağıtımdan sonra birkaç ay içinde gelecekteki büyüyüşünü tahmin etmek kolay değildir. Operations Manager Boyutlandırma Yardımcısı ürün grubunun laboratuvar testinde elde edilen formüle dayalı olarak potansiyel büyümesini makul bir şekilde tahmin edebilse de, kısa vadede ve uzun vadede büyümeyi etkileyebilecek bazı faktörleri hesaba katmaz.

Parçalanmayı ve karşılık gelen ek yükü azaltmak için başlangıç veritabanı boyutu Boyutlandırma Yardımcısı tarafından önerilen boyuta ayarlanmalıdır. Parçalanma ve ek yük, İşlemsel ve Veri Ambarı veritabanları için kurulum zamanında belirtilebilir. Kurulum sırasında yeterince kullanılabilir depolama alanı yoksa, veritabanları daha sonradan SQL Management Studio kullanılarak genişletilebilir ve ardından birleştirmek ve uygun şekilde en iyi duruma getirmek için yeniden dizinlenebilir. Bu öneri ACS veritabanı için de geçerlidir.

İşletimsel ve veri ambarı veritabanlarının büyümesi günlük veya haftalık bir döngüyle proaktif bir şekilde izlenmelidir. Bu beklenmeyen ve önemli büyüle atılımlarının belirlenmesi ve yönetim paketi iş akışındaki bir hatadan (yani bulma kuralı, performans veya olay toplama kuralı veya izleme ya da uyarı kuralı) kaynaklanıyorsa veya yönetim paketiyle ilgili sürüm yönetimi sürecinin test ve kalite kontrol aşamasında belirlenemeyen başka bir belirtiyse hata ayıklanmaya başlanması için gereklidir.

Veritabanı otomatik büyütme

Diskte ayrılan veritabanı dosya boyutu dolduğunda, SQL Server boyutu bir yüzde veya sabit bir değer ile otomatik olarak büyütebilir. Ayrıca, diskteki tüm kullanılabilir alanın dolamamsı için bir en büyük veritabanı boyutu yapılandırılabilir. Varsayılan olarak, OperationsManager veritabanı otomatik büyütme etkin olarak yapılandırılmaz; yalnızca Veri Ambarı ve ACS veritabanları bu şekilde yapılandırılmıştır.

Otomatik olarak büyütmeyi yalnızca beklenmeyen büyümeler için bir yedek plan olarak kullanın. Otomatik olarak büyütme, yüksek oranda işlemsel bir veritabanı söz konusuysa göz önünde bulundurulması gereken bir performans sorununa neden olur. Performans sorunları aşağıdakileri içerir:

  • Uygun büyütme artılını sağlamazsanız günlük dosyasında parçalanma.
  • Kullanılabilir alandan 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 olarak büyütmeyi etkinleştirdiyseniz, işlemin tamamlanması için geçen süre işlem günlüğünün yapılandırılan boyutta büyümesi için harcanan süreyi de içerir.
  • Günlüğün büyümesini gerektiren büyük bir işlem çalıştırıyorsanız, işlem günlüğüne yazmayı gerektiren diğer işlemlerin de büyütme işlemi tamamlanana kadar beklemesi gerekir.

Otomatik olarak büyütme ve otomatik olarak küçültme seçeneklerini birleştirirseniz gereksiz yük oluşturabilirsiniz. Büyütme ve küçültme işlemlerini tetikleyen eşiklerin sık boyut değişikliğine neden olmayacağından emin olun. Örneğin, kaydedildiği zaman işlem günlüğünün 100 MB büyütülmesine neden olan bir işlem çalıştırabilirsiniz. Bundan bir süre sonra otomatik olarak küçültme başlatılır ve işlem günlüğü 100 MB küçültülür. Daha sonra aynı işlemi yeniden çalıştırmak işlem günlüğünün yeniden 100 MB büyütülmesine neden olur. Bu örnekte gereksiz yük oluşturuyor ve günlük dosyasının potansiyel olarak parçalanmasına neden oluyorsunuz. Bunların ikisi de performansı olumsuz etkileyebilir.

Bu iki ayarı çok dikkatli bir şekilde yapılandırmanız önerilir. Belirli yapılandırma ortamınıza bağlıdır. Genel olarak, disk parçalanmasını azaltmak için veritabanı boyutunu belirli bir miktarda artırmanız önerilir. Aşağıdaki örnekte veritabanı otomatik olarak büyütme gerektiğinde her seferinde 1024 MB büyütülecek şekilde ayarlanmıştır.

Küme yük devretme ilkesi

Windows Server Yük Devretme Kümelemesi bir kümedeki ağ bağlantılarını ve düğümlerin sistem durumunu sürekli olarak izleyen bir yüksek kullanılabilirlik platformudur. Bir düğüme ağ üzerinden ulaşılamıyorsa, kurtarma işlemi gerçekleştirilerek uygulama ve hizmetle kümedeki başka bir düğümde çevrimiçi duruma getirilir. Varsayılan ayarlar “sabit” hata olarak kabul edilen tam sunucu kaybının yaşandığı hatalar için optimize edilmiştir. Bunlar yedekli olmayan donanım hatası veya güç kaybı gibi kurtarılamaz hata senaryolarıdır. Bu durumlarda sunucu kaybedilir ve Yük Devretme Kümelemesinin hedefi sunucu kaybını hızlı bir şekilde algılamak ve kümedeki başka bir sunucuda hızlı bir şekilde kurtarmaktır. Sabit hatalardan hızlı bir şekilde kurtarmayı başarmak için varsayılan küme sistem durumu izleme ayarları oldukça katıdır. Ancak ayarlar tamamen yapılandırılabilirdir ve çeşitli senaryoları destekler.

Bu varsayılan ayarlar çoğu müşteri için en iyi davranışı sunar, ancak kümeler birkaç santimetreden kilometrelerce uzağa doğru genişledikçe küme düğümler arasında güvenilir olmayabilen ek ağ bileşenlerine maruz kalır. Başka bir faktör, sürekli artan sunucu kalitesinin yedekli bileşenler (örneğin ikili güç kaynakları, NIC grubu oluşturma ve çok yollu G/Ç) ile geliştirilmiş dayanıklılıkla birleştiğinde yedekli olmayan donanım hatalarının oldukça nadir hale gelmiş olmasıdır. Sabit hatalar daha az göründüğünden, bazı müşteriler kümeyi geçici hatalara karşı ayarlayarak kümeyi düğümler arasındaki kısa ağ hatalarına karşı daha dayanıklı hale getirmek isteyebilir. Varsayılan hata eşiklerini artırarak kısa süreli ağ sorunlarına hassasiyeti azaltabilirsiniz.

Burada doğru tek bir cevap olmadığını ve optimize edilmiş ayarların işletme ihtiyaçlarınız ve hizmet düzeyi anlaşmalarınıza göre farklı olabileceğini anlamak önemlidir.

SQL Server’ı sanallaştırma

Sanal ortamlarda performansa bağlı nedenlerden ötürü, işletimsel veritabanını ve veri ambarı veritabanını sanal disk üzerinde değil, doğrudan takılmış bir depolama üzerinde saklamanız önerilir. Gerekli IOPS’u tahmin etmek için her zaman Operations Manager Boyutlandırma Yardımcısı’nı kullanın ve doğrulamak için veri disklerinize stres testi uygulayın. Bu görev için SQLIO aracını kullanabilirsiniz. Sanallaştırılmış Operations Manager ortamı hakkında ek yönergeler için bkz. Operations Manager sanallaştırma desteği.

Always On ve kurtarma modeli

Tam olarak iyileştirme olmasa da, Always On Kullanılabilirlik Grubu hakkında dikkat edilmesi gereken konulardan biri, bu özelliğin tasarım olarak veritabanlarının “Tam” kurtarma modunda olmasını gerektirmesidir. Yani, işlem günlükleri tam bir yedekleme yapılana veya yalnızca işlem günlüğü yedeklenene kadar asla atılmaz. Bu nedenle, bir yedekleme stratejisi Operations Manager veritabanları için Always On tasarımının isteğe bağlı değil zorunlu bir parçasıdır. Aksi takdirde, zaman içinde işlem günlüklerini içeren diskler dolar.

Yedekleme stratejinizin ortamınızın ayrıntılarını hesaba katması gerekir. Aşağıdaki tabloda tipik bir yedekleme zamanlaması verilmiştir.

Yedekleme TürüZamanlama
Yalnızca işlem günlüğüHer bir saat
TamHaftalık, Pazar 03:00’da

SQL Server raporlama hizmetlerini en iyi duruma getirme

Raporlama Hizmetleri örneği, Veri Ambarı veritabanındaki verilere erişmek için bir proxy görevi görür. Yönetim paketlerinin içinde depolanan şablonları temel alan raporlar oluşturur ve görüntüler.

Raporlama Hizmetleri’nin perde arkasında, ReportServer ve ReportServerTempDB veritabanlarını barındıran bir SQL Server Veritabanı örneği bulunur. Bu örneğin performans ayarlaması için genel öneriler geçerlidir.

© 2017 Microsoft