Selam millet,
Bazen gerçekten gerektiği için ve bazen neden alındığının bile belli olmadığı ve hatta bu yedeklerle ne zaman, kimin ve ne yapılacağının bile bilinmediği ortamlar gördüm. Transaction Log yedeklerinden bahsediyorum. Şirketin RPO ve RTO ihtiyaçları çerçevesinde ve özellikle kritik Production sistemler için Full ve Differential yedeklerin yanında sıklıkla Transaction Log yedeği alınması oldukça normaldir. Recovery Model'ın değişik modlarının ve Transaction Log dosyalarının nasıl yönetileceği tamamen çok geniş ve ayrı konular, ben bu kısa yazımda sizlere Transaction Log'ların sıklıkla alındığı ortamlarda "msdb" veritabanında düzenli temizlik yapılmadığında nasıl bir manzara ile karşılaşılabileceğine dair fikir vermek istiyorum.
Bugün Domain'de olmayan ve bu nedenle (ve tabii ki biraz da ilgili arkadaşımın ilgisizliği nedeniyle) ve benim bu sunucuya henüz kendi denetim ve izleme Script'lerimi kurmamam nedeniyle yukarıda bahsettiğim gibi bir rezaletle karşılaştım.
Efendim, görüntü aşağıdaki gibi:
 |
| "msdb" veritabanı yeterince temizlenmediğinde... |
Gördüğünüz gibi yedekleme ile ilgili tüm tablolar almış başını gitmiş. Emin olun bundan çok daha beter ve rezil manzaralar da var, gördüm. Bununla birlikte, hazır bunu da görmüşken sizlerle de paylaşıp dikkatinizi çekeyim dedim.
Peki bu tablolar neden böyle dolar? Aslında yukarıda özetle değindiğim konuya tekrar değineyim. Genellikle Full veritabanı yedekleri günde bir kere veya haftada bir kere alınır (tabii ki duruma göre değişir!) ve keza Differential yedeklerin de günde en fazla 4 kere alındığını görmüşlüğüm var. Fakat Transaction Log yedekleri çok daha sıklıkla alınır, mesela her 5 dakikada bir sefer gibi (her 1 dakikada bir alındığını da gördüm!). Bu ne demek? Günde ortalama 288 adet Transaction Log yedek dosyası ve "msdb" sistem veritabanındaki ilgili yedek tablolarında 288 adet kayıt demek. İlgili SQL Server Instance'ındaki veritabanı sayısı, Transaction Log yedek alma sıklığı ve "msdb" veritabanının temizlenmeme süresi hesaba katıldığında, ilgili yedek tabloları gerçekten acayip fazla şişebilir.
Tek çekince tabii ki bu tabloların şişip yer kaplaması değil, genelde ve birçok ortamda bu tabloların tutulduğu "msdb" veritabanının dosyaları "C:" diskindedir. Çünkü DBA barındırmayan birçok şirkette SQL Server kurulumları "next, next" şeklinde yapılır ve Best Practice'ler takip edilmez. Hal böyle olunca, bu veritabanlarının büyümesi C: diskini tamamen doldurur, ki çoğu durumda Windows işletim sistemi ve hatta "tempdb" veritabanı da bu disktedir. Tabii ki bu durumda bir taraftan işletim sistemi teklemeye, "garip gurip" hatalar vermeye başlar, bir taraftan da kullanıcılar "tempdb"den "ilginç" hatalar almaya başlarlar.
Peki "msdb" veritabanınızı bu yedek tarihçesi kirliliğinden nasıl kurtaracaksınız? Aşağıdaki komut ile!
USE msdb;
GO
DECLARE @most_old_record_date DATETIME;
SELECT @most_old_record_date = DATEADD(DAY, - 365, GETDATE());
EXEC msdb.dbo.sp_delete_backuphistory @oldest_date = @most_old_record_date;
Açıkçası yukarıda sizinle paylaştığım Script, benim asıl araç gereç kutumdakinin biraz değiştirilmiş versiyonu. Benim kendi kullandığım Script'lerin bir ana yapılandırma tablosu var, yukarıdaki -365 gibi tüm değerler o tablodan alınır. Size de tavsiyem, "msdb" veritabanında en azından 1 senelik kayıt eğer şartlar mümkünse bulundurun. Böylece örneğin geriye dönük olarak aldığınız yedeklerin boyutunun ne kadar büyüdüğünü tespit edebilirsiniz. Hoş bir istatistiki bilgi.
Şimdilik bu kadar! Esen kalın.
Ekrem Önsoy
