IBAnalyst ist jetzt Teil von HQbird Standard!

IBAnalyst ist ein Werkzeug, das es einem Datenbankadministrator ermöglicht, detaillierte Firebird- oder InterBase-Datenbankstatistiken zu analysieren und anschließend mögliche Probleme mit der Datenbankleistung, der Wartung und der Interaktion einer Anwendung mit der Datenbank zu identifizieren.

Dokumentation

IBAnalyst zeigt Firebird- (oder InterBase-) Datenbankstatistiken grafisch auf benutzerfreundliche Weise an und hebt die folgenden Probleme hervor:

Fragmentierung von Tabellen und BLOBs,
Datensatzversionierung,
Garbage Collection,
Effektivität von Indizes usw.

Darüber hinaus kann IBAnalyst automatisch intelligente Vorschläge zur Verbesserung der Datenbankleistung und Datenbankwartung machen.

IBAnalyst kann Statistiken von Live-Produktionsdatenbanken über die Services API (empfohlen) abrufen oder die Textausgabe von gstat -a -r …-Befehlen analysieren. Statistiken aus Spitzenlastzeiten können viele Informationen über tatsächliche Leistungsprobleme in Produktionsdatenbanken liefern.

Wie IBAnalyst helfen kann, Probleme in Ihrer Firebird- oder InterBase-Datenbank zu finden

Lassen Sie uns die wichtigsten Funktionen von IBAnalyst durchgehen. Wenn Sie Ihre Datenbankstatistiken zum ersten Mal in IBAnalyst betrachten, können die Dinge unklar sein, insbesondere wenn IBAnalyst viele Warnungen durch rot und gelb gefärbte Zellen in den Ansichten Zusammenfassung, Tabellen und Indizes anzeigt. Betrachten wir einige reale Statistikbeispiele.

Zusammenfassungsansicht

Die Zusammenfassungsseite zeigt viele Informationen, aber am wertvollsten ist der Transaktionsstatus ( bitte lesen Sie die Beschreibung der möglichen Transaktionszustände in der IBAnalyst-Hilfe, die durch Drücken von F1 oder im Menü Hilfe verfügbar ist).

Auf diesem Screenshot können Sie sehen, dass eine Transaktion seit langer Zeit aktiv ist, “60% des Tagesdurchschnitts”. IBAnalyst markiert den Zustand einer solchen Transaktion rot, weil diese Transaktion verhindern kann, dass angesammelte Versionen vom Server als Müll betrachtet und daher per Garbage Collection entfernt werden. Dies ist ein möglicher Grund für Langsamkeit: Je mehr Versionen für einen bestimmten Datensatz existieren, desto mehr Zeit wird zum Lesen benötigt.

Um diese langlaufende Transaktion zu finden, können Sie das MON$Logger-Modul von FBScanner verwenden oder eine direkte Abfrage der MON$-Tabellen durchführen. Um dann herauszufinden, welche Tabellen von langlaufenden Transaktionen betroffen waren (Tabellen mit vielen Datensatzversionen), müssen Sie zur Ansicht “Tabellen” von IBAnalyst gehen.

Tabellenansicht

In der Ansicht “Tabellen” sehen Sie Tabellen und ihre wichtigen Parameter: Anzahl der Datensätze, Anzahl der Datensatzversionen, Datensatzlänge, maximale Anzahl von Versionen usw.

Sie können diese Ansicht sortieren, um die größten Tabellen zu finden. Besonders interessant sind Tabellen mit vielen Datensatzversionen - viele Datensatzversionen verlängern die Garbage Collection für betroffene Tabellen. Normalerweise ist es notwendig, Update- und Delete-Algorithmen zu ändern, um viele Datensatzversionen loszuwerden.

Zeilenversionen zeigen die Gesamtzahl der Versionen für eine bestimmte Tabelle, und Zeile Max-Versionen zeigt die maximale Anzahl von Versionen, die ein Datensatz erreicht hat. Wenn Sie sich zum Beispiel die Tabelle NAB ansehen, gibt es 11,9 Millionen Datensätze, insgesamt 20932 Versionen, aber ein Datensatz hat 176 Versionen. Das Lesen und Parsen eines solchen Pakets von der Festplatte dauert länger, daher ist das Lesen dieses Datensatzes langsamer als das Lesen anderer.

Dieses Bild zeigt auch viele Tabellen, in denen Daten gelöscht wurden. Aber wegen der langlaufenden Transaktion kann der Server diese Versionen nicht löschen, und sie sind immer noch auf der Festplatte, immer noch indiziert und werden beim Lesen von Daten immer noch vom Server gelesen.

Indexansicht

Einige Produktionsdatenbanken können Indizes haben, bei denen nur ein einziger Schlüsselwert indiziert ist. Dies kann passieren, weil die Datenbank “für zukünftige Erweiterungen” entwickelt wurde oder jemand während der Entwicklung oder Tests einfach mit den Indizes experimentiert hat. Sie können diese Indizes in IBAnalyst als “Nutzlos” sehen:

SKIN04, SKIN05, SKOUT03 usw., die auf einer Spalte aufgebaut sind, die nur einen einzigen Wert für alle Zeilen hat (Millionen von Zeilen). Diese Indizes sind wirklich nutzlos, weil

der Optimierer diesen Index verwenden kann, wenn Sie “where field = …” angeben. Da das Feld nur einen Wert enthält, führt die Verwendung des Index zu nutzlosem Lesen von Indexseiten von der Festplatte in den Speicher und verbraucht Speicher (und Zeit), wenn der Server vorbereitet, welche Zeilen für diese Abfrage angezeigt werden sollen.
das Erstellen von Indizes ist Teil des Wiederherstellungsprozesses. Zusätzliche Indizes bedeuten zusätzliche Zeit.

Natürlich ist das nicht alles, was Sie in IBAnalyst über Ihre Datenbank herausfinden können. Sie können auch Folgendes finden:

durchschnittliche Anzahl von Transaktionen pro Tag
ob es Rollbacks oder verlorene Verbindungen gab und wann
wie groß (in Megabyte) jede Tabelle und jeder Index ist
Tabellen, die Datensätze haben, die mit BLOBs durchsetzt sind, wodurch das Lesen nur der Datensätze langsamer ist
leere Tabellen - einfach vergessen oder zum Zeitpunkt der Statistikaufnahme leer
Indizes mit vielen doppelten Schlüsseln (Sie können über die Werteverteilung der Spalte nachdenken)
Indizes mit einer Tiefe von 4 und mehr - vielleicht müssen Sie die Seitengröße erhöhen, um zu beschleunigen

Automatische Empfehlungen

Wenn Sie durch das Lesen der farbigen Zellenwarnungen verwirrt sind, öffnen Sie einfach “Berichte\Empfehlungen anzeigen” - alles, was für die Datenbankleistung ausreichend ist, ist hier gesammelt. Bitte zögern Sie nicht, Fragen zu stellen ( [email protected]).