Veritabanı yönetimiyle biraz bile uğraştıysanız o meşhur kabusu muhtemelen yaşamışsınızdır: Yana döne büyük bir işlem (transaction) çalıştırırsınız, işler yolunda gitmez ve iptal (rollback) etmek zorunda kalırsınız… Sonra ne mi olur? O işlem saatlerce geri alınmayı bekler! Kilitler (lock) kalkmaz, sistem kilitlenir, TempDB şişer ve telefonlar çalmaya başlar.
İşte SQL Server 2019 ile hayatımıza giren ve veritabanı yöneticilerinin (DBA) adeta imdadına yetişen ADR (Accelerated Database Recovery), tam olarak bu derdimize derman olan harika bir mimari yenilik.
Geleneksel SQL Server mimarisinde veritabanı recovery süreçleri, TempDB snapshot’ları veya DBCC CHECKDB gibi tutarlılık kontrolleri doğrudan TempDB veritabanının omuzlarına yüklenmişti.
Yıllardır uygulanan ARIES kuralı gereği; uzun süren bir işlem geri çekildiğinde ya da sunucu beklenmedik bir anda ansızın kapandığında, veritabanının tutarlı hale gelmesi ciddi zaman alıyordu. Bu süreçte kilitler uzun süre tutuluyor ve TempDB üzerinde inanılmaz bir I/O yükü oluşuyordu. Bir başka deyişle; TempDB tıkandığında, tüm sunucu nefessiz kalıyordu.
ADR ile birlikte Microsoft bu mantığı kökten değiştirdi. “Neden TempDB’yi bu kadar yoruyoruz?” diyerek bu ağır süreçleri TempDB’den alıp doğrudan Data File düzeyine taşıdı.
Artık sürüm denetimi ve snapshot işlemleri, ilgili veritabanının kendi veri dosyaları (.mdf / .ndf) üzerinde tutulan özel yapılar aracılığıyla yönetiliyor.
ADR’nin 3 Ana Bileşeni
ADR’nin bu mucizevi hızına ulaşmasını sağlayan arkadaki 3 ana kahramanı yakından tanıyalım:
- PVS (Persistent Version Store): Eskiden TempDB içinde tutulan değişiklik versiyonları (old versions), artık doğrudan veritabanının kendi veri dosyası içerisinde saklanıyor. Böylece TempDB bağımlılığı ortadan kalkıyor.
- sLOG (Secondary Log): Aktif olmayan veya geri alma gerektirmeyen işlemlerin log kayıtlarını çok hafif bir biçimde tutar. Bu sayede hem transaction log dosyasının şişmesini engeller hem de kurtarma (recovery) süresini minimuma indirir.
- Logical Reversion (Lojik Geri Çevirme): İşte sihrin gerçekleştiği yer! Bir işlemi geri alırken devasa log dosyasını baştan sona taramak yerine, PVS üzerindeki ilgili versiyona doğrudan bir işaretçi (pointer) yönlendirir. Sonuç mu? Saatlerce sürebilecek rollback işlemi saniyeler içinde tamamlanır!
ADR Öncesi ve Sonrası Karşılaştırması
Farkı daha net görebilmeniz için günlük operasyonlarımızdaki kritik noktaları bir araya getirdim:
| Özellik | ADR Öncesi (Geleneksel Yapı) | ADR Sonrası (Yeni Yapı) |
| Snapshot Depolama | Değiştirilen verilerin eski halleri TempDB üzerinde saklanır. | Değişiklik versiyonları veritabanının kendi Data File (PVS) yapısında saklanır. |
| DBCC CHECKDB | Tutarlılık kontrolü sırasında dahili bir veritabanı snapshot’ı oluşturur ve yoğun TempDB I/O yükü getirir. | PVS üzerinden verinin o anki tutarlı görünümünü okuyarak TempDB bağımlılığını azaltır. |
| Rollback Süresi | İşlemin sürdüğü süre kadar (bazen saatlerce!) rollback bekletir. | İşlem boyutundan bağımsız olarak saniyeler içinde tamamlanır. |
| Transaction Log | Uzun süren işlemler nedeniyle log dosyası kesilemez (truncate edilemez) ve sürekli şişer. | sLOG ve PVS sayesinde log boyutu her zaman kontrol altında tutulur. |
Dikkat Edilmesi Gereken Hususlar
Her güzel şeyin küçük bir bedeli olduğu gibi ADR kullanırken de dikkat etmemiz gereken iki önemli nokta var:
- PVS verileri veritabanının kendi veri dosyasında tutulduğu için veri dosyanızda ek alan kullanımına neden olabilir. Bu oran genelde %10-%15 civarındadır. Disk planlamanızı buna göre yapmalısınız.
- Veri dosyasında biriken eski versiyonların temizlenmesi için arka planda sürekli çalışan bir PVS Cleaner süreci bulunur. Özellikle çok yoğun DML (INSERT/UPDATE/DELETE) yükü olan sistemlerde PVS boyutunu ve bu temizleme sürecini yakından izlemekte fayda var.
İlgili veritabanında ADR özelliğini açmak için aşağıdaki ALTER DATABASE komutunu çalıştırmanız yeterlidir:
ALTER DATABASE [VeritabaniAdiniz]
SET ACCELERATED_DATABASE_RECOVERY = ON;Not: Özelliği açarken veritabanı kısa süreliğine özel bir kilit (exclusive lock) alabilir. Bu nedenle bu işlemi canlı ortamda (Production) gerçekleştirmeden önce iş yükünün düşük olduğu bir zaman diliminde yapmanız önerilir.
ADR özelliğinin veritabanınızda başarıyla aktif olup olmadığını kontrol etmek için sys.databases kataloğunu sorgulayabilirsiniz:
SELECT
name AS VeritabaniAdi,
is_accelerated_database_recovery_on AS ADR_Durumu
FROM sys.databases
WHERE name = 'VeritabaniAdiniz';
- Eğer dönen sonuçta ADR_Durumu değeri 1 ise ADR başarıyla açılmış demektir (0 ise kapalıdır).
Özetle; ADR, SQL Server dünyasında TempDB darboğazını çözen ve veritabanı kullanılabilirliğini (availability) tavan yaptıran en kritik mimari adımlardan biri. Eğer henüz aktifleştirmediyseniz, özellikle büyük veritabanlarınızda değerlendirmenizi kesinlikle öneririm!
Başka makalede görüşmek dileğiyle..
“Elbette işin sonu senin için öncesinden daha hayırlı olacaktır.“Duhâ-4
