Comand Prompt’ta yine sqlcmd komutuyla veritabanına bağlanabiliyorsak, “Select @@VERSION” yazarak yine versiyon görüntüleyebiliriz.

2- Error Log dosyasını notepad ile açtığınızda en üst satırda versiyon bilgisini içeren bir satır bulunur. Error Log dosyasını, kendi kurulumunuzdaki versiyon farklılığını da gözönüne alarak  şu path’den bulabilirsiniz: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log.
 SSMS içerisinden de bu log, Management>>SQL Server Logs altında açılabilir. Current log u seçip açtığınızda en alt satıra geldiğinizde yine versiyon bilgisini görebilirsiniz.

3 – SQL Server Management Studio’da sunucu isminde görebilirsiniz. Burada gördüğümüz rakam kurulu versiyonun numarasıdır. Bu numaralar şu versiyonları ifade etmektedir.
SQL Server 2019:15 , 2017:14, 2016:13,2014:12, 2012:11, 2008R2:8.5 , 2008:10

4 – Object Explorer’da sunucu ismine sağ tuş >> Properties penceresinde version bilgisinde yine bir üstteki maddedeki rakama ulaşılabilir.

5- Sunucu üzerindeki veritabanlarından herhangi birine sağ tuş>> properties penceresinde Options tabı içerisinde “compatibility level”  açılır kutusunda en yüksek veritabanı hangisi ise kurulu sql server versiyonu da odur.

6 – EXEC sp_server_info komutunu çalıştırdığınızda DBMS_VER kolununda versiyon bilgisine yine ulaşabilirsiniz.

SQL Server versiyonunu öğrenmek yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

1- SQL Server Configuration Manager’ı açıyoruz.
2- Servis özellikleri penceresini açalım. Startup parametreleri tabına geçelim. Alttaki barı sağa çektiğimizde bu parametrelerden bir tanesinin master veritabanının data dosyasına, bir tanesinin de log dosyasına ait path olduğunu görürüz.

3- Bu parametreleri yeni dosya yoluna ayarlayalım.
4- SQL servisini durduralım.
5- Master veritabanının mdf ve ldf dosyasını yeni konumuna taşıyalım.
6- Servisi yeniden başlatalım.

MSDB, MODEL ve TEMPDB veritabanlarını taşımak için ise ALTER DATABASE .. MODIFY FILE komutunu kullanıyoruz. Sonrasında servisi durdurup, dosyaları yeni konumuna taşıyıp, servisi yeniden başlatıyoruz. Ancak TEMPDB veritabanı servis her başladığında baştan oluşturulduğu için, dosya taşımaya gerek yok. Yeni path girildikten sonra eski konumdan, eski dosyaları silmek yeterli.

Örnek:
ALTER DATABASE tempdb
MODIFY FILE (NAME= tempdev, FILENAME = “Z:\yeni path\tempdb.mdf’);

ALTER DATABASE tempdb
MODIFY FILE (NAME= templog, FILENAME = “Z:\yeni path\templog.ldf’);

Bu komutlar çalıştırıldıktan sonra servis restart edilmek zorundadır.

Master veritabanını taşımak yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

TempDb geçici işlemlerin tutulduğu bir sistem veritabanıdır. Diğer sistem veri tabanlarına nispeten daha kritik bir konumdadır. Genel olarak şunları barındırır:

• Geçici tablolar (temp tables) ve bu tablolara ait veriler
• İstatistik güncellemeleri (Statistics updates)
• Trigger’lar
• Online index işlemleri (sort_in_tempdb)
• Cursor’lar
• Geçici değişkenler
• DBCC CheckDb komutu operasyonları
• Join işlemleri

SQL Server servisini yeniden başlattığımızda TempDB tekrar drop edilip oluşturulur. Diğer veritabanları gibi sürekli değildir. Servis her başladığında Model veritabanından kopyalanarak oluşturulur. TempDB’nin yedeği alınamaz, yedekten geri dönülemez ve recovery modeli değiştirilemez. Simple modeldedir. Drop edilemez. Filegroup sayısı artırılamaz. Collation bilgisi değiştirilemez. Offline ya da read only mode’a alınamaz. Yukarıda sıraladığımız içeriğinden dolayı, sorgu performansını direkt etkileyen bir sistem veritabanıdır.
TempDb’de bir geçici tablo oluşturduğumuzda, normal veritabanında tablo oluşturduğumuzda nasıl yer ayrılıyorsa (allocation), tempdb de de öyle bir allocation süreci işler. Bu süreçte üç page sözkonusudur. PFS(Page Free Space) , GAM(Global Allocation Map), SGAM(Shared Global Allocation Map). Bir sql server objesini oluşturmak ya da silmek için Sql server PFS ve SGAM page’lerine yazar. Latch dediğimiz, aşağıda açıkladığımız yapılar bu page’leri hafızada korur. Her bir tempdb data file için birer adet PFS ve SGAM page mevcuttur.

PFS(Page Free Space) : Her page için bir byte’lık bir bilgi tutar. Bu bilgi , ilgili page de ne kadar boş alan olduğunu, ne için kullanıldığını tutar. Bir PFS page yaklaşık 64MB boyutunda page’e dair bilgileri tutar. Bir data file içerisinde her 64MB için bir PFS page den söz edebiliriz. Herhangi bir veritabanı data file için ilk page PFS dir. Page ile ilgili bir veritabanı hatasında bunu görebiliriz. Örneğin 2:1:1 ifadesi, database id:2 ve 1 numaralı page demektir. Keza tempdb içn şu ifade 5:3:1 database id : 5, file id:3 ve ilk PFS page i göstermektedir.
GAM (Global Allocation Map) : GAM Page her extent (8 page) için, hangisinin dolu hangisinin boş olduğunu gösteren bir bitlik bir bilgi tutar. SQL Server boş extent’leri bu page’lere bakarak tespit eder. Her extent için bir bit kullanılması bir GAM page’in 4GB bir alanı yönetmesine olanak tanır. Bir data file’daki ilk GAM page’in page numarası 2’dir. 2:1:2 TempDB deki ilk GAM page’i gösterir.
SGAM (Shared Global Allocation Map) : Her extent için yine bir bit olarak mixed extent mi full extent mi bilgisini tutar. SQL server küçük verileri yerleştirmek için boş alan içeren mixed extentleri bulmak için bu page’i kullanır. GAM gibi 4GB lık bir alanı yönetir. Bir data file daki ilk SGAM page’in numarası 3 tür. Yani 2:1:3 tempdb nin ilk SGAM page’idir.

Tempdb içerisinde çok fazla nesne oluşturulduğunda tempdb contention oluşur. Yukarıda bahsettiğimiz PFS, GAM ve SGAM page’lerinde exclusive lock durumu oluşur. Bu durumda sistemde PAGELATCH_xx wait türü görülmeye başlanabilir. Bu beklemenin tempdb contention kaynaklı olduğuna amin olabilmek için wait’in açıklamasında page’a dair 2:1:1 gibi bir rakam dizisi görülüyorsa bu beklemenin tempdb contention kaynaklı olduğu söylenebilir. Zira rakam dizisindeki ilk rakam veri tabanı id’sidir ve tempdb’nin id’si 2’dir.

Latch Kavramı
Buffer pool, işletim sisteminin SQL server için hafızada(memory) rezerve ettiği bir alandır. SQL Server gelen taleplere göre diskten ilgili page’leri memory de buffer pool’a atar. Bu sistem içerisinde, verinin buffer pool içerisinde tutarlılığını korumak için bir sisteme ihtiyaç vardır. Latch, SQL Server’ın memory içindeki bu verinin tutarlılığını sağladığı bir lock mekanizmasıdır. Paylaşılan hafıza haynaklarını korumaya yarar. Bir thread bir page üzerinde çalışmayı talep ettiğinde, aynı anda bir page’i sadece bir thread değiştirebileceğinden bu latch üzerinde “latch queue” denilen kuyruk oluşur. Bu page taleplerini dağıtmak amacıyla tempdb data file sayısının , işlemci çekirdek sayısıyla orantılı olarak artırılması önerilir. Çünkü her bir data file için ayrı bir “latch queue” vardır. Bu data file sayısını artırma işlemi thread’in page’i bekleme süresini azaltır. Bu da sorgu performansının artması demektir. Aşağıda bu konuyu resmetmeye çalıştım.

TempdDB Metadata Contention
Birden fazla session geçici tablo oluşturduğu esnada, TempDB’nin sistem tablolarına aynı anda erişmek istediğinde metadata contention oluşur. Bu iş yükü sistem tablolarında gecikmeye sebep olur ve sorgu performansları düşmeye başlar.

TempDb yapılandırması için öneriler:

• Antivirüs taramasından SQL Server dosyalarını exclude etmek
• TempDB yi ayrı bir diskte ve mümkünse SSD üzerinde tutmak. Data ve Log dosyalarını ayrı diskte tutmak.
• Raid0 ya da Raid10 yapısında tutmak.
• TempDB yi başka uygulamaların, veritabanlarını kullandığı disklerde konumlandırmamak
• Index Rebuild işleminde “sort in tempdb” seçeneği tempdb performansını etkiler. Gereksiz kullanımından kaçınılmalıdır.
• Sec/Read ve Avg. Sec/Write oranını takip edip 50ms altında kalmasına dikkat etmek
• Şu wait türleri TempDb performansıyla doğrudan ilişkilidir. PAGELATCH_EX, PAGELATCH_UP, CXPACKET
• TempDb contention durumunu takip etmek. Microsoft’un “allocation contention” problemini azaltmak için önerilerine şu yazıdan ulaşabilirsiniz.
• TempDB data file sayısını, sisteminiz 8 core dan az ise core sayınız kadar, 8 core dan fazla ise 8 data file olarak ayarlamak. Data file boyutlarının aynı olması önemlidir. İşlemci sayısının 8 den fazla olduğu durumda 8 den fazla her 4 core için bir data file eklenebileceğini söyleyenler de vardır. Onlarca core içeren sunucular için bu düşünülebilir. Yani 12 core varsa 8 + 1 (kalan 4 core için bir file) = 9. Düşük ölçekli sunucularda daha önceleri 8 core için 8 dosya uygundu. Ancak onlarca core içeren sistemler için yük testi yaparak 8 den fazla dosya sayısına karar vermek daha yerindedir.
• Autogrowth özelliği açık olmalı. Tempdb her otomatik büyüme esnasında “exclusive lock” mekanizmasıyla kilitlenir. Bu da performansı doğrudan kötü etkiler. Veritabanı kurulurken en uygun başlangıç boyutunu (en az 2048 MB gibi) ve auto growth boyutunu vermek bu yüzden çok önemlidir.

TempDB nin sistem üzerinde tutulduğu yer bilgisi için sp_helpdb tempdb komutu kullanılabilir.

TempDb’nin kullandığı disk alanını sys.dm_db_file_space_usage DMV’sini sorgulayarak görebiliriz. Tempdb içerisinde çok fazla yer kaplayan nesneleri görmek için ise sys.dm_db_session_space_usage ve sys.dm_db_task_space_usage dmv’leri kullanılabilir.

TempDB yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Tips && Tricks yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

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

Bu bekleme türlerine (wait types) dikkat!

sys.dm_os_wait_stats view’ı çalıştırılan tüm görevlere dair bekleme durumları ile ilgili edinebileceğimiz view’dır. Aşağıdaki bekleme türlerinde performas kaybı gözlediğimizde sistemde I/O Bottleneck oluştuğunu düşünebiliriz.

•PAGEIOLATCH
•WRITELOG
•TRACEWRITE
•SQLTRACE_FILE_WRITE_IO_COMPLETION
•ASYNC_IO_COMPLETION
•IO_COMPLETION
•LOG_BUFFER

Nasıl İzlenir?

Microsoft’un «best practice» en iyi deneyimlerinde bottleneck(darboğaz) durumu ile ilgili bazı sayaçlar (performance counter) ve referans değerler belirlenmiştir. Bu darboğazı gözlemlemek için Performance Monitor aracı ve sayaçlar (performance counters) kullanılır. SQL server ile ilgili yüzlerce sayaç vardır ancak disk performansını gözlemlemek için gerekli olanları aşağıda özetlemeye çalıştım. Bunları sys.dm_os_performance_counters dmv’si aracılığıyla görebiliriz. Bu izleme yavaş diskler, tıkanan işlemler vb. sorunlarda bize yardımcı olur.

SQL Server’ın kullandığı depolama ünitelerinin performansı üç farklı yönden ölçülür. Bunlar:

• Saniyedeki I/O işlemleri (I/O operations per second, IOPS)
• Akan veri miktarı diyebileceğimiz disk throughput
• Gecikme (Disk Latency)

Bunların nasıl ölçülebileceğini sırayla açıklayalım

• IOPS şu performans sayaçlarıyla ölçülür:

Disk Reads / Sec : Saniyedeki okuma sayısı
Disk Writes / Sec : Saniyedeki yazma sayısı

• Throughput kavramı periyodik belirli bir sürede aktarılan veri miktarını ifade eder. Şu sayaçlarla ölçülür:

Disk Read Bytes / Sec : Okuma işlemleri sırasında diskten saniyede okunan veri miktarı
Disk Bytes /Sec : Okuma ya da yazma işlemleri boyunca diskten okunan ya da yazılan veri miktarı
Disk Write Bytes / Sec : Yazma işlemleri boyunca saniyede diske yazılan veri miktarı

• Latency(gecikme) I/O isteğinin oluşmasından cevap gelmesi arasında geçen süreyi ifade eder. Şu sayaçlarla ölçülür:

Avg. Disk sec / Read : Diskten veriyi okumak için geçen ortalama zaman
Avg. Disc Sec / Write : Diske veriyi yazmak için geçen ortalama zaman  

Microsoft’un her  iki sayaç için best practice değerleri şunlardır:

Log Dosyaları için 1-5 ms (1ms ideal)
OLTP Data dosyaları için 4-20 ms (10 ms ideal)
OLAP Data dosyaları için <= 30 ms

Aşağıdaki tabloda I/O performansını ölçmek için kullanılan diğer bazı sayaçların anlamlarını ve referans değerlerini görebiliriz. 

I/O Bottleneck 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ı.