Tablo ve Index Rebuild İşlemlerinde En Uygun Çözümü Bulmak
OLTP sistemlerde tablo ve indexler insert,update,delete sonrasında fragmente olmaktadır. Fill factor kullanmak fragmentasyonu önlemeye yetmiyor. Tablo ve indexleri rebuild veya reorganize etmek mecburiyetinde kalıyoruz.
Rebuild işlemi esnasında tablolar en güçlü lock tipi ile kilitlenir. Dolayısıyla tablo üzerinde diğer kullanıcılar işlem yapamaz. Yüksek erişebilirlik gerektiren çok kritik sistemlerde bu durum kabul edilemez. Maintenance esnasında tablonun erişebilirliği sağlamak için işlemleri online parametresini set ederek gerçekleştiririz. Her şeyin bir iyi tarafı olduğu gibi kötü tarafı da var. Online rebuild işlemlerinde veritabanların log dosyalarını daha çok kullanılmaktadır. Ayrıca işlem süresini uzatır. Storage ünitesinde log dosyası için yeterli alan varsa ve sistemde kesintiye sebep olmadığından dolayı yoğun kullanımın olmadığı saatlerde işlemin uzun sürmesi problem oluşturmuyor gibi görünebilir. Gerçekten öyle mi?
Yükselk erişebilir, kritik uygulamalardan bahsediyorsak durum hiç te öyle değil. Çünkü bu tür sistemler, Yüksek Erişebilirlik için örneğin mirroring, Olağanüstü durumlar için log shipping ve hatta veri ambarı için de Change Data Capture(CDC) çözümlerini içerirler. Tüm bu çözümler SQL log’u kullanmaktadır. Dolayısıyla hedef veritabanlarının recover süreleri uzayacaktır. Yani kullanılır hala gelebilmeleri için daha fazla beklemek zorunda kalırız. Kaynak ve hedef veritabanlarının senkron olma süreleri artacak, daha büyük bir network trafiliği oluşturacaktır. Yerel networklerde trafik bir nebze kabul edilebilse bile Olağan Üstü Durum merkezi gibi geniş network ağı gerekli durumlarda network trafiğini konusunda çok daha dikkatli olmak durumundayız.
Tüm bu durumları düşündüğümüzde tablo veya indexlerin bütününü de değilde, parça parça rebuild edilmesi gerektiği ortaya çıkıyor. Yani partition rebuild.
ALTER TABLE PartitionTable1 REBUILD PARTITION = 1
Özellikle tarih bazlı partition yapılmış tablo veya indexlerde insert,update,delete işlemleri son partitionda olacağından dolayı diğer partitiondaki veriler fragmente olmazlar. Dolayısıyla son partition’ın rebuild edilmesi yeterli olacaktır
ALTER INDEX IX_TransactionHistory_TransactionDate ON Production.TransactionHistory
REBUILD Partition = 5;
Artık log dosyasında daha az kayıt var, işlem zamanı kısaldı, recovery süresi uzun olmayacak. Problemlerimiz bitti mi? Malesef hayır. Yazının başında bahsettiğimiz gibi işlemlerimizi yaparken online parametresini set etmeliyiz ki diğer kullanıcıların erişimini engellemeyelim. Ne yazık ki Alter Table ve Alter index online rebuild edilebilse de, partition söz konusu olduğunda online desteklenmiyor.
ALTER INDEX IX_TransactionHistory_TransactionDate ON Production.TransactionHistory
REBUILD Partition = 5 WITH(Online=ON);
Msg 155, Level 15, State 1, Line 2
'Online' is not a recognized ALTER TABLE REBUILD PARTITION option.
SQL Denali ile bu özelliğin geleceğini bekliyordum fakat gelmiyor. Dayanamayıp SQL developer team’e yazdım.
https://connect.microsoft.com/SQLServer/feedback/details/679482/rebuild-partition-online-denali
Bir başka baharda olacağını öğrendik, yine de vote edip ihtiyacın boyutunu göstermek faydalı olabilir.
O bahar gelene kadar biz yine kayıt sayısı fazla olan, maintenance yükünü artıran tablolarımızı daha sık peryotlarla arsivlemek zorunda kalacağız. Partitionlar online rebuild bile olmasa bile , arsivleme yaparken çok işimize yarıyor. Partition switch işlemi delete işleminin oluşturacağı logu oluşturmuyor ve fragmentasyona yol açmıyor. Belki bir ara arsivlemeden daha detaylı bahsederiz.