Bu sayfa makine çevirisidir. İngilizce orijinalini okuyun. English

IBAnalyst artık HQbird Standard’ın bir parçası!

IBAnalyst, veritabanı yöneticisinin ayrıntılı Firebird veya InterBase veritabanı istatistiklerini analiz etmesine ve ardından veritabanı performansı, bakımı ve uygulamanın veritabanıyla etkileşimi ile ilgili olası sorunları belirlemesine olanak tanıyan bir araçtır.

Dokümantasyon

IBAnalyst, Firebird (veya InterBase) veritabanı istatistiklerini kullanıcı dostu bir şekilde grafiksel olarak görüntüler ve aşağıdaki sorunları vurgular:

  • tablo ve BLOB parçalanması,
  • kayıt sürümleme,
  • çöp toplama,
  • indeks etkinliği, vb.

Ayrıca IBAnalyst, veritabanı performansını ve veritabanı bakımını iyileştirme konusunda otomatik olarak akıllı önerilerde bulunabilir.

IBAnalyst, istatistikleri canlı üretim veritabanlarından Services API aracılığıyla (önerilir) alabilir veya gstat -a -r … komutlarının metin çıktısını analiz edebilir. Yoğun yük dönemlerindeki istatistikler, üretim veritabanlarındaki gerçek performans sorunları hakkında çok fazla bilgi sağlayabilir.

IBAnalyst, Firebird veya InterBase veritabanınızdaki sorunları bulmanıza nasıl yardımcı olabilir?

IBAnalyst’in temel özelliklerini inceleyelim. IBAnalyst’te veritabanı istatistiklerinize ilk kez baktığınızda, özellikle IBAnalyst Özet, Tablolar ve İndeks görünümlerinde kırmızı ve sarı renkli hücrelerle çok sayıda uyarı gösteriyorsa, bazı şeyler net olmayabilir. Birkaç gerçek istatistik örneğini ele alalım.

Özet Görünümü

IBAnalyst Özet

Özet sayfası çok fazla bilgi gösterir, ancak en değerli olanı işlem durumudur ( lütfen IBAnalyst yardımındaki olası işlem durumlarının açıklamasını okuyun, F1’e tıklayarak veya Yardım menüsünden erişilebilir).

Bu ekran görüntüsünde bazı işlemlerin uzun süredir aktif olduğunu, “günlük ortalamanın %60’ı” kadar olduğunu görebilirsiniz. IBAnalyst bu tür işlem durumunu kırmızı ile işaretler, çünkü bu işlem birikmiş sürümlerin sunucu tarafından çöp olarak değerlendirilmesini ve dolayısıyla çöp toplanmasını engelleyebilir. Bu, yavaşlığın olası bir nedenidir: bir kayıt için ne kadar çok sürüm varsa, onu okumak o kadar uzun sürer.

Bu uzun süren işlemi bulmak için FBScanner’ın MON$Logger modülünü kullanabilir veya MON$ tablolarına doğrudan sorgu yapabilirsiniz. Ardından, uzun süren işlemlerden hangi tabloların etkilendiğini (çok sayıda kayıt sürümü olan tablolar) bulmak için IBAnalyst’in “Tablolar” görünümüne gitmeniz gerekir.

Tablolar Görünümü

IBAnalyst Tablolar

“Tablolar” görünümünde tabloları ve önemli parametrelerini görebilirsiniz: kayıt sayısı, kayıt sürümü sayısı, kayıt uzunluğu, maksimum sürüm sayısı vb.

En büyük tabloları bulmak için bu görünümü sıralayabilirsiniz. Özellikle çok sayıda kayıt sürümü olan tablolarla ilgileniyoruz - çok sayıda kayıt sürümü, etkilenen tablolar için çöp toplamayı uzatacaktır. Genellikle çok sayıda kayıt sürümünden kurtulmak için güncelleme ve silme algoritmalarını değiştirmek gerekir.

Satır Sürümleri belirli bir tablo için toplam sürüm sayısını gösterir ve satır Maks Sürüm bazı kayıtların ulaştığı maksimum sürüm sayısını gösterir. Örneğin, NAB tablosuna bakarsanız, 11,9 milyon kayıt var, toplam sürümler 20932, ancak bir kayıt 176 sürüme sahip. Böyle bir paketi diskten okumak ve ayrıştırmak daha uzun sürer, bu nedenle bu kaydı okumak diğerlerinden daha yavaştır.

Bu resim ayrıca verilerin silindiği birçok tabloyu da gösterir. Ancak, uzun süren işlem nedeniyle sunucu bu sürümleri silemez ve bunlar hâlâ diskte, hâlâ indeksli ve veri okunurken sunucu tarafından hâlâ okunuyor.

İndeks Görünümü

IBAnalyst İndeksler

Bazı üretim veritabanlarında yalnızca tek bir anahtar değeri indekslenmiş indeksler olabilir. Bu, veritabanının “gelecekte genişletilmek üzere” geliştirilmesi veya birinin geliştirme veya test sırasında indekslerle denemeler yapması nedeniyle olabilir. Bu indeksleri IBAnalyst’te “İşe yaramaz” olarak görebilirsiniz:

SKIN04, SKIN05, SKOUT03 vb., tüm satırlar için (milyonlarca satır) yalnızca tek bir değere sahip bir sütun üzerine kurulmuştur. Bu indeksler gerçekten işe yaramaz, çünkü

  • “where field = …” belirtirseniz optimize edici bu indeksi kullanabilir. Alan yalnızca tek bir değer içerdiğinden, indeksi kullanmak indeks sayfalarının diskten belleğe gereksiz yere okunmasına neden olur ve sunucu bu sorgu için hangi satırları göstereceğini hazırlarken bellek (ve zaman) tüketir.
  • indeks oluşturma, geri yükleme sürecinin bir parçasıdır. Ekstra indeksler ekstra zaman ekler.

Elbette, IBAnalyst’te veritabanınız hakkında bulabileceğiniz tek şey bu değil. Ayrıca şunları da bulabilirsiniz:

  • günlük ortalama işlem sayısı
  • geri alma veya bağlantı kaybı olup olmadığı ve ne zaman olduğu
  • her tablo ve indeksin ne kadar büyük olduğu (megabayt cinsinden)
  • kayıtları BLOB’larla değiştirilmiş tablolar ve bu nedenle yalnızca kayıtları okumak daha yavaştır
  • boş tablolar - sadece unutulmuş veya istatistik alındığında boş olanlar
  • çok sayıda yinelenen anahtarı olan indeksler (sütun değeri dağılımını düşünebilirsiniz)
  • derinliği 4 ve üzeri olan indeksler - hızlandırmak için sayfa boyutunu artırmanız gerekebilir

Otomatik öneriler

Renkli hücre uyarılarını okurken kafanız karıştıysa, sadece “Raporlar\Önerileri görüntüle” bölümünü açın - veritabanı performansı için yeterli olan her şey burada toplanmıştır. Lütfen her türlü soruyu sormaktan çekinmeyin ( [email protected])