SQL Server Bakım Planları: Hangi Görevler Olmalı, Nelerden Kaçınmalı, Nasıl Zamanlanmalı?

Her production SQL Server düzenli bakıma ihtiyaç duyar: backup, bütünlük kontrolü, istatistikler, indeks bakımı ve geçmiş temizliği. SQL Server’ın yerleşik bakım planları (maintenance plans) bunu zamanlamanın en hızlı yoludur. Ama sihirbazın varsayılanlarıyla kurulan bir plan, faydası kadar zarar da verebilir: her gece veritabanlarını shrink etmek, ihtiyaç olsun olmasın bütün indeksleri rebuild etmek ya da differential’larınızın bağlı olduğu full backup’ı silmek gibi.

Bu rehberde bakım planlarının ne olduğunu, sağlıklı bir planın hangi görevleri içermesi gerektiğini, hangilerinden kaçınılması gerektiğini, görevlerin nasıl sıralanıp zamanlanacağını ve script tabanlı bir çözümün ne zaman daha iyi bir seçim olduğunu anlatıyoruz.

SQL Server Bakım Planı Nedir?

Bakım planı, SQL Server Management Studio’da Maintenance Plan Wizard ile ya da tasarımcıda oluşturduğunuz bir bakım görevleri iş akışıdır. Arka planda SQL Server her planı bir Integration Services (SSIS) paketi olarak saklar ve bir SQL Server Agent job‘ı bunu zamanlamaya göre çalıştırır. Görevler farklı zamanlamalara sahip subplan’lara ayrılabilir; örneğin 15 dakikada bir log backup için bir subplan, haftalık bütünlük kontrolleri için başka bir subplan.

Görevler: Hangileri Kullanılmalı, Hangilerinden Kaçınılmalı?

Backup’lar

Backup’lar her planın çekirdeğidir. Full, differential ve log backup görevlerini RPO ve RTO’nuzun gerektirdiği zamanlamaya göre kullanın. Compression ve “Verify backup integrity” / checksum seçeneklerini açın, her backup’ı ayrı bir backup konumunda tarihli kendi dosyasına yazın ve sabit bir liste yerine “All user databases” seçerek planın yeni veritabanlarını otomatik kapsadığından emin olun. Zamanlamanın nasıl seçileceğini SQL Server Backup Planı Nasıl Kurulur? yazımızda anlattık.

Bütünlük kontrolleri

Check Database Integrity görevi DBCC CHECKDB çalıştırır. Başarılı iki kontrol arasındaki süre backup saklama sürenizden kısa olacak şekilde zamanlayın; aksi halde bozulma elinizdeki bütün backup’lara ulaşabilir. Büyük veritabanlarında “Physical only” seçeneği süreyi kısaltır; bunu periyodik bir tam kontrolle birleştirin. SQL Server’da DBCC CHECKDB yazımıza bakabilirsiniz.

İstatistikler ve indeksler

Sihirbaz varsayılanlarının en çok israfa yol açtığı yer burasıdır. Microsoft’un indeks bakımı konusundaki güncel yönlendirmesi nettir:

• İndeks bakımı kaynak yoğun bir işlemdir ve faydası iş yüküne göre hayati ile önemsiz arasında değişir. Ayrım gözetmeden ya da yalnızca sabit fragmentation eşiklerine bakarak yapılmamalıdır.
• İndeksler rebuild edildikten sonra görülen iyileşmenin büyük kısmı aslında rebuild’in yaptığı istatistik güncellemesinden gelir. İstatistikleri güncellemek çoğu zaman aynı faydayı maliyetin küçük bir kısmıyla sağlar.
• Reorganize, rebuild’den daha az kaynak kullanır, her zaman online’dır ve rebuild için özel bir sebep yoksa tercih edilmesi gereken yöntemdir.

Pratikte: Update Statistics‘i düzenli zamanlayın ve indeks görevlerini, görev seçeneklerindeki (SQL Server 2016’dan beri mevcut) fragmentation ve sayfa sayısı filtreleriyle sınırlayın; böylece yalnızca büyük ve gerçekten parçalanmış indekslere dokunulur. Aynı indekslerde hem Rebuild Index hem Reorganize Index çalıştırmayın ve bir rebuild’in ardından aynı indekslerde istatistik güncellemesi yapmayın: rebuild, istatistiklerini zaten full scan ile günceller. Yeni platformlarda düşük maliyetli bir alternatif için SQL Server Automatic Index Compaction yazımıza bakabilirsiniz.

Rutin bakımda asla shrink yapmayın

Temizlik: geçmiş ve eski backup dosyaları

• Clean Up History, msdb’deki eski backup/restore geçmişini, Agent job geçmişini ve bakım planı geçmişini siler. Bu olmadan msdb büyümeye devam eder ve geçmiş sorguları yavaşlar. Birkaç haftalık geçmiş tutmak genellikle yeterlidir; SQL Server Agent Job History Retention İçin Best Practices yazımıza bakabilirsiniz.
• Maintenance Cleanup, belirli bir yaştan eski backup dosyalarını dosya uzantısına göre siler. Backup zincirlerinden haberi yoktur. Bu haftanın differential’ları hâlâ geçen haftanın full backup’ına bağlıyken onu silerse, o differential’lar işe yaramaz hale gelir. Yaşı, her zaman eksiksiz bir set (full + differential’lar + log’lar) kalacak şekilde ayarlayın; gerekirse .bak ve .trn dosyaları için farklı yaşlarla ayrı temizlik görevleri kullanın.

Sıralama ve Zamanlama

Ayrı subplan’larla tipik bir düzen:

Bütünlük kontrolünü haftalık full backup’tan önce çalıştırmak, sonraki haftanın restore’larının bağlı olacağı backup’tan kısa süre önce veritabanının temiz olduğunu bilmenizi sağlar. Ağır görevleri birbirinden ayırın: full backup, bütünlük kontrolü ve indeks bakımının hepsi bütün veritabanını okur ve aynı I/O için yarışır.

Planların Varlığını Değil, Çalıştığını İzleyin

Sessizce hata alan bir bakım planı hiç olmamasından kötüdür, çünkü herkes çalıştığını varsayar. Şunlardan emin olun:

• Her planın Agent job’ı hata durumunda bir operator’e bildirim gönderiyor. SQL Agent Bildirimlerini Kullanarak Job’larınızı Güvende Tutun yazımıza bakabilirsiniz.
• Planlar, her görevin gerçekte ne yaptığını görebilmeniz için bir rapor ya da log yazıyor.
• Backup planı ve CHECKDB rehberlerimizdeki sorgularla, her veritabanının yakın tarihli bir backup’ı ve başarılı bir CHECKDB’si olduğunu düzenli olarak kontrol ediyorsunuz.
• Job sahibi, kişi ayrıldığında devre dışı kalacak bir kişisel login değil, kalıcı bir hesap. SQL Agent Job’ların Owner’larını Neden Önemsemelisiniz? yazımıza bakabilirsiniz.

Bakım Planı mı, Script mi?

Bakım planları, sadeliğin en önemli olduğu küçük ve orta ölçekli ortamlar için uygundur. Ortamlar büyüdükçe script tabanlı çözümler daha pratik hale gelir: sürümlemesi, çok sayıda sunucuya dağıtılması ve veritabanı bazında ince ayar yapılması daha kolaydır. SQL Server topluluğunda yaygın kullanılan ücretsiz bir seçenek, backup, bütünlük kontrolü ve fragmentation tabanlı mantık ve ayrıntılı loglamayla indeks ve istatistik bakımını kapsayan Ola Hallengren’in SQL Server Maintenance Solution‘ıdır. Microsoft da indeks ve istatistik bakımı için Adaptive Index Defrag prosedürünü yayınlıyor. Hangisini seçerseniz seçin, yukarıdaki ilkeler aynı kalır.

Sık Sorulan Sorular