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

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

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından başka diğer bazıları:

- optimize for ad hoc workloads: Bu ayar, Plan Cache'in daha verimli kullanılmasını sağlar. Sunucuya birçok Ad Hoc sorgular geliyor olabilir, fakat bunlar sadece bir kere kullanılıyor ve daha da kullanılmıyor olabilir. Bu nedenle Plan Cache verimli kullanılmıyor olabilir. Eğer "optimize for ad hoc workloads" parametresini etkinleştirirseniz, o zaman ilk defa çalıştırılan bir Batch için geçici, özet bir plan oluşturulur Plan Cache'te ve eğer aynı Batch ikinci kere gelirse, bu sefer planın tamamı Plan Cache'te tutulur ve bu sayede hafıza yönetimi daha verimli bir şekilde yapılmış olur.

Örnek:
EXEC sp_configure "optimize for ad hoc workloads", 1
RECONFIGURE

- remote admin connections: Yine SQL Server 2005 ile birlikte gelen yeni bir özellik vardır, Dedicated Administrator Connection (DAC). DAC sayesinde, bir SQL Server Instance'ında donma, yetersiz hafıza veya CPU işlem yoğunluğu gibi sorunlar olduğunda ilgili Instance'a bağlanmamız mümkündür. Bu sayede kısıtlı da olsa sorunu çözebilecek belli müdahalelerde bulunabiliriz. Fakat DAC özelliği varsayılan olarak sadece SQL Server Instance'ının kurulu olduğu makine üstünden kullanılabilir. Yani DAC'ye uzaktaki bir makineden varsayılan olarak bağlanılamaz. Şayet "remote admin connections" parametresinin değeri "1" yapılırsa, o zaman bu mümkündür.

Örnek:
EXEC sp_configure "remote admin connections", 1
RECONFIGURE

Varsayılan bir SQL Server 2005 (ve üstü) kurulumlarda yukarıda belirttiğim SQL Server Configuration parametreleri etkin değildir ve bunlar SQL Server Instance'ınızın performansını ve işlevselliğini olumsuz şekilde etkileyebilir. Ben ortamımda yaptığım kurulumlardan sonra bu özellikleri etkinleştiriyorum, eğer sizin ortamınıza da uygunsa siz de bu ayarları yapmayı düşünebilirsiniz.

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

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

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından diğer bazıları:

- - max degree of parallelism: OLTP sistemler için bu parametrenin değerini "1" yapmakta, yani işlemleri seri şekilde çalışmasında fayda var. Şayet paralel çalışması gereken (Index işlemleri vb.) işlemleriniz varsa, o zaman o işlemlerde ilgili Hint'leri (örneğin Index Rebuild işlemi için MAXDOP=4 gibi) kullanmanızda fayda var.

Örnek:
EXEC sp_configure "max degree of parallelism", 1
RECONFIGURE

- max server memory (MB): İnternet ortamındaki forumlarda veya başka sosyal ortamlarda insanlardan şunu çok duyarsınız "SQL Server sunucudaki tüm RAM'i kullanıyor ve diğer uygulamalar sıkıntı çekiyorlar!". Çünkü SQL Server'ın varsayılan "max server memory (MB)" ayarı, sunucudaki tüm RAM'in kullanılmasına göre ayarlıdır. O yüzden SQL Server birden değil, ama işlem yoğunluğuna göre yavaş yavaş veya hızlı hızlı tüm RAM'i kullanmaya meyillidir. Şayet "max server memory (MB)" parametresini elle ayarlarsanız, bunu sınırlayabilirsiniz. Örneğin sunucunuzda 8GB RAM varsa ve SQL Server'ın sadece 4GB RAM kullanmasını istiyorsanız o zaman "max server memory (MB)" parametresinin değerini "4096" yapabilirsiniz.

Örnek:
EXEC sp_configure "max server memory (MB)", 4096
RECONFIGURE

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