Bir Fulltext Index tecrübesi

Selam arkadaşlar,

Son birkaç gündür bayağı yoğunluk oldu. Özellikle sorumlu olduğum ortamlardan birinde yaptığımız bir arşivleme çalışması neticesinde Fulltext Index Population işlemiyle bayağı cebelleştim.

Öncelikle senaryodan bahsedeyim. Çalıştığım sunucu canlı, üretim sunucusu. Burada SQL Server'ın Standard Edition'ı kullanılıyor, yani Table Partitioning, arşivleme için geçerli bir seçenek değil.

Arşivlenen üretim veritabanının adına Galata diyelim, arşiv veritabanının adına da Galata_arsiv. Galata'daki bazı tablolardaki kayıtlar, tarih değerlerine göre Galata_arsiv'e taşınıyor. Tabii ki taşıma, önce ilgili kayıtların Galata_arsiv'deki hedef tabloya kopyalanması, sonra da kaynaktan silinmesi şeklinde yapılıyor. Efendim Galata veritabanındaki kaynak tabloda 2 alan için bir de Fulltext Index tanımlı. Silinecek kayıt sayısı 30 milyon civarında.

Silme işlemini yaptım ve bir sorun yok. Bir süre sonra Ghost Cleanup arkaplanda çalışmaya başladı, gene bir sıkıntı yok. O günlük arşivleme çalışması tamamlandı ve bilgisayarımı kapattım. Fakat birkaç saat sonra CPU uyarı mesajları ve akabinde operasyonda çalışan arkadaşlardan yavaşlık şikayetleri gelmeye başladı. Hemen bağlandım baktım, CPU kullanımı sürekli %95'in üstünde, IO çok yüksek. Felaket!

Önce hemen sorun Windows'taki başka bir uygulamada mı yoksa SQL Server'da mı onu kontrol ettim, sorun SQL Server Instance'ındaydı. Daha sonra çok silme işlemi yaptığım için Ghost Cleanup işleminden şüphelendim. Nedir bu Ghost Cleanup ondan da çok özetle bahsedeyim. SQL Server'daki bir tablodan kayıt sildiğinizde bu kayıtlar birkaç nedenden dolayı hemen silinmezler, silinecek olarak işaretlenirler. Öncelikle bu hem silme işleminin hızlı olmasını sağlar, hem de olur da işlemi iptal etmek ve veriyi geri getirmek isterseniz bu yolla çok daha hızlı olmuş olur. Daha sonra belli bazı şartlar oluştuğunda Ghost Cleanup devreye girer ve bu kayıtları yavaş yavaş siler. Efendim inceledim, baktım ve sorunun Ghost Cleanup olmadığına karar verdim.

Kullanıcı işlemlerinde bir gariplik var mı diye inceledim, özellikle göze çarpan bir işlem görmedim. Peki ne oluyordu bu SQL Server Instance'ına da birden bu kadar çok kaynak kullanmaya başlamıştı?

Biraz daha inceleyince gözüme özellikle bir sistem işlemi çarptı. Çok fazla CPU tüketiyordu. Lastwaittype'ına bakınca "FW CRAWL" ibaresini gördüm. O anda aklıma başımın Fulltext Index ile dertte olabileceği geldi. Hemen silme işlemi yaptığım tabloları kontrol ettim, evet, birinde Fulltext Index vardı ve Population işlemine başlamıştı bile. Yani yapılan milyonlarca kayıt silme işlemini kendi Index'ine yansıtıyordu. Fulltext Index uzmanı değilim, tam olarak ne yapıyor da ne oluyor henüz inceleme şansım olmadı ve şunu da belirtmeliyim ki Fulltext Index konusu başlı başına bir kitap konusudur ki sadece bu konuda yazılmış kitaplar vardır. Fakat başka bazı belirtilere göre de başımın Fulltext Index ile dertte olduğu artık kesindi.

Bu arada, sorunun Fulltext Index olduğundan emin olmadan önce, herhangi bir Bug veya gariplikle karşı karşıya olma ihtimaline karşın SQL Server Instance'ını birkaç kere yeniden başlatmıştım. Servis açılırken Galata_arsiv veritabanının uzun süre In-Recovery durumda kaldığını gördüm. Benim silme işlemlerim biteli çok olmuştu ve Transaction Log dosyasını boşaltmıştım, yani geri alınacak veya sürdürülecek herhangi bir log yoktu içinde. Bu Recovery de neyin nesi diye düşünüyordum. Fulltext Index durumu kafamda netleşince, Recovery'nin de bununla ilgili olduğunu anladım. Veritabanı Recovery durumuna düştüğüne göre ve Recovery'nin 3. fazında 15-20 dakika beklediğine göre bir şeyler (Fulltext Index ile ilgili) loglanıyordu.

Efendim ya henüz ben bulamadım ve bilemedim, ama maalesef bir Fulltext Index Population işleminin tam olarak hangi safhada olduğu, yani mesela yüzde kaçının tamamlandığı ve benzeri bir bilgiyi edinebileceğim herhangi bir sistem kataloğu veya DMV'si yok. Bilen varsa da lütfen paylaşsın, ben de buradan duyurayım. Sadece Fulltext Index'leri ve kataloglarını görüntüleyebiliyoruz, bir de Index'in güncel olmayan durumunu. "Index'in güncel olmayan durumu" derken neyi kastettiğimi de hemen belirteyim, [sys].[dm_fts_index_population] isimli DMV ile bir Fulltext Index'in o anki durumunu ([status_description]) görebiliyorsunuz, fakat benim senaryomda bu alanda "Starting" yazıyordu, halbuki bu işlem başlayalı 2 gün olmuştu zaten! Tabii insan kuşkulanıyor ve akla sorular düşüyor, işlem gerçekten devam ediyor mu, yoksa bir yerde bloke mi oldu, bloke olsa neden bu kadar kaynak tüketiyor, yoksa kaynak tüketen ve henüz tespit edemediğim başka bir işlem mi var? Bu noktada Fulltext Index'in kara kutu olduğunu düşünmeye başlamıştım, ki hala öyle görünüyor.

Bununla birlikte, şöyle sorular soruyor olabilirsiniz:
- Neden Population'ı durdurmadın?
- Neden Fulltext Index'i silmedin veya Disable duruma getirmedin?
- Neden Auto-tracking'i Manuel yapmadın ve daha uygun zamanda devam etmedin Population'a?

Çok güzel sorular ve tabii ki benim de ilk aklıma gelenler oldu. Fakat FW CRAWL işlemini yapan sistem işlemi buna izin vermedi. Yukarıdaki sorular için aksiyon almaya kalktığımda FW CRAWL sistem işleminin o aksiyonu bloke ettiğini gözlemledim. Ayrıca bloke olan sadece benim aksiyon almak için kullandığım işlem değil, arşiv veritabanına gelen diğer tüm kullanıcı işlemleri de o anda bloke oluyordu. Ben aksiyon almak için kullandığım ALTER FULLTEXT INDEX vb komutları çalıştırdığım işlemi sonlandırdığım anda blokasyon çözülüyor ve kullanıcılar işlemine devam edebiliyordu.

Yani öyle bir durum ki, Population'ı durduramıyorum, CPU ve IO kaynaklarım sonuna kadar kullanılıyor, kullanıcılardan sürekli yavaşlık şikayetleri geliyor.

Durum konusundaki bazı noktalar netleşince hemen alternatif bir aksiyon planı hazırladım. O aksiyon planını devreye almadan önce, sorunun şiddetini dindirebilecek önlemleri almak için ilgili birimler arasında küçük toplantılar tertip ettim, alınabilecek küçük, hızlı, anlık sorunları hafife indirgeyecek aksiyonlar aldık ve tüm bunlar konusunda ilgili yöneticileri zaman zaman bilgilendirdim. Eğer Population işlemi T zamanına kadar bitmeseydi, ilgili yöneticilerin onayıyla da alternatif planı devreye alacaktım. Fakat işlem dün akşam nihayet tamamlandı.

Bu yazıdan özellikle almanızı beklediğim şey, bir kriz anında panik yapmadan yapılacak şeyleri düşünmeniz, ilgili yöneticileri her daim bilgilendirmeniz, özellikle de kritik bir aksiyon almadan önce. Yeri geldiğinde tabii ki inisiyatif alın, fakat unutmayın ki siz resmin sadece bir bölümünü görebilirsiniz, ilgili yöneticileriniz resmin daha büyük kısmına hakim, o nedenle kritik bir aksiyon öncesinde muhakkak ilgili birimlerle ve yöneticilerle eşgüdümlü çalışın. Biliyorum kolay değil, ama panik yapmayın. Veritabanı yönetimi, tüm şirketi etkileyen, hatta bir şirketin en hayati kademelerinden biridir. Çok ciddi bir iştir ve büyük sorumluluk ister. Her zaman bunun bilincinde olmalısınız.

Sevgiler,
Ekrem Önsoy