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

MS SQL' DE Estimated Execution Plans İncelemesi

    Merhabalar, Execution plan hakkında internette bazı araştırmalar yaptım ve yeteri kadar türkçe kaynak olmadığını fark ettim. Bundan dolayı bazı yabancı makaleleri inceleyerek dilimin döndüğünce türkçeye çevirdim ve bu konuyu merak edenlere kısa bir özet yazmak istedim.Umarım faydalı olur.

     Estimated Execution Plans'ın kullanım amacı, aslında sorgular çalıştırılmadan önce perfromans kaybını önlemek ve sorgunun nerelerinde sıkıntı olduğunu tespit etmek ve nokta atışı yaparak sorguda iyileştirmeler yapamaya çalışmak diyebiliriz.
    Sorgu çalıştırıldığında aslında 2 ana step yürütülür. Birinci adım da query compile edilir(yani sorgu derlenir.) 2. adım ise planın execute edilmesidir(yani çalıştırılır). SQL SERVER 2005 de query execution plan bize 3 farklı sunum göstermektedir. text, xml ve grafik olarak, ki bunlardan da en çok tercih edilen grafik olarak sunulanıdır. Örneğin yeni bir sorgu penceresi açtığınız zaman SSMS da query seçer Actual Execution Plan çalışıtırıldığında neler olacaktır görelim. Örnek olarak AdventureWorks kullanılmıştır.

   
    Bunun sonucunda aşağıdakileri sırasıyla görebiliriz. ilk olarak execution plan sorgu yığını içinde bulunan her bir sorgu için bize değer döndürür.(Fakat örnekte sadece bir tane sorgu kullanılmıştır.) Execution plan sorguyu üstten alta, sağdan sola doğru incelemeye başlar. Mesela bu execution plan da ilk adım bölge adını ve kimlik sütunlarını dönmek için AK_SalesTerritory_Name indexinde tarama yapmaktadır. Bu adımın sonunda diğer step ile birleşecektir. Sağdan sola çalışmaya devam edecek ve nasted loop iki tabloyu birlikte joinlemek için kullanılır. Sonunda da nested loop'un sonucu SELECT işlemini besler.

 

    Yukarıdaki resimde de gördüğünüz gibi sorgunun her bir adımdaki maliyeti bize gösterilir. Bu bize dönen sonuç bütün query ile alakalıdır. Bu örnekte AK_SalesTerritory_Name Index de taranan toplam query maliyeti %44'tür. Benzer bir şekilde eğer sorgu yığını çalıştırılırsa, sorgu çalışma maliyeti bütün sorgu yığını ile alakalı olarak gösterilir. Yukarıda görülen her bir ok bağlantıyı temsil eder ayrıca okların kalın olarak gösterilmesi ise her bir satırın sayı miktarı ile alakaladır. Yukarıdaki planda her bir adım incelenip sorguyu optimize etme ve sorun giderme konusunda bize çok yarıdımcı olacaktır. 2. resimde adımların AK_SalesTerritory_Name index taramasının detaylarını açıkça görebilirsiniz. Farklı kolonların bilgileri burada gözükmektedir. Eğer her bir kolonun açıklamasını görmek istersek step'e tıkladıktan sonra SSMS'da özellik menüsünü açmalıyız. Buradan view ve özellik pernceresini SSMS' de seçmeliyiz. Bu kısımda bir çok hesaplanmış değer bize sunulmaktadır.(Örneğin CPU Cost)Buradaki değeleri referans olarak querymizi yapılandırmada kullanabiliriz.

                          Estimated Execution Plans:
    Estimated Execution Plan sorgulardan seçilmiş olanları görüntüler. Aslında gerçekte olan bu sorguların çalıştırılması değildir. Bunun yerine sadece muhtemel olan çalışma maliyeti hesaplanır ve sunulur. Çok daha büyük ve karmaşık sorgular söz konusu olduğu zaman Estimated Execution çok hızlı sonuç döndürecektir. Ayrıca her bir adımın detaylarına baktığınız zaman dönen sonuçların sadece tahmini olduğunu da görebilirsiniz.

    Tahmini değerlerin gösterdiği sonuçlar daima gerçekte gerçekleşenlerle birebir örtüşmez. Çünkü sorgular çalıştırılırken bir çok durum söz konusudur. Örneğin filtrelemeler uygulanırken oluşan maliyet yada satır numaralarının döndürülmesi . Tüm bunlar sorgu çalıştırımadan bilinmeyecektir. Query Engine(Sorgu Motoru) tüm bu muhtemel değerleri istatistiklere dayalı olarak hesaplar.(SQL Server veritabanında saklanan indeks ve sütun verileri hakkında istatistiki bilgiler sağlar.) Eğerki Sql server da istatistiksel hesaplamalar güncel değilse tahminlerin doğruluğu etkilenebilir.Konuda detaylı bilgi edinmek isteyenler linki inceleyebilirler. (http://sqlmag.com/t-sql/making-most-automatic-statistics-updating buradaki yazıdan istatiksel güncelleme hakkında bilgi alabilrisniz.)

    Karmaşık sorgularda geriye dönen çok fazla sayıda satırdan dolayı iki farklı şeye odaklanmak gerekir bunlardan bir tanesi Estimated number of Rows (Tahmini satır sayısı) ve Estimated Subtree Cost . Aslında tahmini satır sayısı zaten kendini isminden dahi açıklıyor.  Estimated Subtree Cost bir işlemin ve onun alt işlemlerinin işlemciye olan kümülatif maliyetleri olarak tanımlanmıştır.

    Sql Server 2005 Book online da yazılanlara göre maliyet ölçümü, "hesaplanan tahimini süre; aslında donanımsal konfigürasyonun  sorguyu tamamlaması gerektiği süredir." Bu tahminler SQL Server developer'lar tarafından test makinelerinde gerçekleşmektedir. Bundan dolayı işlemci maliyetleri hesaplanmasında tahminlerde %100 doğruluk söz konusu değildir. Şunu söylemekte fayda var sorguların  çalıştırımasında geçen süre  ve burada oluşan  performans düşüklüğü yada artışı  donanımsal özellikleriyle oldukça yakından ilgilidir.

    Bir çok farklı sorgu yazıp bunları kendi makinelerinizde tahmini değerleri ve çalıştırıp gerçek değerlerini inceleyin. Bu incelemerden sonra sizde, donanımıza uygun ne tür işlemlerin işlemci maliyetleri açısından kafanızda  bir alt eşik oluşturacaktır.
   

   

MS SQL Aggregate Function Konu Anlatımı (Video)

MS SQL Server  Aggregate Function  video konu anlatımı:

Hakkımda

  Bu bloğun yazarı, birçoğunuz gibi buralarda araştırma yapıp öğrenmeye çalışan, SQL alanında kendini yetiştirmek isteyen ve her yeni öğrendiği şeyi burada sizinle paylaşıp nitelikli Türkçe dökümanlara bir parça da olsa katkıda bulunmak isteyen biri. 
   Bu konuda maalesef daha çok yol almam gerektiğinden, alaninda uzman kaynaklardan araştırma yapıp yabancı dökümanları inceliyorum ve burada size Türkçe olarak sunmaya çalışıyorum. Bundan dolayı yazılarımda herhangi bir yanlış ifadeye rastlamaniz durumunda bunu benimle paylaşırsanız size minettar olurum :) Böylece hem okuyucularima yanlış bir bilgi aktarmamı engelleyecek hem de bana da yeni bir şey öğretmiş olacaksınız. Umarım bloğumda faydalanacağınız konular bulabilirsiniz. Diğer yazılarimda görüşmek üzere, hoşçakalın :)


İletişim:
yasin.muftuler@gmail.com

Yasin Müftüler Özgeçmiş

Özgeçmiş'i görüntülemek için tıklayın.