SQL server’a bir veri isteği geldiğinde bu istek normal, optimum şartlarda işlemcinin hızına göre hemen gerçekleştirilebilecek bir işlem iken, kaynakların (ram, işlemci core sayısı, disk boyut ve hızı vb.) sınırlı olması ve gelen isteğin çokluğu sebebiyle işlemci bu istekleri hemen yerine getiremez, bir işlem kuyruğuna sokar ve bu istekler için bekleme sözkonusu olur. İşte SQL Server bu beklemeleri türü, süresi vb. bilgileriyle kaydeder. Çeşitli bekleme türleriyle ilgili bu kayıtlara wait statistics adı verilir. Yüzlerce wait türü vardır. Performans analizi yapabilmemiz için çok önemli göstergelerdir. Performance counters ile birlikte yorumlamak daha doğru sonuçlar üretmemizi sağlar.

Beklemeler temel olarak iki kategoriye ayrılır:

Kaynak Beklemeleri (Resource Wait) : Görev bekleme listesindedir ve suspended statüsündedir. Disk/hafıza’da yazma/okuma beklemesi ya da başka bir transaction tarafından kilitlenen page’in beklenmesi gibi.

Sinyal Beklemeleri (Signal Wait) : Görev runnable statüsündedir ancak işlemcide sıra beklemektedir

 SQL server’a bir istek(request) geldiğinde bu istek kendisine bir “worker thread” atanan bir  göreve dönüştürülür. Bir istek “worker thread” talep ettiğinde,  SQL server bu isteğe atamak için boşta bir worker thread arar. Bulamazsa ya da sunucunun maximum worker threads limitine ulaşılmışsa istek kuyruğa eklenir ve herhangi bir worker thread’in boşa çıkmasını bekler. Worker thread sayısı sunucumuzun özelliklerine göre parametrik belirlenen bir rakamdır. Örneğin 64 bit ve 4’ten fazla core içeren bir sunucuda worker thread sayısı 512+((core sayısı -4)*16) formülüyle bulunur. 16 core içeren bir sunucu için bu rakam 704 e tekabül eder. Aşağıdaki ekranda maximum worker threads ile iligili bir ayar sözkonusudur.

 Proses diskte yüklü uygulamanın çalıştırıldığı, hafızaya yüklendiği, işlemci tarafından yürütüldüğü anda aldığı isimdir. Bir proses birden fazla thread barındırabilir ve buna multithreading adı verilir.

  Örneğin bir select sorgusu çalıştırdık diyelim, bu sorgunun istediği bilgi için önce buffer pool’a bakılır. Burada yoksa diske gider thread, diskten yanıt beklediği sırada suspended statüsündedir ve PAGEIOLATCH wait türü oluşur. Veri diskten alınıp buffer pool’a taşındığında statüsü runnable dır ancak bu kez de CPU zamanlayıcısından sinyal beklemeye başlar. Kuyruğun sonundadır. CPU core ları başka threat lerle meşguldür. Sıra kendisine geldiğinde listenin başına alınır ve sorgu çalıştırılır. Her ne kadar bu işlemlerin bazısı eş zamanlı gerçekleşse de aşağıda bu işlemleri bir nebze sıralı olarak şematize etmeye çalıştım:

Wait istatistiklerine ait bilgi alabileceğimiz iki önemli DMV (dynamic management view) vardır:
sys.dm_os_waiting_tasks :  herhangi bir kaynağı bekleyen aktif görevleri
sys.dm_os_wait_stats :  instance seviyesinde, sql server servisinin son başlamasından bu yana toplam bekleme sürelerini gösterir.

Sunucunun son başlamasından bu yana toplanmış olan bu istatistikler aşağıdaki komutla temizlenebilir:

DBCC SQLPERF(‘sys.dm_os_wait_stats’,CLEAR);Bir de SQL Server 2016 versiyonuyla birlikte gelen sys.dm_exec_session_wait_stats view’ı vardır ve session bazında thread’lerin karşılaştığı beklemeleri gösterir.

 Yukarda bahsettiğimiz sys.dm_os_wait_stats view’ını sorguladığımızda aşağıdaki bilgileri alırız:

Wait_type : Gerçekleşen bekleme türü
Waiting_task_count : Bu bekleme türü kaç kez gerçekleşti
Wait_time_ms : Wait_type alanında belirtilen beklemenin toplam geçen zamanı. signal_wait_time_ms bekleme süresini de içerir. Runnable ve suspended statüsünde kuyrukta harcanan toplam zamanı gösterir. 
Max_wait_time_ms : Bir thread in bu bekleme türü için beklediği en fazla süre
signal_wait_time_ms : Thread’in runnable statüsünde kuyrukta CPU beklediği zaman. Yüksek değerler görüyorsak CPU darboğazı(bottleneck) olduğunu düşünürüz.

Latch, Hafızadaki veriyi korumak için kullanılan bir lock mekanizmasıdır ve kullanıcı tarafından kontrol edilemez. Bir proses latch için beklediğinde de bazı beklemeler oluşur. Latch’in üç türü vardır ve bu üç türe göre aşağıdaki isimlendirmelerde beklemeler kaydedilir: 
      – I/O Latch : PAGEIOLATCH_*
      – Buffer Latch : PAGELATCH_*
      – Non-buffer latch : LATCH_*

Yukarıdaki tanımlamalardan sonra SQL Server’ı gözlemlemek için hangi wait türlerinin takibinin önemli olduğu konusuna geçebiliriz. CPU yoğunluğu, I/O yoğunluğu, memory yoğunluğu, block/deadlock durumları gibi durumları analiz etmek için yaygın olarak gözlemlediğimiz wait türleri vardır. Yüzlerce bekleme türü var ancak SQL Server performansını gözlemlemek için yaygın olarak aşağıdakiler izlenir.

PAGEIOLATCH_* : Bir görev buffer pool’da olmayan bir Page’in diskten getirilmesini bekliyor. I/O yoğunluğu yüksek veri tabanlarında çok sık görülen bir beklemedir. Bu beklemeyi sık görüyorsak diskte I/O darboğaz(bottleneck) oluştuğundan söz edebiliriz. Disk sistemlerinizin Sql Sever’a cevap vermekte yavaş kaldığına işaret eder. Ancak bu gecikme başka sebeplerden de kaynaklanabilir. Optimize olmayan sorgular, index sorunları, güncel olmayan istatistikler, implicit conversion gibi konular da sebep olabilir. _sh shared latch , _up update latch, _ex exclusive latch için beklendiğini gösterir.

PAGELATCH : PAGELATCH beklemesi, bir görevin(task), başka bir task tarafından latch edilmiş(lock), buffer pool’daki page’e erişmek için beklediğini gösterir. İndex’lemenin gözden geçirilmesi, partitioning çalışması ve tempdb performansının iyileştirimlesi gibi çalışmalarla azaltılabilir. 

WRITELOG : Transaction commit edildiğinde ya da checkpoint işleminde log block diske yazılırken oluşan bekleme türüdür. Bir task transaction log bloğunun diske yazılmasını beklemektedir. Çok sık karşılaşılıyorsa transaction log’ların bulunduğu disklerde bir problem varlığından söz edilebilir. Ancak yine tek sorun diskler olmayabilir. Çok fazla transaction çok sık aralıklarla commit ediliyorsa bu da sebep olabilir. Transaction sayısı azaltılabilir. Yine gereksiz index’ler de bu beklemeye sebep olur. Bir tabloda ne kadar fazla index varsa, tablo her insert/update aldığında oluşan log miktarı da o kadar fazla olur. İndex parçalanmaları da yine bu beklemeye sebep olabilir. 

LCK_M_* : Thread veriye erişmek ve lock koymak için başka bir görevin kilitlediği kaynağı bekliyor. M harfinden sonra gelen harf lock türünü gösterir. LCK_M_S shared lock, LCK_M_U update lock, LCK_M_X exclusive lock bazı örnekleridir. 60’dan fazla türü vardır. Şu sebeplerle görülür genel olarak:
– Büyük bir tablo tarama ya da update işlemi tabloda “lock escalation” a sebep oluyor.
– Ulaşılan datadaki gereksiz shared lock’lar 
– Optimize edilmesi gereken update, insert sorguları var (LCK_M_U )
– Optimize edilmesi gereken select sorguları var (LCK_M_S )

RESOURCE_SEMAPHORE : Bir worker thread bir sorgu için memory kaynağı beklerken ortaya çıkar. Çok fazla hafıza ihtiyacı olan eş zamanlı sorguların çok fazla olduğu sistemlerde görülür. Bu bekleme türünü ve memory_allocation_ext beklemesini alıyorsak veri tabanımız üzerinde memory baskısı olduğunu düşünebiliriz.

I/O_COMPLETION, ASYNC_I/O_COMNPLETION : Backup gibi uzun süren I/O işlemlerinde görülebilir. Bu bekleme türünü görüyorsak diskte bir darboğaz(bottleneck) oluştuğunu düşünebiliriz.

CXPACKET : Paralel sorgu çalıştırılması sırasında thread’lerin senkronizasyonu için beklenen zamandır. Kaynaklara dair bir darboğaz olduğunu göstermez. Veri tabanında paralel sorguların çalıştığını ve beklenenden fazla zaman aldığını gösterir. Belirli bir miktar işi on tane işçiye paylaştırdığımızı farzedelim, işçilerden bazıları işlerini erkenden bitirdi ve yeni iş bekliyorlar. İstatistikler güncellenerek azaltılabilir.

SOS_SCHEDULER_YIELD: Thread’in işlemciden zamanlayıcı(scheduler) beklediği ve runnable statüsünde olduğu süredir.

THREADPOOL : Yukarda daha önce bir isteğin kendisine “worker thread” atanması için beklediğinden bahsetmiştik. Bu bekleme o anda oluşur. İşlemci sayısına göre worker thread sayısı olduğunu gözönüne alırsak, bu beklemeyi sürekli görüyorsak sunucumuzun işlemci core sayısını artırmamız gerektiğini düşünebiliriz. Ya da maximum worker thread sayısı düşük kalmış olabilir.

ASYNC_NETWORK_IO : Network’te darboğaz oluştuğu gibi yorumlanır ama tek sebebi bu değildir. Veri tabanımızı kullanan uygulamanın satır satır veri çekip işlediği durumlarda oluşur. Bir satır çeker işler, bir satır daha çeker işler böyle devam eder. İstemcinin veri tabanından çektiği veriyi kullanma şekli sebebiyle oluşturduğu bir beklemedir. 

HADR_WORK_QUEUE : Always On yapısına dahil olan veri tabanları için ayrılmış olan thread’lerin görev atanmasını beklediklerini gösterir. Boşta kalma bekleme süresini gösterdiği için yüksek olması umulur.

Son olarak, beklemeler tek başlarına tüm sistem performansı hakkında yeterli bilgi vermezler. Sql Server’ı barındıran işletim sisteminin performansına dair bazı bilgilere de ihtiyaç duyarız. İşletim sistemine dair bu bilgilere de performans counters adı verilen sayaçları izleyerek ulaşırız. Bu sayaçlar bize sistem kaynakları üzerindeki yoğunluğu ve beklemeleri(queue) gösterir. Wait türlerini ve kuyrukları(queue) birlikte izlemek daha iyi sonuç verecektir

SQL Server’da Wait Statistics Konusu yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Full Backup : İsminden tahmin edileceği üzere veritabanının tamamının kopyasının alınmasıdır. Kopyanın alındığı tarih ve saate, veritabanımızı başka bir dosyaya ihtiyaç duyulmadan restore yani geri yükleme yapabiliriz.

Differantial Backup : Bir önceki full backup’tan bu yana veritabanında yapılmış olan değişikliklerin yedeğidir. Büyük boyutlu, yoğun işlem gören veritabanlarında sürekli full backup almak hem donanım kaynakları açısından hem de zaman yönetimi açısından maliyetli bir işlemdir. Bu maliyeti tolere edebilmek differantial backup alarak mümkündür. Bu backup türü bir full backup’ı temel alır ve temel aldığı full backup tan bu yana veritabanının uğradığı değişiklikleri tutar. Dikkat edilecek önemli nokta şudur ki; differential en son alınan full backup’tan bu yana yapılan değişikliklerin yedeğidir. Bir önceki differential backup’tan bu yana alınan değişikliklerin yedeği değildir.

Transaction Log Backup :  Transaction Log veritabanı üzerinde yapılan her bir değişikliğin kaydının tutulduğu log dosyasıdır. Bu logların yedeğinin alınması da üçüncü backup türümüzdür. Transaction Log backup veritabanımızın son full ya da differential yedekten sonra tutarlılığını sağlar. Bu yüzden yoğun işlem gören veritabanlarında olmazsa olmazdır.

Backup konusunun ve özellikle transaction log backup’ın anlaşılabilmesi için transaction log yapısının anlaşılması çok önemlidir. Transaction Log bir ya da daha fazla fiziksel dosyadan oluşabilir. Ancak Sql Server transaction log dosyalarını sequential yani sıralı olarak kullanır, eş zamanlı paralel olarak kullanmaz. Bu yüzden birden çok transaction log dosyasının log performansı anlamında bir katkısı yoktur. Diskte ayrılan tüm alana fiziksel log, bu fiziksel alan içerisindeki loga logical log (mantıksal log) adı verilir. Kavramsal olarak log kayıtlarından oluşan bir dizidir transaction log ve başında 8KB boyutunda header bulunur. Bu header tr log dosyasına ait boyut ve auto growth ayarları gibi bilgiler tutar.

Sql server motoru transaction log dosyasını, belirli parametrelere göre VLF olarak kısaltılan Virtual Log parçalarına böler. Bu parçalı yapı tr log’un yönetimini kolaylaştırır. VLF sayısını ya da boyutunu biz belirleyemeyiz. Şöyle ki;
Transaction Log dosyası boyutu 64 MB dan küçükse 4 VLF, 64MB ile 1GB arasındaysa 8VLF, 1GB’dan büyükse 16 VLF oluşur. Verdiğimiz autogrowth boyutuna göre vlf sayısı ve log boyutu bu parametrelere göre artmaya devam eder. Transaction Log sarmal (circular) bir yapıya sahiptir.

Eğer VLF içerisinde bir log kaydı var ise bu aktif bir VLF dir ve SQL server bu alanı kullanamaz. Yeni oluşturulan VLF inaktif ve kullanılmaz durumdadır. Yeni oluşturulmuş veritabanı hariç ilk VLF de her zaman kullanılır. Bir transaction log da en az bir tane VLF aktif ve kullanılıyor durumda olur. Bu VLF’lerin içerisinde de boyutları 512 byte ila 60 kb arasında değişen ve log kayıtlarını tutan log blokları bulunur. Log blok dolduğunda diske yazılmak zorundadur. Transaction Log Backup alındığında log truncate edilir yani commit olan kayıtlar diske yazılarak, bu kayıtları tutan VLF ler boş olarak işaretlenir ve unused statüsüne geçer yani kullanıma açılır. Truncate işleminin bu kayıtları sildiği bilgisi genelde yanlış algılanmış bir bilgidir. Kaydı içeren VLF kullanılabilir olarak işaretlernir. Ancak VLF açık bir transaction’a ait log kaydı barındırıyorsa istisnadır ve aktif durumda kalabilir. Log truncate etmenin tek yolu log backup’ı almaktır. Log dosyasının büyümesini engellemek için mümkün olduğunca sık transaction log backup alınır. Log’u truncate etmeden backup almanın yolu “Copy Only” backup seçeneğidir. Copy Only backup konusunda şu yazıdan detaylı bilgi alabilirsiniz. Aşağıdaki şekildeki MinLSN değeri log içerisindeki en eski ve açık transaction’a ait LSN değeridir. Sql Server peşi sıra gelen tüm kayıtları logical log’un sonuna yazar.

Backup Zinciri && LSN Numaraları

SQL Server transaction log içerisindeki her kayıt için kendine ait bir sıra numarası verir. Bu sıra numarasına «Log Sequence Number, LSN» adı verilir. LSN numarası büyük olan kayıt log dosyasına LSN numarası küçük olan kayıttan sonra işlenmiştir. Log yedekleri LSN değeri üzerinden son Full backup ı referans alarak bir backup zinciri oluşturur. LSN üç parçadan oluşan decimal ya da hexadecimal formatta bir sayıdır
•VLF sıra numarası (Virtual Log File)
•Log Blok Numarası
•Log Kayıt Numarası

RESTORE HEADERONLY FROM DISK = 'fullyedek.bak'
Bu komut bize yedeğin niteliklerine dair birçok bilginin yanında dört tane LSN değeri döndürür
FirstLSN –Backup seti içerisindeki ilk transaction’a ait Log Sequence Number
LastLSN – Backup setinden sonraki ilk log kaydının LSN‘i
CheckpointLSN – Son checkpoint’e ait LSN
DatabaseBackupLSN – Son full backup’a ait LSN

CHECKPOINT işlemi memory’de veri üzerinde yapılan değişikliklerin diske kaydedilmesidir. Diskten buffer cache’e getirilen data değiştiğinde henüz diske yaılmadığı için dirty page olarak adlandırılır. Verideki bu değişime dair log buffer’da bir log record oluşur. Log Flush adı verilen işlemle Log buffer’daki bu kayıt transaction log dosyasına yazılır. Hemen akabinde de buffer cache’deki ilgili değişiklik diskteki mdf dosyasına yazılır. Yani önce transaction log dosyasına sonra mdf dosyasına yazılır. Bir felaket durumunda log dosyası ile verinin tutarlılığının korunması için gerçekleşen bu mekanizmaya write ahead logging denir.

Bir veritabanını restore ederken, LSN zincirine dikkat etmek gerekir. Aksi takdirde şu hata alınır “Unable to Create Restore Plan Due to Break in the LSN Chain”. LSN zincirini korumak için şu hususları bilmek faydalı olacaktır:

Alınan ilk full backup’da DatabaseBackupLSN değeri daima sıfırdır.
Alınan ilk full backup’da FirstLSN ve CheckpointLSN değerleri aynıdır.
Veritabanını geri yükleyeceğimiz zaman hangi differential backup bizim full backup’ımızla ilintiliyse anlamak için
DatabaseBackupLSN (differential backup) = CheckpointLSN (full backup)

Eğer differential backup’ımız yoksa, full backup ve transaction log yedeklerimiz varsa LSN zincirini korumak için şu konuya dikkat etmemiz gerekir:
FirstLSN(TransactionLog) < LastLSN (Full Backup) < LastLSN(TransactionLog)

Differential backup’tan sonra hangi transaction log’un geleceğini anlamak için:FirstLSN(TrLog) < LastLSN(Diff) < LastLSN(TrLog)

Transaction Log LSN zincirini de aşağıdaki şekildeki gibi kontrol edebiliriz.

Bütün bu bilgiler ışığında veritabanı restore işlemleri aşağıdaki ekrandan yapılır. LSN zinciri bozulmadığı sürece bir sorun çıkmayacaktır. Veritabanımızı elimizdeki yedeklerimizin elverdiği istenilen zamana geri döndürebiiriz.

Son olarak veritabanı simple recovery modeldeyken de bir transaction log dosyamız vardır. Ancak bu modda transaction’lar bu log dosyasında kısa bir süre için (aktif olduğu süre boyunca) tutulur. Transaction buffer’dan diske yazıldığında (checkpoint işlemiyle log flush işlemi yani log buffer’dan transaction log’a) log truncate edilir. Yani yukarıda bahsedildiği gibi, logdaki vlf’ler kullanılabilir(unused) statüsüne alınır. Full modda belirttiğimiz boyut dolduğunda, log dosyası döngüsünde yeni log dosyası oluşturulurken, burada varolan dosya üzerine dönüp dönüp tekrar yazar. Bu yüzden “point in time recovery” mümkün değildir

SQL Server’da Backup Seçenekleri, Transaction Log Yapısı ve Restore yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.