Index ‘lerin Bulundukları FileGroup ları Değiştirme Süreçleri

Reading Time: 3 minutes

Index ‘lerin Bulundukları FileGroup ları Değiştirme Süreçleri

Index ‘lerin oluşturuldukları FileGroup ‘ları iki farklı yöntem ile değiştirebiliyoru. Bunlardan ilki DROP_Existing ifadesi ile diğeri ise klasik DROP-CREATE işlemi ile.

DROP-CREATE yönteminde bildiğiniz üzere ilk önce var olan Index ‘imizi DROP edip daha sonra Create ediyoruz.

 

DROP_EXISTING ifadesi ile de ;

 

Peki biz bu durumda hangisi ile işlem yapmamız gerek ?
Aslında Cluster ve NonClustered ındex olarak süreci iki ayrı başlık altında yorumlamak gerekir ise ;

Clustered ındex te yaşanan süreç,

Clustered Index ‘i DROP-CREATE ile FileGroup değişikliği yaptığımızda tüm NonClustered ındex ‘ler 2 defa REBUILD oluyor. İlk DROP işleminde tüm NonClustered ındex lerin Leaf Level Page ‘lerinde ki Clustered Index Key ‘lerini kaldırıp Heap Row Pointer bilgilerinin konulması, Index tekrar Create edildiğinde de yani Clustered Index ‘in KEY bilgilerininde tekrar tüm NonClustered Index lerin Leaf Level ‘larına yerleştirilmesi süreci.

NonClustered Index te yaşanan süreç,
DROP-CREATE metodu ile tekrar oluşturulması daha fazla IO yapılmasına ve daha uzun sürede gerçekleşmesine sebebiyet verir. En büyük sebebi ise , DROP-CREATE metodunda Index tekrar Create edilirken Index Page leri tüm tablolar okunurak oluşturuluyor. DROP_EXISTING de ise hali hazırda olan Page leri kullanıp sadece Index’in Filegroup ‘unu değiştriyor ve tüm tablo okunmadığı için bize daha performanslı sonuç sağlıyor.
ÖNEMLİ : INDEX Filegroup değişimlerinde DROP_EXISTING komutunu kullanarak operasyonlarınızı yaparsanız daha performanslı ve daha hızlı süreçlerinizi gerçekleştirmiş olursunuz.

 

Örneğimizde konuyu daha detaylı İnceleyelim ,

Örnek 1: Clustered Index ‘i başka bir Filegroup a taşıyacağız.

Test veritabanımızı oluşturuyoruz.

Test veritabanımızın içerisine demo tablomuzu oluşturuyoruz.

Daha sonra tablo üzerine Primary FileGroup içerisine Index ‘imizi oluşturuyoruz.

Index ‘imizin detayını help_index komutu ile kontrol edelim.

Yukarıda da görüldüğü üzere Index 2imiz PRIMARY Filegroup un içerisinde yer almaktadır.

SSMS üzerinden kontrol etmek istediğimizde ise ,

Veritabanımız altında tablo Tables içerisinde oluşturduğumuz tablonun altına girip orada ki Indexes sekmesi altında oluşturduğumuz Clustered Index i görüyoruz. Index in üzerine gelip sağ tıkladıktan sonra Proparties seçeneğine tıklıyoruz.

Aşağıda ki ekran karşımıza gelmekte ve sol tarafta ki Storage sekmesine basarak Filegroup bilgisini bu ekranda da görebilir hatta değiştirebiliriz fakat GUI üzerinden bu tarz riskli işleri yapmanızı hiçbir zaman önermem.

DROP_EXISTING metodu ile Index ‘imizin Filegroup unu değiştirelim ,

sp_helpindex ile kontrol edelim hızlı bir şekilde ,

Gördüğünüz üzere index_description alanında artık INDEX filegroup una taşınmıştır.

Şimdi ise hem Primary Key olan hem de Clsutered Index olan kolondan Clustered Index ‘in Filegroup unu nasıl değiştiririz onu göreceğiz ;

Test tablomuzu oluşturuyoruz

Personel_2 adında oluşturduğumuz test tablomuzun Index yapısına help_index ile kontrol ediyoruz.

Index_description alanını gördüğünüzde Id kolonunun hem Primary key hemde unique clustered index olduğunu öğrendik.

Index ‘imizi başka bir filegroup taşıdığımızda aynı şekilde PK nında orada yer aldığını görmketeyiz.

 

NOT : Örneğimizin amacı DROP_EXISTING yöntemi ile Index lerimizi başka FileGroup ‘lara nasıl taşınacağını göstermek.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *