Shrink İncelemesi

    Merhaba arkadaşlar, bu yazımda sizlere MS SQL Server da shrink işleminden bahsedeciğim. Bu konuyu ele almak istememdeki amaç ise katıldığım bir eğitim programında shrink işlemenin tercih edilmemesi gerektiği üzerine yapılan bir konuşma oldu. Bunun üzerine shrink işlemi hakkında yaptığım araştırma sonucunda sizi de bilgilendirmek istedim.
    Bir blog yazısından Shrink işlemi hakkında yazarın yazdığı bir cümleyi sizinle paylaşmak istiyorum. 'Veritabanınızı shrink etmek gerçekten iyi bir fikir değildir. Shrinklemek için istisnai durumlar vardır. Ama onlar sadece istisnadır.' (Mike Walsh)
    Shrink'in yaptığı işlem , veritabanında kullanılmayan boş alanları temizler. Shrink işlemi için, bazı yazılarda çirkin bir işlem olarak nitelendirildiğini ve pek tercih edilmediğine denk geldim. Aslında sevilmemesinin sebebi Shrink işlemi sonucunda index'te parçalanmalar söz konusu olduğu için uzun dönemde performansı kötü yönde etkileneceği söylenmektedir. Eğer veritabanınızda büyüme eğilimi varsa bu konuda geçerli önlem alınmadığı sürece shrinklemek size sadece geçici bir çözüm sunacaktır. Çünkü zaten Shrinkledikten bir süre sonra tekrar DB şişmeye başlayacaktır. Ortaya çıkan parçalanmış dosyları gidermek için I/O (input/output) subsystem tarafında tamamen ele alınması gerektiğidir.
    Peki Sql Server dosylarında boş alan açabilmek için neler yapabiliriz? Aslında ilk olarak ileride DB'in boyutunun ulaşabileceği değerleri tahmin edip buna uygun DB boyutu ayarlanmalıdır. Eğer yapılabiliyorsa gelecekteki bir yıl yada daha fazlası için bu analiz yapılmalıdır.DB'nin ulaşacağı boyut data bazında mantıklı tahmin edilmelidir. Hatta DB'nin belli bir periyot içerisinde ulaşabileceği boyutlar yüzdesel ifadeler yerine byte tipinde kesin sayısal veriler ile ifade edilip tahmin edilmelidir '%10 default değerini ele alırsak. Eğer 1TB bir DB'ye sahipseniz bunun öngürülür büyüme oranının sayısal karşılığı 100 gb olacaktır ki buda ne kadar mantıksal bir varsayım olur...') Boş kalan alanınızı ve DB'nin büyüme eğilimini zaman içinde izleyin. Daha büyük bir alanda gerçekleşen parçalanma için başta analiz ettiğiniz DB boyutu sayesinde tekrardan planlama yapabilirsiniz.
    Eğer DB de Full Recovery Mod' da çalışıyorsanız aslında hedeflediğiniz amaç herhangi bir sorun durumunda sistemi tekrardan ayağa kaldırabilmek. Bu durumda Full backup ve Transaction Log Backup(belkide differential) alıyorsunuzdur. Aslında SQL server'ın anladığı şey sizin planladığınz amaçtan farklı. Çünkü bu durumda SQL Server log dosyalarını truncate etmiyecektir (Verilerde değişiklik olsa bile aslında veri boyutu bazında bir azalma söz konusu olmayacaktır. Yer açmak için Shrink yapmak yerine tercih edeceğimiz Truncate olmalıdır. Truncate dosya içerisinde yer açar. Oysaki Shrink işlemi boş alan açmak için fiziksel dosylarıda küçültecektir. ).
    Sürekli Full backup almak yerine transaction log backup ile birlikte zaman içerisinde belli bir noktaya DB'ye restore edebiliriz, tabiki log dosysları ve zincirinde herhangi bir kayıp yaşanmadıysa. Kısaca verim açısından backup ve recovery stratejilerini gözden geçirilmelidir. Uzmanlar bu konuda özellikle Log Backup'ın tercih edilmesi gerektiğinin üzerinde duruyorlar.
    Shrink bize geçici bir çözüm sunmakta ayrıca yapısal bozukluklara sebebiyet verdiğinden dolayı en son ki aşamada tercih edilmelidir. Bu aşamdan önce yapılması gerekenleri olabildiğince yukarıda anlatmaya çalıştım umarım faydalı olmuştur. Bir sonraki yazıda göüşmek üzere. Hoşçakalın...