SQL Server Kurulumlarında Gözden Kaçanlar - 8

Kurulum yapıldıktan sonra, özellikle de kritik veritabanı uygulamalarını barındıran SQL Server sunucularında, SQL Server açısından takibini yapmanız gereken olmazsa olmaz şeyler var. Bunlardan temel olarak bazıları:

- CPU kullanımı (Ortalama İşlemci Kullanımı)
- RAM kullanımı (Plan Cache ve Data Buffer Cache Hit Ratio, Available Memory, Page Life Expectancy gibi)
- Disk performansı (Ortalama Disk Queue Length, Disk Idle, Disk Response Time gibi)
- Disk kullanımı (doluluk oranları)
- Veritabanı veri ve Transaction Log dosyaları için doluluk oranları
- SQL Error Log dosyasının içindeki hatalar
- Deadlock takibi
- Blocking takibi
- Uzun süren, maliyetli işlemlerin takibi
- (Varsa) Log Shipping, Database Mirroring, Replication gibi sistemlerin çalışırlığı, senkronizasyon sürelerindeki gecikmeler gibi (meselâ Heartbeat yöntemleri kullanarak)
- (Varsa) SQL Server Failover Clustering'teki pasif düğümlerinizin durumu (meselâ Ping'leyerek)

Bu takipler çoğu zaman 3. parti uygulamalarla gerçekleştiriliyor. Fakat bütçesi müsait olmayan firmalarda bu takiplerin birçoğu, ücretli uygulamalar olmadan da gerçekleştirilebilir. Bazılarının takibi için bazı icatlar yapmıştım, bazılarını ise şirkette kullandığımız 3. parti uygulamalarla yapıyoruz. Yavaş yavaş, bu takipleri olabildiğince 3. parti ücretli uygulamalara para ödemeden nasıl yapabileceğiniz hakkında yazılar yazmaya çalışacağım; tabii ki her şeyi 3. parti uygulama olmadan çözmek mümkün veya pratik olmayabilir, bunları da ayrıca anlatmaya çalışacağım.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7

SQL Server Kurulumlarında Gözden Kaçanlar - 7

SQL Server kurulumlarından sonra yapılması gereken şeylerden biri de TEMPDB veritabanının DATA dosyalarının sayısının CPU (CORE) sayısına göre çoğaltılmasıdır.

Örneğin 8 çekirdekli bir işlemciye sahip olan bir sunucunuz var, o zaman TEMPDB için toplam 8 tane DATA dosyası oluşturmanız uygun olacaktır. Transaction Log dosyasının sayısını ise seri şekilde işlendiğinden dolayı istisnai durumlar haricinde gerekmediği zaman çoğaltmaya gerek yoktur.

Ayrıca yapılan testlere göre işlemci sayısı 16'yı geçse bile, 16'dan fazla TEMPDB dosyası oluşturmamak gerekiyor. Yani üst sınırınız şimdilik 16.

DATA dosyalarını oluştururken tüm dosyaların boyutlarının aynı olduğundan emin olun. Örneğin sistem veritabanları için 50GB'lık bir disk ayırdıysanız ve sunucunuzda 16 CPU varsa, o zaman 16 tane dosya oluşturun ve hepsinin boyutunu da 512MB veya 1GB olarak ayarlayın. Bunu ihtiyacınıza göre değiştirebilirsiniz, fakat bir dosyanın boyutu ne olacaksa, diğerleri de aynı olmalıdır. Transaction Log dosyasının boyutu ise farklı olabilir, bunu da yine ihtiyacınıza göre ayarlarsınız. Maksat, işlemlerin dosyalara eşit şekilde yayılmasını sağlamak ve paralellikten faydalanmak ve dosyaların sürekli bir şekilde büyümesini engelleyip performans kaybının oluşmasını önlemek.

Dosyaları oluştururken dikkate almanız gereken şey ise büyüklükleri ve artış oranları. Dosyaları oluştururken varsayılan olarak 3MB değil büyüyecek şekilde bırakmayın. Bu ayarı makul bir şekilde ayarlamanız gerekiyor. Çünkü dosya büyürken yaşanan performans sıkıntılarını yaşamak istemezsiniz. Büyüme değerlerini de kontrollü bir büyüme için MB cinsinden, makul değerlerle belirlemek gerekir. Örneğin bazı durumlarda büyüme değerinin %25 olarak yapıldığını görüyoruz. Bunu şöyle düşünün, 100MB'ın %25'i 25MB; fakat 1GB'ın %25 256MB. Kestiremeyeceğiniz şekilde yaşanan büyümeler veritabanının Suspect duruma düşmesine yol açabilecek sonuçlara kadar gidebilir. Başka örneklerde de bu büyümenin 1MB gibi çok düşük bir miktarda olduğunu görebiliyoruz. Bu gibi durumlarda ise SQL Error Log'da sürekli IO ile ilgili uyarılara rastlanabilir. Ayrıca Transaction Log dosyasının büyümesi sırasında donmalar yaşanabilir, çünkü veritabanı yeni kayıtları kabul edemeyebilir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Performance Counter'larının tekrar oluşturulması

Tam olarak ne gibi durumlarda gerçekleşiyor bilemiyorum, fakat bazı SQL Server kurulumlarından sonra sunucuda SQL Server Performance Counter'ları belki kurulumda hiç oluşturulmamış oluyor ve biz olmadıklarını sonradan fark ediyoruz, belki de herhangi bazı işlemler yüzünden bu Performance Counter'ları bir şekilde silinebiliyor.

Daha geçen gün, yine bir müşterimizde böyle bir sorun ile karşılaştım. SQL Server 2008 Failover Cluster'ın kurulu olduğu 2 düğümlü bir sistemde, makinelerden birinde SQL Server Performance Counter'ları vardı; fakat diğerinde sadece SQL Server Agent ve SQL Server Integration Services'a ait 4-5 tane Performance Counter vardı.

Bu durumda SQL Server (2005 veya 2008) Performance Counter'larını tekrar oluşturmak gerekiyor. SQL Server Performance Counter'ları ilgili SQL Server Instance'ının "BINN" klasöründeki "sqlctr.ini" isimli dosyada bulunur. Counter'ları tekrar oluşturmak için aşağıdaki yolu izleyebilirsiniz.

- Bir Command Prompt penceresi açarak Performance Counter'ları olmayan SQL Server Instance'ının "BINN" klasörüne ulaşmanız gerekiyor, örneğin: "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn".
- Halihazırda var olan (eğer varsa) sayaçlar kaldırılır. Bunun için varsayılan bir SQL Server Instance'ı (Default Instance) için aşağıdaki kod:

unlodctr MSSQLSERVER

Bir Named Instance için de aşağıdaki kod çalıştırılmalı:

unlodctr MSSQL$namedInstance

- Sonrasında ise yine ilgili SQL Server Instance'ının "BINN" klasöründe aşağıdaki kod çalıştırılmalı:

lodctr sqlctr.ini

Eğer bu komutu çalıştırdıktan sonra herhangi bir sonuç dönmüyorsa, bu komutun başarılı olarak çalıştırıldığı anlamına gelir. Ayarların etkinleştirilebilmesi için ise ilgili SQL Server servisinin yeniden başlatılması gerekir. Bu işlemden sonra SQL Server Performance Counter'larının görünmesi gerekir.

Bazı durumlarda ise "sqlctr.ini" dosyası bir şekilde bozulmuş olabiliyor. Böyle bir durumda ise, bu dosyanın sağlam bir halini, aynı versiyondaki başka bir SQL Server Instance'ının "BINN" klasöründen alıp kopyalayabilirsiniz. Böyle bir durumda ise "sqlctr.ini" dosyasındaki aşağıdaki parametreyi SQL Server Instance'ınızın adına göre düzenlemelisiniz. Aşağıdaki örnekte SQL Server Instance'ı Default Instance'tır.

[info] drivername=MSSQLServer
trusted=
symbolfile=sqlctr.h

SQL Server Kurulumlarında Gözden Kaçanlar - 6

Bazı SQL Server sunucuları veya servisleri çok uzun süre kapatıl(a)mayabiliyor. Bu durumda ise, SQL Server Error Log çok şişebiliyor ve bu da bazı sıkıntılara neden olabiliyor. Örneğin dosyanın açılması, okunması zor oluyor, pratik olmuyor. Bu nedenle ben, yeni kurulan sunucularda SQL Error Log'larının haftada bir yenilenmesi (Cycle) için bir Job oluştururum ve bu Job, aşağıdaki kodu çalıştırarak SQL Error Log'unu haftada bir kere yeniler.

EXEC sp_cycle_errorlog

Bu sayede SQL Server Error Log dosyaların boyutları hafifler ve açması, içinde bir şeyler araması ve bulması ve yönetimi kolay olur.

Ayrıca, varsayılan olarak SQL Server sadece 6 tane SQL Server Error Log tutar. 6 tanesinden sonra yeni SQL Server Error Log'lar ise, eskilerinin üzerine yazılmaya başlar.

Bu sayıyı arttırmak için SQL Server Management Studio'da aşağıdaki yolu izleyebilirsiniz:
- Object Explorer'dan ilgili SQL Server Instance'ının altından "Management"ı genişletin.
- "SQL Server Logs" öğesinin üzerinde farenin sağ tuşuna tıklayın ve "Configure" öğesine tıklayarak "Configure SQL Server Error Logs" penceresine ulaşın.
- "Maximum number of error log files:" parametresinin değerini ihtiyacınıza göre ayarlayın.

Not:Log sayısını belirlerken, diskteki boş yerinizi de göz önüne almanız önemlidir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 5

Bir SQL Server kurulumu yaptıktan sonra, özellikle de Log Shipping kullanılacaksa veya sık yedek alınabilecek bir sunucuysa (Transaction Log yedekleri gibi) o zaman muhakkak "msdb" sistem veritabanındaki yedeklemeyle ilgili kayıtları tutan tabloların düzenli bir şekilde silinmesinde fayda vardır. Aksi takdirde "msdb" veritabanı zamanla büyüyecektir, çünkü "msdb" veritabanında en çok büyüyen tablolar yedekleme ile ilgili tablolardır.

Bu amaçla, kurulum yaptığınız ve/veya yapacağınız sunucularda çalıştırılmak üzere standart bir Script oluşturup, bu Script'i de bir Job ile, SQL Server Agent* vasıtasıyla çalıştırabilirsiniz.

Bu Script'i hazırlarken temel olarak kullanabileceğiniz bir sistem Stored Procedure (SP)'ü bulunmaktadır. Bu SP "sp_delete_backuphistory" isimli SP'dir. Bu SP hakkında daha fazla bilgi almak için Books Online'dan şu adrese bakabilirsiniz: http://msdn.microsoft.com/en-us/library/ms188328.aspx

Örnek: Aşağıdaki kod ile, 1 aydan daha eski yedekleme kayıtlarının tarihçesini "msdb" veritabanındaki ilgili tablolardan temizlemiş olursunuz.
DECLARE @tarih datetime SET @tarih = DATEADD(month, -1, getdate()) EXEC sp_delete_backuphistory @tarih

* SQL Server Express Edition'larda SQL Server Agent bulunmamaktadır. Bu durumda, oluşturacağınız Script'i bir dosyaya kaydedebilir, bu dosyayı SQLCMD ile (SQL Server'ın Command Prompt aracı), Windows Scheduler ile de zamanlayarak çalıştırabilirsiniz.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8