1. Transaction Log'un Yapısı ve Çalışma Prensipleri

Transaction Log (İşlem Günlüğü), SQL Server'ın veri bütünlüğünü ve kurtarılabilirliğini garanti eden temel bileşenidir. Her veritabanı, veritabanı dosyalarından ayrı bir fiziksel dosya olarak tutulan kendi işlem günlüğüne sahiptir. Log dosyası, veritabanında gerçekleşen tüm değişiklikleri sıralı ve atomik bir şekilde kaydeder. Bu prensip, WAL (Write-Ahead Logging) olarak adlandırılır ve herhangi bir veri değişikliğinin önce log'a, ancak daha sonra veri dosyasına yazılacağını belirtir.

Log kayıtları, her bir işlemi (transaction) oluşturan mantıksal işlemleri tanımlar. Her kayıt benzersiz bir Log Sequence Number (LSN) ile işaretlenir. LSN'ler, log kayıtlarının sıralı düzenini korumak ve kurtarma işlemlerini yönetmek için kritik öneme sahiptir. Log dosyası içinde, sanal log dosyaları (VLF'ler) olarak bilinen daha küçük kesimlere bölünür; bu yapı, log alanının yönetimini ve yeniden kullanımını kolaylaştırır.

Kurtarma süreci, log kayıtlarının bu sıralı yapısına dayanır. SQL Server başlatıldığında, her veritabanı için bir otomatik kurtarma işlemi gerçekleştirir. Bu işlem, tamamlanmamış işlemleri geri almak (ROLLBACK) ve belleğe alınıp diske yazılmamış tamamlanmış işlemleri ileri almak (ROLLFORWARD) için log'u inceler, böylece veritabanını tutarlı bir duruma getirir.

Log Kaydı Bileşeni Açıklama
LSN (Log Sequence Number) Log kaydının sıralı ve benzersiz tanımlayıcısı.
Transaction ID Kaydın ait olduğu işlemi tanımlar.
Önceki LSN Aynı işlem içindeki önceki kaydı işaret eder, zincir oluşturur.
İşlem Türü Kaydın hangi operasyona (INSERT, UPDATE, DELETE, BEGIN TRAN vb.) ait olduğu.
Veri Değiştirilen verinin eski (before image) ve/veya yeni (after image) hali.

Log'un fiziksel yazma işlemi, daha yüksek g/ç performansı sağlamak için log tamponu kullanılarak gerçekleştirilir. Log yazıcı (Log Writer) süreci, tampondaki log kayıtlarını diskteki log dosyasına sürekli olarak yazar. Bu yazma işlemi sıralıdır; bu nedenle, mekanik disklerde bile veri dosyalarına kıyasla genellikle çok daha hızlıdır.

Transaction log'un etkin yönetimi, performans ve kurtarılabilirlik için hayati öneme sahiptir. Yetersiz yönetim, log dosyasının kontrolsüz büyümesine, disk alanının tükenmesine ve sonuç olarak veritabanı operasyonlarının durmasına neden olabilir. Log yönetim stratejisi, seçilen kurtarma modeli tarafından belirlenir ve düzenli yedekleme gerektirir.

Sonuç olarak, transaction log, SQL Server'ın ACID (Atomicity, Consistency, Isolation, Durability) özelliklerini, özellikle de Dayanıklılık (Durability) ve Atomiklik (Atomicity) ilkelerini uygulamasını sağlayan merkezi bir mekanizmadır. Yapısını ve çalışma prensiplerini anlamak, etkin veritabanı yönetiminin ilk adımıdır.

2. Transaction Log Yedekleme ve Kurtarma Modelleri

SQL Server, transaction log'un nasıl yönetileceğini ve ne kadar süreyle saklanacağını belirleyen üç temel kurtarma modeli sunar: Basit (Simple), Tam (Full) ve Toplu İşlenmiş (Bulk-Logged). Bu model seçimi, kurtarma hedeflerinize (RTO, RPO) ve iş yükünüzün doğasına göre yapılmalıdır.

Basit Kurtarma Modeli, yönetimi en kolay olandır. Bu modelde, işlem günlüğü kayıtları, ilgili işlem tamamlanıp veri dosyalarına yazıldıktan sonra otomatik olarak kesilebilir (truncated) ve kullanılabilir alan geri kazanılır. Ancak, log yedeklemesi mümkün olmadığı için, yalnızca en son tam veritabanı yedeğine kadar olan noktaya kurtarma yapabilirsiniz. Bu model, geliştirme ortamları veya veri kaybına karşı hassas olmayan sistemler için uygundur.

Tam Kurtarma Modeli, en kapsamlı veri korumasını sağlar. Bu modelde, tüm işlemler log'a ayrıntılı bir şekilde kaydedilir ve log, açıkça bir log yedeği alınana kadar kesilmez. Düzenli log yedekleri alarak, bir arıza durumunda veritabanını herhangi bir noktaya (son log yedeğine kadar) kurtarabilirsiniz. Bu, veri kaybı penceresini birkaç dakikaya, hatta saniyelere indirebilir. Tam model, üretim sistemlerinde veri kaybına tahammülün olmadığı durumlar için standarttır.

Toplu İşlenmiş Kurtarma Modeli, Tam modelin bir varyasyonudur. Çoğu işlem tam olarak log'lansa da, SELECT INTO, BULK INSERT gibi büyük toplu işlemler minimum düzeyde log'lanır. Bu, log büyümesini ve yedekleme süresini azaltırken, bu toplu işlemlerin sırasında bir log yedeği alınırsa, kurtarma işleminin bütünlüğünü korur. Ancak, bir toplu işlem sırasında bir log dosyası hasar görürse, o işlemden son log yedeğine kadar olan tüm değişiklikleri kaybedebilirsiniz.

Kurtarma Modeli Log Yedeklemesi Noktasal Kurtarma Log Büyümesi Riski Önerilen Kullanım
Basit Desteklenmez Son Tam/Coklu Yedek'e Kadar Düşük (Otomatik Kesme) Geliştirme / Test / Raporlama
Tam Gereklidir Herhangi Bir Zamana (PIT) Yüksek (Yedek Alınmazsa) Üretim (Kritik Veri)
Toplu İş Desteklenir Toplu İş İçeren Log Yedeği Hariç PIT Değişken Periyodik Büyük Veri Yüklemeleri

Log yedekleme stratejisi, kurtarma modeline bağlıdır. Tam veya Toplu İş modelinde, düzenli log yedekleri alınmazsa, log dosyası süresiz olarak büyümeye devam edecek ve tüm disk alanını tüketecektir. Log yedeklemesi, etkin log kısmının (henüz yedeklenmemiş olan) bir kopyasını oluşturur ve bu VLF'leri etkin olmayan duruma getirerek, belirli koşullarda yeniden kullanılabilir hale gelmelerini sağlar.

Bir kurtarma planı tasarlanırken, tam veritabanı yedekleri, diferansiyel yedekler ve transaction log yedeklerinin kombinasyonu kullanılır. Örneğin, haftalık tam yedek, günlük diferansiyel yedek ve 15 dakikada bir log yedeği alan bir strateji, hem kurtarma süresini (RTO) hem de olası veri kaybını (RPO) yönetilebilir seviyelerde tutar.

Kurtarma işlemi, yedeklerin tam tersi sırayla geri yüklenmesini gerektirir: en son tam yedek, varsa en son diferansiyel yedek ve ardından sırayla tüm transaction log yedekleri. SQL Server, log yedeklerini uygularken, işlemleri tam olarak orijinal sıralarıyla yeniden oluşturur ve veritabanını tutarlı bir duruma getirir.

Özetle, doğru kurtarma modelinin seçimi ve buna uygun bir yedekleme stratejisinin sürekli uygulanması, iş sürekliliğinin ve veri güvenliğinin temel taşıdır. Transaction log yönetimi, pasif bir depolama alanı yönetiminden ziyade, aktif bir veri koruma disiplinidir.

3. Log Büyümesi ve Boşluk Yönetimi

Transaction log dosyasının kontrolsüz büyümesi, SQL Server yöneticilerinin en sık karşılaştığı sorunlardan biridir. Bu büyüme, genellikle düzenli log yedeklerinin alınmaması, uzun süren açık işlemler veya büyük toplu işlemler gibi belirli operasyonel koşulların bir sonucudur. Log dosyası otomatik olarak genişlese de, bu işlem performansı olumsuz etkiler ve disk alanını tüketerek sistemi riske atar.

Log büyümesinin temel nedenlerini anlamak, sorunu kökten çözmek için kritiktir. En yaygın neden, Tam Kurtarma Modeli kullanılırken log yedeklerinin ihmal edilmesidir. Log, yalnızca bir log yedeği alındığında kesilebilir ve yeniden kullanılabilir alan yaratılır. Eğer yedek alınmazsa, log sürekli büyümeye devam eder. Diğer bir yaygın neden, çok uzun süren (saatlerce veya günlerce açık kalan) bir kullanıcı işlemidir; bu işlem, en eski etkin LSN'yi ilerletemediği için tüm VLF'lerin etkin kalmasına ve temizlenememesine yol açar.

Log dosyasının mevcut durumunu ve büyüme baskılarını analiz etmek için birkaç temel DMV (Dynamic Management View) kullanılır. DBCC SQLPERF('LOGSPACE') komutu, tüm veritabanlarının log dosya boyutunu ve kullanım yüzdesini hızlıca gösterir. Daha detaylı analiz için, sys.dm_db_log_info DMV'si, log dosyasındaki her bir Sanal Log Dosyası'nın (VLF) durumu, boyutu ve LSN aralıklarını sağlar. Çok fazla sayıda küçük VLF olması ("VLF parçalanması"), kurtarma ve yedekleme performansını düşürebilir.

Log alanını proaktif yönetmek için çeşitli stratejiler mevcuttur. İlk adım, uygun kurtarma modelini ve tutarlı bir yedekleme planını uygulamaktır. İkinci olarak, log dosyasının başlangıç boyutu, beklenen iş yüküne göre yeterince büyük ayarlanmalıdır. Bu, sık sık otomatik büyüme olaylarının önüne geçer. Otomatik büyüme yüzdesi yerine sabit bir megabayt değeri (örneğin, 1024 MB) ayarlamak, daha öngörülebilir bir büyüme ve daha az dosya parçalanması sağlar.

Zaten aşırı büyümüş bir log dosyasını küçültmek için DBCC SHRINKFILE komutu kullanılır. Ancak bu işlem, yalnızca log'un kesilebilir kısmındaki kullanılmayan alanı geri kazanır. Etkin VLF'leri etkilemez ve fiziksel dosya parçalanmasına yol açabileceğinden sık kullanımı önerilmez. Doğru yaklaşım, önce log'un neden büyüdüğünü (örneğin, log yedeği alarak) ele almak, ardından tek seferlik bir küçültme işlemi yapmaktır.

Büyük toplu işlemler (batch operations) planlanırken log büyümesi dikkate alınmalıdır. Mümkünse, bu işlemler daha küçük gruplar halinde (batch'lerde) gerçekleştirilmelidir. Ayrıca, işlem sırasında geçici olarak Toplu İşlenmiş Kurtarma Modeli'ne geçmek, log üretimini önemli ölçüde azaltabilir. Ancak, bu değişiklik yapılmadan önce mutlaka bir tam veritabanı yedeği alınmalı ve işlem tamamlandıktan sonra hemen Tam modele geri dönülmelidir.

Log dosyasının sağlıklı bir VLF yapısına sahip olması için bakım önemlidir. Çok fazla sayıda VLF (binlerce), kurtarma, yedekleme ve Always On gibi senaryolarda gecikmelere neden olabilir. İdeal olarak, VLF sayısı birkaç yüzü geçmemelidir. VLF sayısını ve boyutunu düzeltmek için, log dosyasını uygun bir başlangıç boyutuna manuel olarak yeniden yapılandırmak gerekebilir.

Sonuç olarak, etkin log büyümesi yönetimi, reaktif küçültme işlemlerinden ziyade proaktif planlamaya dayanır. Düzenli yedekleme, uygun model seçimi, doğru dosya boyutlandırma ve büyük işlemlerin kontrollü yürütülmesi, log dosyasının sağlıklı, performanslı ve yönetilebilir kalmasını sağlayan temel ilkelerdir.

4. Yüksek Kullanılabilirlik Senaryolarında Log Yönetimi

SQL Server'ın Always On Kullanılabilirlik Grupları (AG) ve Veritabanı Yansıtma (Database Mirroring) gibi yüksek kullanılabilirlik (HA) ve olağanüstü durum kurtarma (DR) çözümleri, transaction log yönetimini daha da kritik ve karmaşık hale getirir. Bu teknolojiler, verilerin ikincil sunuculara aktarılması için log kayıtlarına bağımlıdır, bu nedenle log performansı ve gecikmesi doğrudan RPO (Kurtarma Noktası Hedefi) ve RTO (Kurtarma Süresi Hedefi) üzerinde belirleyici bir etkiye sahiptir.

Always On Kullanılabilirlik Grupları'nda, birincil replikadaki log kayıtları, ikincil replikalara yakın gerçek zamanlı olarak taşınır, burada redo sırası (yeniden yapma) bekler veya uygulanır. Bu sürecin sağlıklı işleyişi, birincil sunucuda tutarlı log üretimine ve düşük ağ gecikmesine bağlıdır. Birincil replikadaki log yazıcısı, log kaydını yerel diske yazdıktan sonra, bu kaydı ikincil replikalara gönderir. Eğer log birincide çok hızlı büyür veya ikincile gönderimde bir gecikme yaşanırsa, gönderim kuyruğu (send queue) birikebilir.

Gönderim kuyruğunun büyümesi, genellikle ağ bant genişliği yetersizliğinden, ikincil sunucunun log disk performansının düşük olmasından veya ikincil sunucudaki redo iş parçacığının yetersiz kalmasından kaynaklanır. Bu gecikmeyi izlemek için, sys.dm_hadr_database_replica_states DMV'sindeki log_send_queue_size (KB cinsinden) ve log_send_rate sütunları kullanılır. Yüksek bir kuyruk boyutu, veri kaybı riskinin arttığı anlamına gelir.

Benzer şekilde, ikincil replikada yeniden yapma kuyruğu (redo queue) da izlenmelidir. Bu kuyruk, diske yazılmış anchenüz veri dosyalarına uygulanmamış log kayıtlarını temsil eder. Yüksek bir redo kuyruğu, bir failover (devralma) durumunda kurtarma süresini (RTO) uzatır. Redo performansı, ikincil sunucunun CPU ve disk alt sistemi performansıyla doğrudan ilişkilidir. Yeterli performans sağlamak için, birincil ve ikincil sunucuların kaynak kapasitelerinin benzer olması önerilir.

HA/DR mimarilerinde log yedekleme stratejisi de özel dikkat gerektirir. Genellikle, log yedekleri ikincil replikalardan alınabilir. Bu, birincil sunucu üzerindeki yükü azaltır ve yedekleme g/ç operasyonlarının birincil iş yükünü etkilemesini önler. Ancak, log zinciri (chain of LSNs) bu durumda da korunmalıdır. Yedekleme tercihleri, Kullanılabilirlik Grubu özellikleri yapılandırılarak belirlenir.

Sonuç olarak, yüksek kullanılabilirlik ortamlarında log yönetimi, yalnızca tek bir sunucunun disk alanını değil, aynı zamanda ağ sağlığını, çoğaltma gecikmelerini ve çoklu sunucuların performansını kapsayan bütünsel bir bakış açısı gerektirir. Log dosyasının sağlıklı yapısı, düzenli yedeklemeleri ve performansı, HA/DR çözümünün güvenilirliğini ve etkinliğini doğrudan belirleyen en önemli faktörlerden biridir.