IBAnalyst: Veritabanınızı Anlamak

Dmitri Kuzmenko, [email protected], son güncelleme 31-Mart-2014

1994’ten beri InterBase ile çalışıyorum. O zamanlar çoğu veritabanı küçüktü ve herhangi bir ayar gerektirmiyordu. Elbette, sunucuda ibconfig’i değiştirmek veya donanımı ya da işletim sistemini yeniden yapılandırmak zorunda kaldığım durumlar oldu, ancak performansı ayarlamak için yapabildiğim neredeyse tek şey buydu.

Dört yıl önce, şirketimiz InterBase kullanıcılarına teknik destek ve eğitim sağlamaya başladı. Birçok üretim veritabanıyla çalışmak bana çok farklı şeyler öğretti. Ancak, öğrendiklerimin çoğu uygulamalarla ilgiliydi - işlem parametrelerinin kullanımı, sorguların ve sonuç kümelerinin optimize edilmesi.

Elbette, uzun süredir gstat’ı - veritabanı istatistik bilgilerini veren aracı - biliyordum. Eğer gstat çıktısına hiç baktıysanız veya bu konuda opguide.pdf okuduysanız, istatistiksel çıktının sadece bir grup sayıdan başka bir şey gibi göründüğünü bilirsiniz. Tamam, belirli bir tablo veya dizin için parçalanma bilgisini keşfedebilirsiniz, ancak başka hangi yararlı bilgiler elde edilebilir?

Neyse ki, InterBase ile çalışmadan önce, farklı veri yapılarına, nasıl depolandıklarına ve hangi algoritmaları kullandıklarına ilgi duyuyordum. Bu, gstat çıktısını yorumlamama yardımcı oldu. O zamanlar, veritabanını ayarlamaya veya en azından performans sorunlarının nedenini belirlemeye yardımcı olmak için gstat çıktısını analiz edebilecek bir araç yazmaya karar verdim.

Uzun lafın kısası, sonuç IBAnalyst’in yaratılması oldu. Tecrübeme rağmen, hala farklı veritabanlarında çok ilginç şeyler veya performans sorunları bulmamı sağlıyor.

Gerçek sistemlerde çalışma zamanı performansı bir dalga gibi dalgalanır. Bu tür ‘dalgaların’ genliği düşük veya yüksek olabilir, bu yüzden performansın günden güne (veya saatten saate) nasıl değiştiğini görebilirsiniz. Gerçek performans, uygulamanın tasarımı, sunucu yapılandırması, işlem eşzamanlılığı, veritabanındaki sürüm çöpleri ve bunun gibi birçok faktöre bağlıdır. Bir veritabanında neler olup bittiğini (performansın hem olumlu hem de olumsuz yönlerini) öğrenmek için en azından zaman zaman veritabanı istatistiklerine göz atmalısınız.

Şimdi IBAnalyst’in yeteneklerine bir göz atalım. IBAnalyst, gstat veya Services API’den istatistikleri alabilir ve bunları size veritabanı, tabloları ve dizinleri hakkında eksiksiz bilgi veren bir rapora derleyebilir. İstatistiklere göz atarken kullanılabilen yerinde uyarılar içerir; ayrıca ipucu yorumları ve öneri raporları da içerir.

Veritabanı Bilgisi

Şekil 1 Veritabanı istatistiklerinin özeti

Şekil 1’de gösterilen özet, veritabanınız hakkında genel bilgi sağlar. Gösterilen uyarılar veya yorumlar, çok sayıda gerçek dünya üretim veritabanından dikkatlice toplanan bilgilere dayanmaktadır.

Not: Bu makaledeki tüm şekiller, sahiplerinin izniyle gerçek bir üretim veritabanından alınan gstat istatistiklerini içerir.

Daha önce de söylediğim gibi, ham veritabanı istatistikleri şifreli görünür ve yorumlanması zordur. IBAnalyst, olası sorunları sarı veya kırmızı renkte açıkça vurgular ve sorunun ayrıntısı, imleci ilgili girdinin üzerine getirip görüntülenen ipucunu okuyarak kolayca öğrenilebilir. Yukarıdaki şekilden ne keşfedebiliriz? Bu, sayfa boyutu 4096 bayt olan bir dialect 3 veritabanıdır. Altı ila sekiz yıl önce geliştiriciler varsayılan sayfa boyutu olarak 1024 bayt kullanıyordu, ancak daha yakın zamanlarda bu kadar küçük bir sayfa boyutu birçok performans sorununa yol açabilir. Bu veritabanının sayfa boyutu 4k olduğundan, bu sayfa boyutu uygun olduğu için herhangi bir uyarı görüntülenmez.

Ardından, Forced Write parametresinin OFF olarak ayarlandığını ve kırmızı ile işaretlendiğini görebiliriz. InterBase 4.x ve 5.x’te varsayılan olarak bu parametre ON idi. Forced Writes’ın kendisi bir yazma önbelleği yöntemidir: ON olduğunda değiştirilen verileri hemen diske yazar, ancak OFF olduğunda yazmaların işletim sistemi tarafından dosya önbelleğinde belirsiz bir süre saklanacağı anlamına gelir. InterBase 6, veritabanlarını Forced Writes OFF ile oluşturur.

Bu neden IBAnalyst raporunda kırmızı ile işaretlenmiştir? Cevap basit - asenkron yazma kullanmak, güç, işletim sistemi veya sunucu arızası durumlarında veritabanı bozulmasına neden olabilir.

İpucu: Modern HDD arayüzlerinin (ATA, SATA, SCSI) Forced Write On veya Off olarak ayarlandığında performansta önemli bir fark göstermemesi ilginçtir(1).

Raporda sıradaki gizemli “sweep interval” (süpürme aralığı) bulunur. Pozitifse, motorun otomatik çöp toplama başlatma ihtiyacı konusunda uyarıldığı en eski(2) ve en eski anlık görüntü işlemi arasındaki boşluğun boyutunu ayarlar. Bazı sistemlerde, bu eşiğe ulaşmak “ani performans kaybı” etkisine neden olur ve sonuç olarak bazen sweep interval’in 0 olarak ayarlanması (otomatik süpürmeyi tamamen devre dışı bırakma) önerilir. Burada, sweep interval sarı ile işaretlenmiştir, çünkü sweep boşluğunun değeri negatiftir; bu, InterBase 6.0, Firebird ve Yaffil istatistiklerinde olabilir, ancak InterBase 7.x’te olamaz. Sweep boşluğunun değeri sweep interval’den büyükse (sweep interval 0 değilse), sweep interval için rapor girdisi uygun bir ipucu ile kırmızı olarak işaretlenir.

Sonraki 8 satırı bir grup olarak inceleyeceğiz, çünkü hepsi veritabanının işlem durumunun yönlerini gösterir:

En eski işlem (oldest transaction), en eski onaylanmamış işlemdir. Bundan daha düşük işlem numaraları onaylanmış işlemlere aittir ve bu tür işlemler için kayıt sürümleri mevcut değildir. En eski işlemden daha yüksek işlem numaraları, herhangi bir durumda olabilen işlemlere aittir. Buna aynı zamanda “en eski ilginç işlem” de denir, çünkü bir işlem geri alma ile sonlandırıldığında donar ve sunucu o anda değişikliklerini geri alamaz.
En eski anlık görüntü (oldest snapshot) - şu anda en eski “ilginç” işlem olan işlemin başlangıcında var olan en eski aktif (yani henüz onaylanmamış) işlem. Kayıt sürümleriyle ilgilenen en düşük anlık görüntü işlem numarasını gösterir.
En eski aktif (oldest active) - şu anda aktif olan en eski işlem(3).
Sonraki işlem (next transaction) - yeni işleme atanacak işlem numarası.
Aktif işlemler (active transactions) - IBAnalyst, en eski aktif işlem numarası günlük işlem sayısından %30 daha düşükse bir uyarı verecektir. İstatistikler, en eski aktif ile sonraki işlem arasında başka aktif işlemlerin olup olmadığını söylemez, ancak bu tür işlemler olabilir. Genellikle, en eski aktif takılırsa, iki olası neden vardır: a) bazı işlemlerin uzun süre aktif olması veya b) uygulama tasarımının işlemlerin uzun süre çalışmasına izin vermesi. Her iki neden de çöp toplamayı engeller ve sunucu kaynaklarını tüketir.
Günlük işlemler (transactions per day) - bu, sonraki işlemin, veritabanının oluşturulduğu andan istatistiklerin alındığı noktaya kadar geçen gün sayısına bölünmesiyle hesaplanır. Bu yalnızca üretim veritabanları veya işlem numaralandırmasının sıfırlanmasına neden olan yedekten periyodik olarak geri yüklenen veritabanları için doğru olabilir.

Zaten öğrendiğiniz gibi, herhangi bir uyarı varsa, sorunun nasıl düzeltileceği veya önleneceği konusunda net, açıklayıcı ipuçlarıyla renkli satırlar olarak gösterilir.

Veritabanı istatistiklerinin her zaman yararlı olmadığı belirtilmelidir. Çalışma ve bakım işlemleri sırasında toplanan istatistikler anlamsız olabilir.

Aşağıdaki durumlarda istatistik toplamayın:

Veritabanınızı yeni geri yüklediyseniz
-g anahtarı olmadan yedekleme (gbak -b db.gdb) gerçekleştirdiyseniz
Yakın zamanda manuel sweep (gfix -sweep) gerçekleştirdiyseniz

Bu tür durumlarda elde ettiğiniz istatistikler pratik olarak işe yaramaz olacaktır. Ayrıca, normal çalışma sırasında veritabanının mükemmel durumda olduğu zamanlar olabileceği de doğrudur, örneğin uygulamalar normalden daha az veritabanı yükü oluşturduğunda (kullanıcılar öğle yemeğinde veya iş gününün sakin bir zamanı).

Veritabanında bir sorun olduğunu nasıl anlarsınız?

Uygulamalarınız o kadar iyi tasarlanmış olabilir ki her zaman işlemler ve verilerle doğru çalışır, sweep boşlukları oluşturmaz, çok sayıda aktif işlem biriktirmez, uzun süreli anlık görüntüler tutmaz vb. Genellikle bu olmaz (üzgünüm, meslektaşlarım).

En yaygın neden, geliştiricilerin uygulamalarını yalnızca iki veya üç eşzamanlı kullanıcıyla test etmeleridir. Uygulama daha sonra on beş veya daha fazla eşzamanlı kullanıcıyla bir üretim ortamında kullanıldığında, veritabanı öngörülemez şekilde davranabilir. Elbette, çok kullanıcılı mod iyi çalışabilir çünkü çoğu çok kullanıcılı çakışma, iki veya üç eşzamanlı çalışan uygulamayla test edilebilir. Ancak, daha fazla sayıda kullanıcıyla çöp toplama sorunları ortaya çıkabilir. Bu tür potansiyel sorunlar, doğru anlarda veritabanı istatistikleri toplarsanız yakalanabilir.

Tablo bilgisi

IBAnalyst’ten başka bir örnek çıktıya göz atalım.

![](/images/article_IBAnalyst (1).jpg)

Şekil 2 Tablo istatistikleri

IBAnalyst Tablo istatistikleri görünümü de çok kullanışlıdır. Hangi tabloların çok sayıda kayıt sürümüne sahip olduğunu, nerede çok sayıda güncelleme/silme yapıldığını, güncelleme/silme veya blob’lardan kaynaklanan parçalanmış tabloları vb. gösterebilir. Hangi tabloların sık güncellendiğini ve tablo boyutunun megabayt cinsinden ne olduğunu görebilirsiniz. Bu uyarıların çoğu özelleştirilebilir.

Bu veritabanı örneğinde birkaç sorun vardır. Her şeyden önce, VerLen sütunundaki sarı renk, kayıt sürümlerinin kapladığı alanın kayıtların kendilerinin kapladığından daha büyük olduğu konusunda uyarır. Bu, bir kayıttaki birçok alanın güncellenmesinden veya toplu silmelerden kaynaklanabilir. MaxVers sütununun mavi ile işaretlendiği satırlara bakın. Bu, kayıt başına yalnızca bir sürümün saklandığını ve dolayısıyla sorunun toplu silmelerden kaynaklandığını gösterir. Versions sütunundaki değer, kaç kaydın silindiğini gösterir.

Çöp toplamayı engelleyen uzun ömürlü aktif işlemler, performans düşüşünün ana nedenidir. Bazı tablolar için hala “kullanımda” olan birçok sürüm olabilir. Sunucu, bunların gerçekten kullanımda olup olmadığına karar veremez, çünkü aktif işlemler potansiyel olarak bu sürümlerden herhangi birine veya tümüne ihtiyaç duyabilir. Buna göre, sunucu bu sürümleri çöp olarak görmez ve bir işlem onu okuduğunda birçok sürümden doğru bir kayıt oluşturmak giderek daha uzun sürer. Şekil 2’de, sürüm sayısı kayıt sayısından üç kat daha yüksek olan iki tablo görebilirsiniz. Bu bilgiyi kullanarak, uygulamalarınızın bu tabloları bu kadar sık güncellemesinin tasarım gereği mi yoksa bir hata nedeniyle mi olduğunu da kontrol edebilirsiniz.

Dizin görünümü

Dizinler, veritabanı motoru tarafından birincil anahtar, yabancı anahtar ve benzersiz kısıtlamaları uygulamak için kullanılır. Ayrıca veri alımını hızlandırırlar. Benzersiz dizinler veri alımı için en iyisidir, ancak benzersiz olmayan dizinlerden sağlanan fayda düzeyi, dizinlenen verinin çeşitliliğine bağlıdır.

Örneğin, ADDR_ADDRESS_IDX6’ya bakın. Her şeyden önce, dizin adının kendisi manuel olarak oluşturulduğunu gösterir. İstatistikler metadata bilgisiyle Services API tarafından alındıysa, hangi sütunların dizinlendiğini görebilirsiniz (IBAnalyst 1.83 ve sonrasında). İncelenen dizin için 34999 anahtar olduğunu, TotalDup’un 34995 ve MaxDup’un 25056 olduğunu görebilirsiniz. Her iki yinelenen sütun da kırmızı ile işaretlenmiştir. Bunun nedeni, Uniques sütununda görülebileceği gibi, bu dizindeki tüm anahtarlar arasında yalnızca 4 benzersiz anahtar değeri olmasıdır. Ayrıca, en büyük yinelenen zincir (aynı sütun değerine sahip kayıtlara işaret eden anahtar) 25056’dır - yani neredeyse tüm anahtarlar dört benzersiz değerden birini saklar. Sonuç olarak, bu dizin şunları yapabilir:

Geri yükleme işleminin hızını azaltın. Tamam, otuz beş bin anahtar modern veritabanları ve donanımlar için büyük bir sorun değildir, ancak etkisi yine de belirtilmelidir.
Çöp toplamayı yavaşlatın. Düşük sayıda benzersiz değere sahip endeksler, tamamen benzersiz bir endekse kıyasla çöp toplamayı on kata kadar yavaşlatabilir. Bu sorun InterBase 7.1/7.5 ve Firebird 2.0’da çözülmüştür.
Optimizasyon aracı endeksi okuduğunda gereksiz sayfa okumaları üretin. Bu, belirli bir sorguda aranan değere bağlıdır - MaxDup için daha büyük bir değere sahip bir endeksle arama yapmak daha yavaş olacaktır. Daha az yinelenen değere sahip bir sütunda değer aramak daha hızlı olacaktır, ancak sütunun endeksli olduğunu yalnızca siz bilirsiniz.

Bu nedenle IBAnalyst, bu tür endekslere dikkatinizi çeker, onları kırmızı ve sarı renkle işaretler ve Öneriler raporuna dahil eder. Ne yazık ki, “kötü” endekslerin çoğu, yabancı anahtar kısıtlamalarını zorlamak için otomatik olarak oluşturulur. Bazı durumlarda bu sorun, tetikleyiciler kullanılarak, arama tablolarındaki birincil anahtarların silinmesi veya güncellenmesinin engellenmesiyle çözülebilir. Ancak bu tür değişiklikleri uygulamak mümkün değilse, IBAnalyst her istatistik görüntülediğinizde Yabancı Anahtarlar üzerindeki “kötü” endeksleri size gösterecektir.

Raporlar

Her seferinde tüm raporu gözden geçirmeye, hücre rengini fark etmeye ve yeni uyarılar için ipuçlarını okumaya gerek yoktur. Daha doğrudan ve ayrıntılı bilgi, IBAnalyst’ın Öneriler özelliği kullanılarak elde edilebilir. Sadece istatistikleri yükleyin ve Raporlar/Önerileri Görüntüle menüsüne gidin. Bu rapor, zorunlu yazmalar, süpürme aralığı, veritabanı etkinliği, işlem durumu, veritabanı sayfa boyutu, süpürme, işlem envanter sayfaları, parçalanmış tablolar, çok sayıda kayıt sürümüne sahip tablolar, büyük silme/güncelleme işlemleri, derin endeksler, optimizasyon aracı dostu olmayan endeksler, gereksiz endeksler ve hatta boş tablolar hakkında daha ayrıntılı açıklayıcı uyarılar içeren adım adım bir analiz sağlar. Tüm bu bilgiler ve beraberindeki öneriler, yüklenen istatistiklere dayalı olarak dinamik olarak oluşturulur.

Rapor çıktısına bir örnek olarak, bu makalenin başlarında gördüğünüz veritabanı istatistikleri için oluşturulan bir rapora bakalım:

“İşlem envanter sayfalarının (TIP) genel boyutu büyük - 94 kilobayt veya 23 sayfa. Read_committed işlemi global TIP kullanır, ancak snapshot işlemleri TIP’in kendi kopyalarını bellekte oluşturur. Büyük TIP boyutu performansı yavaşlatabilir. TIP boyutunu azaltmak için süpürmeyi manuel olarak çalıştırmayı deneyin (gfix -sweep).”

İşte raporun tablo/endeks bölümünden başka bir alıntı:

“Sürümlenmiş tablo sayısı: 8. Büyük miktarda kayıt sürümü genellikle performansı yavaşlatır. Tabloda çok sayıda kayıt sürümü varsa, çöp toplama çalışmıyor veya kayıtlar herhangi bir select ifadesi tarafından okunmuyor demektir. Bu tablolarda çöp toplamayı zorlamak için select count(*) deneyebilirsiniz, ancak bu uzun sürebilir (çok sayıda sürüm ve benzersiz olmayan endeksler varsa) ve bu sürümlerle ilgilenen en az bir işlem varsa başarısız olabilir.

Sürüm/kayıt oranı 3’ten büyük olan tabloların listesi:


Tablo	Kayıtlar	Sürümler	Kayıt/Sürüm boyutu
CLIENTS_PR	3388	10944	92%
DICT_PRICE	30	1992	45%
DOCS	9	2225	64%
N_PART	13835	72594	83%
REGISTR_NC	241	4085	56%
SKL_NC	1640	7736	170%
STAT_QUICK	17649	85062	110%
UO_LOCK	283	8490	144%

Özet

IBAnalyst, bir kullanıcının Firebird veya InterBase veritabanı istatistiklerinin ayrıntılı analizini yapmasına ve performans, bakım ve uygulamanın veritabanıyla etkileşimi açısından veritabanıyla ilgili olası sorunları belirlemesine yardımcı olan paha biçilmez bir araçtır. Anlaşılması zor veritabanı istatistiklerini alır ve bunları anlaşılması kolay, grafiksel bir şekilde görüntüler ve veritabanı performansını iyileştirme ve veritabanı bakımını kolaylaştırma konusunda otomatik olarak mantıklı önerilerde bulunur.

1 InterBase 7.5 ve Firebird 1.5, Zorunlu Yazmalar Kapalıysa kaydedilmemiş sayfaları periyodik olarak temizleyebilen özel özelliklere sahiptir.

2 En eski işlem, her yerde bahsedilen en eski ilginç işlemle aynıdır. Gstat çıktısı bu işlemi “ilginç” olarak göstermez.

3 Ann Harrison, En eski aktif işlemi, mevcut en eski aktif işlem başladığında aktif olan en eski işlem olarak tanımlar. Uygulamalar için burada büyük bir fark yoktur.