SQL Server indeks bakımı: soldan sağa yükselen dört basamak — parçalanmış indeks çubukları ve uyarı, REORGANIZE senkron okları, REBUILD dişlisi ve yeşil ilerleme çubuğu, sağlıklı düzgün indeks çubukları ve yeşil onay; üstte fragmentasyon göstergesi

SQL Server İndeks Bakımı: Fragmentasyon ve Yeniden Oluşturma Rehberi

SQL Server indeks bakımı, fragmentasyonu ölçüp REORGANIZE veya REBUILD ile düzeltmektir. Ne zaman hangisi, güvenli plan ve kontrol listesi.

Kısaca: SQL Server indeks bakımı, tablolardaki indekslerin zamanla parçalanmasını (fragmentasyon) ölçüp yeniden düzenleme (REORGANIZE) veya yeniden oluşturma (REBUILD) ile düzeltmektir. Bakım yapılmayan indeksler okuma sürelerini uzatır, yedekleme ve bakım pencerelerini şişirir. KOBİ’lerde haftalık bir bakım planı, çoğu yavaş rapor ve uygulama şikayetini indekslere dokunmadan çözmenin en ucuz yoludur.

SQL Server’da her UPDATE, INSERT ve DELETE indeksi biraz daha dağıtır: sayfalar bölünür, mantıksal sıra ile fiziksel sıra ayrılır. Sonuçta aynı sorgunun okuduğu sayfa sayısı artar; disk ve bellek baskısı yükselir. Performans sorununu yalnızca yeni donanım veya sorgu yeniden yazımıyla çözmeye çalışmak, bakım yapılmayan indeksleri görmezden gelmektir.

Bu yazıda fragmentasyonun ne anlama geldiğini, REORGANIZE ile REBUILD arasındaki farkı, ne zaman hangisini seçeceğinizi ve güvenli bir bakım planını nasıl kuracağınızı adım adım anlatıyoruz.

SQL Server indeks bakımı neden gerekir?

İndeksler, sorguların doğru satırlara hızlı ulaşmasını sağlar. Yoğun yazma yükü altında indeks sayfaları parçalanır:

  • Dahili fragmentasyon: Sayfada boş alan kalır; aynı veri için daha fazla sayfa okunur.
  • Harici fragmentasyon: Mantıksal sıra bozulur; ardışık okumalar rastgele I/O’ya dönüşür.

Fragmentasyon yüzde olarak izlenir. Genel pratikte %10–30 aralığında yeniden düzenleme, %30 üzerinde yeniden oluşturma düşünülür; eşikler iş yüküne ve bakım penceresine göre ayarlanır. Microsoft’un resmi rehberi olan indeksleri yeniden düzenleme ve yeniden oluşturma sayfası, komut seçeneklerini ve dikkat edilmesi gerekenleri özetler.

REORGANIZE mi, REBUILD mi?

SQL Server indeks bakımı döngüsü: ortada SQL veritabanı; ölç (büyüteç + düzensiz çubuklar), karar ver (REORGANIZE / REBUILD çatalı), çalıştır (dişli + ilerleme), doğrula (onay + sağlıklı çubuklar) — saat yönünde oklar

1. Fragmentasyonu ölçün

sys.dm_db_index_physical_stats ile avg_fragmentation_in_percent ve page_count değerlerine bakın. Birkaç sayfalık küçük indekslerde yüksek yüzde yanıltıcı olabilir; bakım kararını sayfa sayısıyla birlikte verin.

2. REORGANIZE (yeniden düzenleme)

Online çalışır, kilitleri kısa tutar ve indeksi yerinde toparlar. Orta düzey fragmentasyon ve dar bakım pencereleri için uygundur. Yoğun yazma dönemlerinde bile çoğu KOBİ ortamında güvenle planlanabilir.

3. REBUILD (yeniden oluşturma)

İndeksi sıfırdan oluşturur; istatistikleri de yeniler. Enterprise sürümünde ONLINE seçeneği vardır; Standard’da işlem sırasında ilgili nesneler daha uzun kilitlenebilir. Yüksek fragmentasyon, büyük indeksler ve bakım penceresi olan geceler için tercih edilir.

4. Fill factor ve bakım penceresi

Fill factor, sayfada ilerideki güncellemelere yer bırakır. Çok düşük seçmek indeksi şişirir; çok yüksek seçmek fragmentasyonu hızlandırır. Bakım işlerini yedekleme ve yoğun rapor saatlerinin dışına koyun; aksi halde SQL kilitlenmeleri artabilir.

5. İstatistikler ve sorgu planları

REBUILD istatistikleri günceller; REORGANIZE etmez. Bakım sonrası kritik raporların plan cache’ini ve sürelerini kontrol edin. Genel performans için bakıma ek olarak SQL veritabanı performansını artırmanın 10 yolu yazımızdaki indeks ve sorgu kontrollerini de uygulayın.

Güvenli bir bakım planı nasıl kurulur?

Tek seferlik bir REBUILD yeterli değildir; tekrarlayan bir ritim gerekir:

  • Haftalık ölçüm: Fragmentasyon ve sayfa sayısı eşik üstü indeksleri listeleyin.
  • Kademeli işlem: Önce REORGANIZE, gerekirse REBUILD; tüm veritabanını körlemesine rebuild etmeyin.
  • Yedekleme ile hizalama: Büyük REBUILD öncesi güncel bir yedek olduğundan emin olun; SQL veritabanı yedekleme yazımız RPO/RTO çerçevesini anlatır.
  • İzleme: Bakım sonrası en yavaş 10 sorguyu ve disk gecikmesini kaydedin; iyileşme yoksa sorun indeks değil sorgu veya eksik indekstir.

Bakım job’larını SQL Server Agent ile zamanlayın; her çalıştırmanın çıktısını bir tabloya yazın. Böylece hangi indekslerin sürekli fragment olduğunu ve hangi REBUILD’lerin uzun sürdüğünü görürsünüz. Aynı izleme, gereksiz yere her gece tüm indeksleri rebuild eden şişkin planları da ortaya çıkarır.

Kontrol listesi: İndeks bakımına başlamadan önce

  • Hangi veritabanları ve indeksler bakım kapsamına alındı yazılı mı?
  • Fragmentasyon eşiği ve minimum sayfa sayısı tanımlandı mı?
  • Bakım penceresi yedekleme ve yoğun saatlerle çakışmıyor mu?
  • Standard / Enterprise sürümüne göre ONLINE REBUILD mümkün mü net mi?
  • Bakım sonrası kritik raporlar için bir doğrulama listesi var mı?

SQL Server indeks bakımı, pahalı donanım yatırımlarından önce gelen düzenli bir operasyon disiplinidir. Kapsamı ve riskleri SQL danışmanlık bakış açısıyla da değerlendirebilirsiniz.

ÇAP Teknoloji olarak KOBİ’lerin SQL Server ortamlarında indeks bakımı, performans ve yedekleme planlarını birlikte kuruyoruz. SQL danışmanlığı hizmetlerimizi inceleyebilir veya veritabanınızı değerlendirmek için bizimle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular

REORGANIZE ile REBUILD arasındaki fark nedir?

REORGANIZE indeksi online olarak yerinde toparlar ve istatistikleri güncellemez. REBUILD indeksi sıfırdan oluşturur, istatistikleri yeniler ve yüksek fragmentasyonda tercih edilir; Standard sürümde ONLINE seçenek sınırlı olabilir.

Fragmentasyon yüzde kaçta bakım yapılmalı?

Yaygın pratik %10–30 için REORGANIZE, %30 üzeri için REBUILD düşünmektir. Küçük indekslerde yüzde yanıltıcı olabilir; page_count ile birlikte karar verin ve eşiği iş yükünüze göre ayarlayın.

İndeks bakımı uygulamayı yavaşlatır mı?

Bakım penceresi yoğun saatlere denk gelirse kilitlenme ve I/O artabilir. REORGANIZE genelde daha hafiftir; büyük REBUILD işlerini geceye ve yedekleme dışına planlayın.

Bakım sonrası performans düzelmezse ne yapmalı?

Sorun fragmentasyon değil, eksik indeks, kötü sorgu veya istatistik kaynaklı olabilir. En yavaş sorguları, yürütme planlarını ve eksik indeks önerilerini inceleyin.