Bir müşterimde bir süredir büyük bir tabloda yaşanan dahili kayıt tekilleştirici mekanizmasının yarattığı kesinti sorununun giderilmesi konusunda çalışıyorduk. Nihayet sorunu giderdik. Bu yazımda sorunun tanımından ve çözmek için neler yapılabileceğinden özetle bahsedeceğim.
Yazının başında belirtmem gerekir ki bu yazı Microsoft SQL Server konusunda bazı ileri seviye terim ve kavramları bilmenizi gerektiriyor. Bu yazıda her kavramı tek tek açıklamayı hedeflemiyorum.
"Dahili kayıt tekilleştirici" nedir önce ondan bahsedeyim. Muhtemelen oldukça küçük bir azınlığın haberdar olduğu bir terim olduğu için ilk bakışta ilginç görünse de Türkçe olarak tanımlamak istedim ki biraz daha anlaşılabilir olsun. Efendim bahsettiğim kavram Microsoft SQL Server ürünündeki Clustered tablolardaki tekrar eden kayıtların tekilleştirilmesi için kullanılan Uniquifier kavramı. Öncelikle bu kavram tam olarak nerede, nasıl ve neden kullanılıyor ondan bahsedeyim.
Bir tabloyu Clustered yaptığınızda, yani bir tabloda bir Clustered indeks oluşturduğunuzda, o tablodaki tüm kayıtların eşsiz olması gerekiyor. Bu eşsizliği, oluşturacağınız Clustered indeksi Unique Clustered indeks olarak oluşturarak sağlayabilirsiniz; aksi takdirde, yani indeksinizi Unique Clustered indeks olarak değil de sadece Clustered olarak oluşturursanız SQL Server indeksinize Uniquifier adında dahili bir alan ekleyecektir. Normal şartlar altında, SELECT sorgularınızda veya [sp_helpindex] ile ve benzeri diğer yöntemlerle bu alanı görmezsiniz. Bu alanın varlığını ve etkilerini görebilmek için özel bazı yöntemler kullanmak gerekiyor. Heap tablolarda, yani bir Clustered indeks tanımlanmamış bir tablodaki kayıtların bir Unique indeks ile veya Uniquifier ile eşsizleştirilmesine ihtiyaç yoktur.
Uniquifier isimli alanın veritipi INT'tir, tutabileceği azami değer 2.147.483.647'dir ve diskte 4 baytlık yer kaplar. Cluster Key kendini tekrar etmedikçe Uniquifier'ın değeri artmaz, 0 olarak kalır ve diskte de yer kaplamaz. Cluster Key, Clustered indeksi oluşturan alandır. Clustered indeksi oluşturan alan sayısı birden fazla da olabilir, birden fazla alandan oluşan indekslere de Composite indeks denir.
Biraz da örnek ve görsellerle anlatayım, bu kavramlara çok yabancı olan arkadaşlar için daha anlaşılabilir olsun.
Not: Öncelikle şunu belirtmek gerekiyor ki DBCC PAGE komutu Microsoft tarafından resmen desteklenen ve dokümante edilmiş bir komut değildir. Bu ve diğer komutları canlı/üretim sunucularınızda çalıştırmamanızı öneririm.
Bu örnekte önce [uniq_test] adında bir tablo oluşturuyorum ve bu tablodaki [id] alanı için de bir Clustered indeks oluşturuyorum. Sonra aynı kayıttan 2 tane oluşturuyorum. DBCC IND komutuyla [test] veritabanındaki [uniq_test] tablosunun Page'lerini tespit ediyorum. DBCC PAGE komutuyla da yine [test] veritabanındaki birinci veri dosyasındaki 36296 numaralı Page'in içeriğine bakıyorum.
CREATE TABLE [uniq_test](id INT, isim NVARCHAR(50), soyisim NVARCHAR(50));
GO
CREATE CLUSTERED INDEX [CIX] ON [uniq_test]([id]);
GO
INSERT INTO [uniq_test] VALUES(1, 'Ekrem', 'Önsoy');
GO 2
DBCC IND([test], [uniq_test], 1);
GO
DBCC PAGE(test, 1, 36296, 3) WITH TABLERESULTS;
 |
| DBCC PAGE'in sonucu |
Not: Burada [isim] ve [soyisim] alanlarının aynı olması değil, [id] alanının aynı olması Uniquifier'ın kullanılmasını sağlıyor. [isim] ve [soyisim] alanları farklı da olsa yine de Uniquifier değeri artacaktı.
Not: DBCC IND komutu sizde muhtemelen farklı bir Page numarası döndürecektir, bunda hiçbir gariplik veya sakınca yok. Eğer örneği siz de kendi test ortamınızda uygulamak istiyorsanız DBCC PAGE komutuyla sizde dönen Page numarasını kullanın.
DBCC PAGE ile ilgili Page'in içerisine baktığımda yukarıdaki ekran görüntüsünde paylaştığım gibi bir sonuç görüyorum. Önceden de belirttiğim gibi eğer Clustered indeksimi oluştururken Unique Clustered indeks olarak oluştursaydım veya hiç Clustered indeks oluşturmasaydım ve yine bu Page'in içine baksaydım o zaman UNIQUIFIER diye bir alanı hiç görmeyecektim.
Yukarıdaki ekran görüntüsünde oluşturduğum 2 kayda ait değerleri her kayıt için ayrı ayrı renklerle ve dikdörtgen ile işaretledim. Önce lütfen daha uzun olan kırmızı ve mavi dikdörtgenlere bakın. Bu değerlere dikkatlice baktığınızda UNIQUIFIER'ın normalde 4 bayt uzunluğunda oduğunu, diskte ne kadar yer kapladığını ve o anki değerini göreceksiniz. (physical) 0 olduğunda diskte yer kaplamıyor demektir, yani aynı değer birden fazla tekrar etmemiş demektir. Bu nedenle uzun kırmızı dikdörtgende (physical)'ın yanında 0 varken, uzun mavi dikdörtgen ile işaretlediğim 2. kayda ait değer 4. Kırmızı ile işaretlediğim ilk kayda ait UNIQUIFIER'ın değil de mavi ile işaretlediğim ikinci kayda ait UNIQUIFIER'ın diskte 4 bayt yer kapladığını da küçük dikdörtgenlerle çevrelediğim Record Size değerlerinden anlayabilirsiniz. İlk kaydın boyutu 39 bayt iken, ikinci kaydın boyutu 4 baytlık UNIQUIFIER değer nedeniyle 43 bayt.
Eğer aynı kaydı 3. kere ekleseydim UNIQUIFIER'ın değeri 2 olacaktı ve INT veritipindeki bir alanın alabileceği azami değer olan 2.147.483.647'ye kadar gidecekti. Şayet aynı Cluster Key değeriyle bir kayıt bu kadar tekrar ederse, bir sonraki kaydı oluşturamazsınız ve aşağıdaki hatayı alırsınız:
"The maximum system-generated unique value for a duplicate group was exceeded for index with partition ID XXX. Dropping and re-creating the index may resolve this; otherwise, use another clustering key."
Emin olun, böyle bir durumla karşılaşmak istemezsiniz. Çünkü bu durumla karşılaştığınızda bu demektir ki tablonuzda en az 2 küsur milyar kayıt var ve muhtemelen önemli bir tablonuzdur ki bu kadar besleniyordur.
Bu sorun, hatalı tablo tasarımından kaynaklanır. Kayıtları blok blok silmeniz bir şey ifade etmez, çünkü UNIQUIFIER değeri böyle sıfırlanmaz. UNIQUIFIER değerinin sıfırlanması için tekrar eden kaydın tamamının silinmesi veya blokları sildikten sonra tabloyu hata mesajında da belirtildiği gibi komple yeniden oluşturmanız gerekir. Bu da size ancak bir sonraki hataya kadar zaman kazandırır.
Firmalar iş hayatlarına başlarken genelde düşük bütçeyle başlar, bu nedenle her konuda uzmanı bünyelerinde barındıramazlar ve böyle tasarımlar da genelde bu gibi nedenlerden kaynaklanır. Çünkü eğer firmanın bünyesinde donanımlı bir veritabanı yöneticisi varsa ve tasarım sırasında kendisine tablo tasarımı danışılsa, o böyle bir tasarımın yaratacağı olası sonuçları önceden öngörebilir.
Bu sorunu düzeltmek için tablonuzu Heap'e çevirebilir veya Clustered indeksinizi değiştirebilirsiniz. Tabii ki bunlar çok ciddi süreçler, çok iyi hazırlık ve doğru aksiyon gerekiyor. Aksi takdirde, performans sorunu gibi yeni sorunlarla karşılaşabilirsiniz. Belki fırsat olursa ileride de bu konulardan bahsederim.
Ekrem Önsoy
Hiç yorum yok:
Yorum Gönder