SQL Server Automatic Index Compaction: İndeks Bakımının Sonu mu?

SQL Server’da indeks bakımı yıllardır hep aynı senaryoyu izliyor: zamanlanmış rebuild/reorganize job’ları, gitgide daralan bakım pencereleri, şişen transaction log’lar ve performans ile kesinti süresi arasında sürekli kurulan denge. SQL Server Automatic Index Compaction bu tabloyu değiştiriyor. Azure SQL Database, Azure SQL Managed Instance ve Microsoft Fabric’teki SQL veritabanı için önizleme aşamasında sunulan bu yeni özellik, bu operasyonel yükün büyük kısmını arka planda sürekli çalışarak ortadan kaldırmayı hedefliyor.

Bu yazıda özelliğin nasıl çalıştığını, nasıl açılıp izlendiğini ve klasik indeks bakımından farkını ele alıyoruz. Ekibiniz SQL Server ortamlarını yönetiyor ve bu özelliği test etmeyi değerlendiriyorsanız, Aryasoft’un SQL Server danışmanlık hizmetleri kendi workload’unuza göre değerlendirme yapmanıza yardımcı olabilir.

Klasik İndeks Bakımının Sorunu

Zamanlanmış rebuild/reorganize job’larının gerçek operasyonel maliyetleri var: rebuild işlemleri ciddi CPU ve I/O tüketiyor, bakım pencereleri gitgide daralırken job’lar daha uzun sürüyor, transaction log’u şişirerek backup ve replikasyonu zorluyor, offline rebuild tabloyu tamamen kilitliyor, online rebuild ise en azından başlangıç ve bitişte kısa süreli exclusive kilit gerektiriyor.

Ayrıca daha temel bir sorun var: bu job’lar yıllardır aslında yanlış metriği hedefliyor. SQL Server’da indeks sağlığı genelde iki farklı fragmentation türü üzerinden değerlendirilir:

• Internal fragmentation (iç parçalanma) – her sayfanın ne kadar dolu olduğu, avg_page_space_used_in_percent ile ölçülür. Düşük sayfa doluluğu, aynı veriyi saklamak için daha fazla sayfa gerektirir; bu da memory, I/O ve CPU maliyetini artırır.
• External fragmentation (dış parçalanma) – sayfaların disk üzerindeki fiziksel sırası, avg_fragmentation_in_percent ile ölçülür. Bu metrik, sıralı olmayan okumaların pahalı olduğu mekanik disklerde çok önemliydi.

Bununla birlikte, SSD, NVMe ve bulut depolamada sıralı olmayan okumanın maliyeti artık marjinal seviyede, ama düşük sayfa doluluğunun maliyeti hâlâ geçerli. Automatic Index Compaction, tam olarak internal fragmentation’ı sürekli biçimde düzeltmek için tasarlanmış; external fragmentation’a ise hiç dokunmuyor.

SQL Server Automatic Index Compaction Nasıl Çalışıyor?

Özellik, bu platformlarda zaten çalışan Accelerated Database Recovery (ADR) altyapısının bir parçası olan Persistent Version Store (PVS) cleaner sürecine entegre edilmiş. Kısaca:

• Son zamanda insert, update veya delete ile değişen sayfaları izler.
• Sonraki sayfalardaki satırları, boş alanı olan mevcut sayfalara taşır.
• Fill factor için ayrılan alanı korur, o alana dokunmaz.
• Satırlar taşındıktan sonra boşalan sayfaları serbest bırakır (deallocate eder).

Sadece IN_ROW_DATA allocation unit’lerindeki leaf-level sayfalar kapsamda: clustered index, nonclustered index ve XML/full-text/spatial gibi özel tiplerdeki B-tree indeksler. Ancak heap tablolar, ROW_OVERFLOW_DATA, LOB_DATA, sıkıştırılmış columnstore rowgroup’lar, memory-optimized tablolar ve page lock’u devre dışı bırakılmış indeksler kapsam dışı.

İşlem; sayfada aktif bir transaction varsa, index rebuild/reorganize veya shrink devam ediyorsa, PVS boyutu 150 GB’ı geçmişse ya da aborted transaction sayısı 1000’i aşmışsa ilgili sayfayı atlıyor. Bu nedenle workload’unuzla kaynak rekabetine girmeden arka planda sürekli çalışabiliyor.

Nasıl Açılır, Nasıl Kontrol Edilir?

Pratikte, SQL Server Automatic Index Compaction veritabanı bazında açılıp kapatılıyor; restart veya exclusive erişim gerekmiyor:

-- Açmak için
ALTER DATABASE [veritabani-adi] SET AUTOMATIC_INDEX_COMPACTION = ON;

-- Kapatmak için
ALTER DATABASE [veritabani-adi] SET AUTOMATIC_INDEX_COMPACTION = OFF;

-- Durumu kontrol etmek için
SELECT database_id, name, is_automatic_index_compaction_on
FROM sys.databases;

-- ya da tek bir veritabanı için
SELECT DATABASEPROPERTYEX('veritabani-adi', 'IsAutomaticIndexCompactionOn');

Açtıktan sonra birkaç dakika içinde etkili oluyor.

Microsoft’un Kendi Demo Sonuçları

Microsoft, Automatic Index Compaction için resmi ve tekrarlanabilir bir demo yayınlıyor: bobsql GitHub deposu, Azure SQL Hyperscale veritabanı üzerinde çalıştırılıyor. Örneğin kurulum şöyle: 1.000.000 satır içeren, %99,8 sayfa doluluğuna sahip bir clustered index. Ardından satırların yarısı dağınık biçimde (scatter-delete) silinerek doluluk %47,1’e düşüyor; sayfa sayısı neredeyse değişmiyor — yani full scan artık verinin gerçekte ihtiyaç duyduğundan çok daha fazla sayfa okuyor. Sonrasında Automatic Index Compaction açılıp arka planda çalışmaya bırakılıyor.

Sonuç olarak, Automatic Index Compaction 18.004 yarı-boş sayfayı rebuild yapmadan 8.909 sıkı paketlenmiş sayfaya indiriyor: logical reads yaklaşık yarı yarıya düşüyor, cold-cache scan süresi %43 azalıyor — hepsi arka planda, hiçbir bakım penceresi olmadan.

Bilinmesi gereken bir detay: büyük bir silme işleminden hemen sonra, compaction devreye girmeden önce sayfa sayısı kısa süreliğine artabilir. Çünkü Accelerated Database Recovery kullanan platformlarda, silinen her satır temizlenene kadar ghost record için küçük bir versiyon işaretçisi tutar; zaten neredeyse dolu olan sayfalarda bu ek yük page split’e yol açabilir — ki bu tam olarak Automatic Index Compaction’ın sürekli temizlemek için tasarlandığı türde bir şişme.

Nerede Kullanılabilir, Nerede Kullanılamaz?

Kullanılabilir: Azure SQL Database, Azure SQL Managed Instance (Always-up-to-date politikası ile) ve Microsoft Fabric’teki SQL veritabanı.

Ancak kullanılamaz: şu an için SQL Server 2025 on-premises kurulumlarında yok. Sistem tabloları ve sistem veritabanlarında da çalışmıyor (msdb hariç).

Bilinmesi Gereken Sınırlamalar

• Fakat rebuild’in aksine istatistikleri (statistics) güncellemiyor.
• Logical/external fragmentation’ı azaltmıyor, hatta hafifçe artırabiliyor — ama bu burada önemli bir sorun değil.
• Fill factor’ün ayırdığı boş alanı geri kazandırmıyor.
• Data dosyalarını shrink etmiyor; dosya içinde kullanılan alanı azaltıyor, ayrılan dosya boyutunu değil.
• Write-yoğun workload’larda transaction log I/O’sunu artırabiliyor, page split nedeniyle fragmentation’ı bir miktar yükseltebiliyor.
• CPU kullanımına etkisi düşük, tek haneli yüzdeler seviyesinde.

Automatic Index Compaction’ı İzleme

Bunun için indekslerinizdeki sayfa doluluğunu ve fragmentation’ı izlemek üzere:

SELECT COALESCE(OBJECT_SCHEMA_NAME(ips.object_id), '<Total>') AS schema_name,
       COALESCE(OBJECT_NAME(ips.object_id), '<Total>') AS object_name,
       COALESCE(i.name, '<Total>') AS index_name,
       AVG(ips.avg_page_space_used_in_percent) AS avg_page_space_used_in_percent,
       AVG(ips.avg_fragmentation_in_percent) AS avg_fragmentation_in_percent,
       SUM(ips.page_count) AS page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), DEFAULT, DEFAULT, DEFAULT, 'SAMPLED') AS ips
INNER JOIN sys.indexes AS i
    ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE i.type_desc IN ('CLUSTERED', 'NONCLUSTERED', 'XML', 'SPATIAL')
  AND ips.index_level = 0
  AND ips.alloc_unit_type_desc = 'IN_ROW_DATA'
GROUP BY ROLLUP(ips.object_id, i.name, ips.partition_number);

Compaction’a özel sayaçlar için sys.dm_db_index_operational_stats üzerinden compaction_attempt_count, compaction_complete_count, compaction_skip_count, compaction_row_move_count ve compaction_page_deallocation_count kolonlarını sorgulayabilirsiniz. Ayrıca auto_index_compaction_stats extended event’i her 10 dakikada bir tetiklenerek taşınan satır ve deallocate edilen sayfa sayısını raporluyor; hafif bir izleme dashboard’u kurmak için bu event kullanılabilir.

SQL Server Automatic Index Compaction İndeks Bakım Job’larının Yerini Alıyor mu?

Tam olarak değil. İstatistik güncellemesi ve logical fragmentation düzeltmesi hâlâ zamanlanmış bir işlem gerektiriyor; dolayısıyla SQL Server Automatic Index Compaction, rebuild/reorganize job’larının tam bir yerine geçmiyor. Ortadan kaldırdığı şey, sürekli değişen bir veri kümesinde sayfa doluluğunu sağlıklı tutmak için harcanan, tekrar eden ve düşük katma değerli iş — daha önce bir bakım penceresi ve manuel zamanlama gerektiren iş.

Örneğin pratik bir strateji şu: mevcut düşük yoğunluklu indeksler için bir kerelik reorganize veya rebuild yaparak sağlıklı bir başlangıç noktasına getirin, sonrasında sürekli bakımı Automatic Index Compaction’a bırakın. Mevcut bakım pencerenizin yetersiz kaldığı ya da SQL Server modernizasyonunun zaten gündeminizde olduğu ortamlar için bu özelliği erkenden test etmek mantıklı. Bu konunun daha geniş upgrade/migrasyon planlaması içindeki yerini görmek için SQL Server modernizasyonu rehberimize göz atabilirsiniz.

Bu nedenle, özellik hâlâ önizleme aşamasında olduğu için production’a almadan önce kendi workload’unuza karşı test ortamınızda doğrulamanızı öneririz.

Microsoft kaynaklarından daha fazlası:
Automatic Index Compaction – Microsoft Learn
Automatic Index Compaction demo script’leri – Microsoft GitHub (bobsql)
The End of Index Maintenance? – Data Exposed (YouTube)