Defrag Heap Table

Veri tabanı tasarımı ve geliştirilmesi konusunda en temel işlevlerden biri olan tablo tasarımı ve oluşturma sürecinde, karşılaşılan sorunlardan biri HEAP formundaki (yapısındaki) tablolardır. Sıradan bir tablo oluşturulduğunda, eğer açıkça clustered index tanımı yapılmadıysa, oluşturulan tablonun yapısı HEAP formunda (yapısında) olacaktır.

Aşağıda basit bir tablo oluşturma scripti ve nonclustered index tanımı yer almaktadır:

Yukarıdaki scripti çalıştırdıktan sonra tablo üzerinde yer alan indexlere göz atalım:

Veri tabanı tasarım, geliştirme ve test süreçleri bittikten,  production (canlı kullanım) ortamına geçildikten sonra, oluşturduğunuz tablo(lar) verilerle dolmaya başladığında, karşılaşacağınız ilk sorunlardan biri performans olabilir. Nedenini araştırdığınızda tabloda bulunan fragmentation (parçalanma) olduğunu gözlemleyebilirsiniz.

Oluşturduğumuz tabloya, örnek olması amacıyla veriler eklendikten sonraki index fragmentation oranları aşağıdaki gibidir:

Clustered ve HEAP formu arasındaki fark, tablonun fiziksel olarak sıralanması ile doğrudan ilişkilidir. Clustered formundaki bir tablo, belirlenen alan(lar)a göre sıralamaya tabii tutulurken, HEAP formundaki tabloda herhangi bir sıralama söz konusu değildir. Yani her yeni eklenen veri, en sona eklenerek devam edecektir, herhangi bir sıralama söz konusu değildir.
Yanlış olarak bilinen çözümlerden birisi, HEAP tabloyu clustered forma dönüştürüp fragmentationu düşürmektir. Clustered forma geçtikten sonra fragmentation düştüğü gözlemlenebilir fakat clustered indexe bağlı olan tüm non-clustered indexlerin tamamı rebuild işlemine tabii tutulacaktır. Bunun nedeni ise, non-clustered indexlerin üzerinde bulunan key fieldların (alan) olası bir istek doğrultusunda tabloya erişmek istediğinde, ilgili satıra erişebilmek için HEAP formundaki tablolar için row locator id (RID) değerini tutması, Clustered formundaki tablolar için ise Clustered key fiedlarını tutmasıdır. Tablo, HEAP’ten Clustered forma geçtiğinde artık RID yerine clustered index’te tanımlı keylerin non-clustered indexlerde tanımlanabilmesi için rebuild işlemine tabi tutulur.

Clustered index tanımlanmadan önce, non-clustered indeximizin fiziksel yapısı aşağıdaki gibi olacaktır:


Clustered forma geçtikten sonra, parçalanma oranları:

 

Clustered index tanımlandıktan sonra, non-clustered indexlerimizde yer alan HEAP RID yerine clustered indexte bulunan keylerin yerleştiğini görebiliyoruz:

Eğer production ortamındaysanız ve yoğun transaction alan bir tablo üzerinde çalışıyorsanız, bu ciddi transaction log ve lock üretimine, ayrıca eğer AlwaysOn, Mirroring, Log Shipping gibi HADR çözümleri kullanılıyorsa network taraflı darboğazlara sebep olabilir.

Çözümün devamında uygulanan diğer adım, HEAP’ten Clustered’a dönüştürülen tablonın eski haline dönüştürülmesi için clustered index’in kaldırılmasıdır. Bu operasyon yine, tablo’da bulunan tüm non-clustered indexlerin rebuild olmasına neden olacaktır.
Bunu engellemenin yolu ise, tablo tasarımı esnasında uygun clustered index tanımı yapılarak, bu tür sorunların önüne geçmektir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir