IBAnalyst: Verstehen Sie Ihre Datenbank

Dmitri Kuzmenko, [email protected], letzte Aktualisierung 31. März 2014

Ich arbeite seit 1994 mit InterBase. Damals waren die meisten Datenbanken klein und benötigten keine Optimierung. Natürlich gab es Gelegenheiten, bei denen ich ibconfig auf einem Server ändern musste und Hardware oder Betriebssystem neu konfigurierte, aber das war fast alles, was ich tun konnte, um die Leistung zu optimieren.

Vor vier Jahren begann unser Unternehmen, technischen Support und Schulungen für InterBase-Benutzer anzubieten. Die Arbeit mit vielen Produktionsdatenbanken hat mir auch viele verschiedene Dinge beigebracht. Das meiste, was ich lernte, betraf jedoch Anwendungen - die Verwendung von Transaktionsparametern, die Optimierung von Abfragen und Ergebnismengen.

Natürlich kannte ich schon seit geraumer Zeit gstat - das Werkzeug, das Datenbank-Statistikinformationen liefert. Wenn Sie jemals in die gstat-Ausgabe geschaut oder opguide.pdf darüber gelesen haben, wissen Sie, dass die statistische Ausgabe wie eine Ansammlung von Zahlen und sonst nichts aussieht. Okay, Sie können Fragmentierungsinformationen für eine bestimmte Tabelle oder einen Index entdecken, aber welche anderen nützlichen Informationen können gewonnen werden?

Glücklicherweise interessierte ich mich vor meiner Arbeit mit InterBase für verschiedene Datenstrukturen, wie sie gespeichert werden und welche Algorithmen sie verwenden. Dies half mir, die Ausgabe von gstat zu interpretieren. Zu dieser Zeit beschloss ich, ein Werkzeug zu schreiben, das die gstat-Ausgabe analysieren konnte, um bei der Optimierung der Datenbank zu helfen oder zumindest die Ursache von Leistungsproblemen zu identifizieren.

Lange Geschichte, aber das Ergebnis war, dass IBAnalyst entwickelt wurde. Trotz meiner Erfahrung ermöglicht es mir immer noch, sehr interessante Dinge oder Leistungsprobleme in verschiedenen Datenbanken zu finden.

Reale Systeme haben eine Laufzeitleistung, die wie eine Welle schwankt. Die Amplitude solcher ‚Wellen‘ kann niedrig oder hoch sein, sodass Sie sehen können, wie sich die Leistung von Tag zu Tag (oder Stunde zu Stunde) unterscheidet. Die tatsächliche Leistung hängt von vielen Faktoren ab, einschließlich des Designs der Anwendung, der Serverkonfiguration, der Transaktionsparallelität, des Versionsmülls in der Datenbank und so weiter. Um herauszufinden, was in einer Datenbank passiert (sowohl positive als auch negative Aspekte der Leistung), sollten Sie zumindest von Zeit zu Zeit einen Blick auf die Datenbankstatistiken werfen.

Werfen wir einen Blick auf die Fähigkeiten von IBAnalyst. IBAnalyst kann Statistiken von gstat oder der Services API übernehmen und sie in einen Bericht zusammenstellen, der Ihnen vollständige Informationen über die Datenbank, ihre Tabellen und Indizes gibt. Es enthält integrierte Warnungen, die beim Durchsuchen der Statistiken verfügbar sind; es enthält auch Hinweiskommentare und Empfehlungsberichte.

Datenbankinformationen

Abbildung 1 Zusammenfassung der Datenbankstatistiken

Die in Abbildung 1 gezeigte Zusammenfassung bietet allgemeine Informationen über Ihre Datenbank. Die angezeigten Warnungen oder Kommentare basieren auf sorgfältig gesammeltem Wissen aus einer großen Anzahl realer Produktionsdatenbanken.

Hinweis: Alle Abbildungen in diesem Artikel enthalten gstat-Statistiken, die aus einer realen Produktionsdatenbank stammen (mit Genehmigung ihrer Eigentümer).

Wie ich bereits sagte, sehen rohe Datenbankstatistiken kryptisch aus und sind schwer zu interpretieren. IBAnalyst hebt potenzielle Probleme deutlich in Gelb oder Rot hervor, und die Details des Problems können einfach gelesen werden, indem Sie den Cursor über den entsprechenden Eintrag bewegen und den angezeigten Hinweis lesen.

Als Nächstes können wir sehen, dass der Parameter Forced Write auf OFF gesetzt und rot markiert ist. InterBase 4.x und 5.x hatten diesen Parameter standardmäßig auf ON. Forced Writes selbst ist eine Schreibcache-Methode: Wenn ON, werden geänderte Daten sofort auf die Festplatte geschrieben, aber OFF bedeutet, dass Schreibvorgänge für unbestimmte Zeit vom Betriebssystem in seinem Dateicache gespeichert werden. InterBase 6 erstellt Datenbanken mit Forced Writes OFF.

Warum ist dies im IBAnalyst-Bericht rot markiert? Die Antwort ist einfach - die Verwendung asynchroner Schreibvorgänge kann bei Strom-, Betriebssystem- oder Serverausfällen zu Datenbankkorruption führen.

Tipp: Es ist interessant, dass moderne HDD-Schnittstellen (ATA, SATA, SCSI) keinen großen Leistungsunterschied zeigen, ob Forced Write auf On oder Off gesetzt ist(1).

Als Nächstes im Bericht ist das mysteriöse „Sweep-Intervall“. Wenn es positiv ist, legt es die Größe der Lücke zwischen der ältesten (2) und der ältesten Snapshot-Transaktion fest, bei der die Engine darauf aufmerksam gemacht wird, dass eine automatische Speicherbereinigung gestartet werden muss. Auf einigen Systemen führt das Erreichen dieses Schwellenwerts zu einem Effekt des „plötzlichen Leistungsverlusts“, und als Ergebnis wird manchmal empfohlen, das Sweep-Intervall auf 0 zu setzen (wodurch automatisches Sweeping vollständig deaktiviert wird). Hier ist das Sweep-Intervall gelb markiert, weil der Wert der Sweep-Lücke negativ ist, was in InterBase 6.0, Firebird und Yaffil-Statistiken vorkommen kann, aber nicht in InterBase 7.x. Wenn der Wert der Sweep-Lücke größer als das Sweep-Intervall ist (falls das Sweep-Intervall nicht 0 ist), wird der Berichtseintrag für das Sweep-Intervall rot mit einem entsprechenden Hinweis markiert.

Wir werden die nächsten 8 Zeilen als Gruppe untersuchen, da sie alle Aspekte des Transaktionszustands der Datenbank anzeigen:

Die älteste Transaktion ist die älteste nicht festgeschriebene Transaktion. Alle niedrigeren Transaktionsnummern gehören zu festgeschriebenen Transaktionen, und für solche Transaktionen sind keine Datensatzversionen verfügbar. Transaktionsnummern höher als die älteste Transaktion gehören zu Transaktionen, die sich in jedem Zustand befinden können. Dies wird auch als „älteste interessante Transaktion“ bezeichnet, da sie eingefroren wird, wenn eine Transaktion mit Rollback endet und der Server ihre Änderungen in diesem Moment nicht rückgängig machen kann.
Der älteste Snapshot - die älteste aktive (d. h. noch nicht festgeschriebene) Transaktion, die zum Start der Transaktion existierte, die derzeit die älteste „interessante“ Transaktion ist. Gibt die niedrigste Snapshot-Transaktionsnummer an, die an Datensatzversionen interessiert ist.
Die älteste aktive - die älteste derzeit aktive Transaktion (3).
Die nächste Transaktion - die Transaktionsnummer, die einer neuen Transaktion zugewiesen wird.
Aktive Transaktionen - IBAnalyst gibt eine Warnung aus, wenn die älteste aktive Transaktionsnummer 30 % niedriger ist als die tägliche Transaktionsanzahl. Die Statistiken sagen nicht, ob es andere aktive Transaktionen zwischen der ältesten aktiven und der nächsten Transaktion gibt, aber solche Transaktionen können existieren. Normalerweise gibt es zwei mögliche Ursachen, wenn die älteste aktive Transaktion hängen bleibt: a) eine Transaktion ist lange Zeit aktiv oder b) das Anwendungsdesign erlaubt es, dass Transaktionen lange laufen. Beide Ursachen verhindern die Speicherbereinigung und verbrauchen Serverressourcen.
Transaktionen pro Tag - dies wird aus der nächsten Transaktion berechnet, geteilt durch die Anzahl der Tage, die seit der Erstellung der Datenbank bis zum Zeitpunkt der Statistikabfrage vergangen sind. Dies kann nur für Produktionsdatenbanken korrekt sein oder für Datenbanken, die regelmäßig aus Backups wiederhergestellt werden, wodurch die Transaktionsnummerierung zurückgesetzt wird.

Wie Sie bereits gelernt haben, werden Warnungen, falls vorhanden, als farbige Zeilen mit klaren, beschreibenden Hinweisen angezeigt, wie das Problem behoben oder verhindert werden kann.

Es sollte beachtet werden, dass Datenbankstatistiken nicht immer nützlich sind. Statistiken, die während der Arbeit und Wartungsvorgängen gesammelt werden, können bedeutungslos sein.

Sammeln Sie keine Statistiken, wenn Sie:

Ihre Datenbank gerade wiederhergestellt haben
Ein Backup (gbak -b db.gdb) ohne den Schalter -g durchgeführt haben
Kürzlich einen manuellen Sweep (gfix -sweep) durchgeführt haben

Statistiken, die Sie bei solchen Gelegenheiten erhalten, sind praktisch nutzlos. Es ist auch richtig, dass es während der normalen Arbeit Zeiten geben kann, in denen sich die Datenbank in einem perfekten Zustand befindet, zum Beispiel wenn Anwendungen weniger Datenbanklast erzeugen als üblich (Benutzer sind beim Mittagessen oder es ist eine ruhige Zeit im Geschäftstag).

Wie können Sie erkennen, wann etwas mit der Datenbank nicht stimmt?

Ihre Anwendungen können so gut entworfen sein, dass sie immer korrekt mit Transaktionen und Daten arbeiten, keine Sweep-Lücken erzeugen, nicht viele aktive Transaktionen ansammeln, keine lang laufenden Snapshots halten und so weiter. Normalerweise passiert das nicht (Entschuldigung, Kollegen).

Der häufigste Grund ist, dass Entwickler ihre Anwendungen nur mit zwei oder drei gleichzeitigen Benutzern testen. Wenn die Anwendung dann in einer Produktionsumgebung mit fünfzehn oder mehr gleichzeitigen Benutzern verwendet wird, kann sich die Datenbank unvorhersehbar verhalten. Natürlich kann der Mehrbenutzermodus gut funktionieren, da die meisten Mehrbenutzerkonflikte mit zwei oder drei gleichzeitig laufenden Anwendungen getestet werden können. Bei einer größeren Anzahl von Benutzern können jedoch Probleme mit der Speicherbereinigung auftreten. Solche potenziellen Probleme können erkannt werden, wenn Sie Datenbankstatistiken zu den richtigen Zeitpunkten sammeln.

Tabelleninformationen

Werfen wir einen Blick auf eine weitere Beispielausgabe von IBAnalyst.

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

Abbildung 2 Tabellenstatistiken

Die Tabellenstatistikansicht von IBAnalyst ist ebenfalls sehr nützlich. Sie kann zeigen, welche Tabellen viele Datensatzversionen haben, wo eine große Anzahl von Updates/Löschungen durchgeführt wurde, fragmentierte Tabellen, bei denen die Fragmentierung durch Update/Delete oder durch Blobs verursacht wurde, und so weiter. Sie können sehen, welche Tabellen häufig aktualisiert werden und wie groß die Tabelle in Megabyte ist. Die meisten dieser Warnungen sind anpassbar.

In diesem Datenbankbeispiel gibt es mehrere Probleme. Zunächst warnt die gelbe Farbe in der Spalte VerLen, dass der von Datensatzversionen belegte Speicherplatz größer ist als der von den Datensätzen selbst belegte. Dies kann durch das Aktualisieren vieler Felder in einem Datensatz oder durch Massenlöschungen verursacht werden. Sehen Sie sich die Zeilen an, in denen die Spalte MaxVers blau markiert ist. Dies zeigt, dass nur eine Version pro Datensatz gespeichert wird und folglich das Problem auf Massenlöschungen zurückzuführen ist. Der Wert in der Spalte Versions zeigt, wie viele Datensätze gelöscht wurden.

Lang lebende aktive Transaktionen, die die Speicherbereinigung verhindern, sind der Hauptgrund für Leistungsverschlechterungen. Für einige Tabellen kann es viele Versionen geben, die noch „in Gebrauch“ sind. Der Server kann nicht entscheiden, ob sie wirklich in Gebrauch sind, da aktive Transaktionen potenziell jede oder alle dieser Versionen benötigen. Dementsprechend betrachtet der Server diese Versionen nicht als Müll, und es dauert immer länger, einen korrekten Datensatz aus vielen Versionen zu konstruieren, wenn eine Transaktion ihn zufällig liest. In Abbildung 2 sehen Sie zwei Tabellen, bei denen die Versionsanzahl dreimal höher ist als die Datensatzanzahl. Mit diesen Informationen können Sie auch überprüfen, ob die Tatsache, dass Ihre Anwendungen diese Tabellen so häufig aktualisieren, beabsichtigt ist oder auf einen Fehler zurückzuführen ist.

Die Indexansicht

Indizes werden von der Datenbank-Engine verwendet, um Primärschlüssel-, Fremdschlüssel- und Unique-Constraints durchzusetzen. Sie beschleunigen auch den Datenabruf. Unique-Indizes sind am besten für den Datenabruf geeignet, aber der Nutzen von nicht-uniquen Indizes hängt von der Vielfalt der indizierten Daten ab.

Zum Beispiel sehen Sie sich ADDR_ADDRESS_IDX6 an. Zunächst deutet der Indexname selbst darauf hin, dass er manuell erstellt wurde. Wenn Statistiken über die Services API mit Metadateninformationen abgerufen wurden, können Sie sehen, welche Spalten indiziert sind (in IBAnalyst 1.83 und höher). Für den untersuchten Index können Sie sehen, dass er 34999 Schlüssel hat, TotalDup ist 34995 und MaxDup ist 25056. Beide Duplikatspalten sind rot markiert. Dies liegt daran, dass es nur 4 eindeutige Schlüsselwerte unter allen Schlüsseln in diesem Index gibt, wie aus der Spalte Uniques ersichtlich ist. Darüber hinaus ist die größte Duplikatkette (Schlüssel, der auf Datensätze mit demselben Spaltenwert verweist) 25056 - d. h. fast alle Schlüssel speichern einen von vier eindeutigen Werten. Als Ergebnis könnte dieser Index:

Reduzieren Sie die Geschwindigkeit des Wiederherstellungsprozesses. Okay, fünfunddreißigtausend Schlüssel sind für moderne Datenbanken und Hardware keine große Sache, aber die Auswirkung sollte dennoch beachtet werden.
Verlangsamen Sie die Garbage Collection. Indizes mit einer geringen Anzahl eindeutiger Werte können die Garbage Collection im Vergleich zu einem vollständig eindeutigen Index um bis zu zehnmal behindern. Dieses Problem wurde in InterBase 7.1/7.5 und Firebird 2.0 gelöst.
Erzeugen Sie unnötige Seitenlesevorgänge, wenn der Optimierer den Index liest. Es hängt von dem Wert ab, der in einer bestimmten Abfrage gesucht wird - die Suche über einen Index mit einem größeren Wert für MaxDup wird langsamer sein. Die Suche nach einem Wert in einer Spalte mit weniger doppelten Werten wird schneller sein, aber nur Sie wissen, dass die Spalte indiziert ist.

Deshalb lenkt IBAnalyst Ihre Aufmerksamkeit auf solche Indizes, markiert sie rot und gelb und nimmt sie in den Bericht „Empfehlungen“ auf. Leider werden die meisten „schlechten“ Indizes automatisch erstellt, um Fremdschlüssel-Constraints durchzusetzen. In einigen Fällen kann dieses Problem gelöst werden, indem Löschungen oder Aktualisierungen von Primärschlüsseln in Nachschlagetabellen mithilfe von Triggern verhindert werden. Wenn solche Änderungen jedoch nicht umgesetzt werden können, zeigt Ihnen IBAnalyst jedes Mal, wenn Sie Statistiken anzeigen, „schlechte“ Indizes auf Fremdschlüsseln.

Berichte

Es besteht keine Notwendigkeit, jedes Mal den gesamten Bericht durchzusehen, Zellfarben zu erkennen und Hinweise auf neue Warnungen zu lesen. Direktere und detailliertere Informationen erhalten Sie über die Funktion „Empfehlungen“ von IBAnalyst. Laden Sie einfach die Statistiken und gehen Sie zum Menü Berichte/Empfehlungen anzeigen. Dieser Bericht bietet eine schrittweise Analyse, einschließlich detaillierterer beschreibender Warnungen zu erzwungenen Schreibvorgängen, Sweep-Intervall, Datenbankaktivität, Transaktionsstatus, Datenbankseitengröße, Sweeping, Transaktionsinventarseiten, fragmentierten Tabellen, Tabellen mit vielen Datensatzversionen, massiven Löschungen/Aktualisierungen, tiefen Indizes, optimiererunfreundlichen Indizes, nutzlosen Indizes und sogar leeren Tabellen. Alle diese Informationen und die begleitenden Vorschläge werden dynamisch basierend auf den geladenen Statistiken erstellt.

Als Beispiel für die Ausgabe des Berichts werfen wir einen Blick auf einen Bericht, der für die Datenbankstatistiken generiert wurde, die Sie früher in diesem Artikel gesehen haben:

„Die Gesamtgröße der Transaktionsinventarseiten (TIP) ist groß - 94 Kilobyte oder 23 Seiten. Read_committed-Transaktionen verwenden das globale TIP, aber Snapshot-Transaktionen erstellen eigene Kopien des TIP im Speicher. Eine große TIP-Größe kann die Leistung verlangsamen. Versuchen Sie, den Sweep manuell auszuführen (gfix -sweep), um die TIP-Größe zu verringern.“

Hier ist ein weiteres Zitat aus dem Tabellen-/Indizes-Teil des Berichts:

„Anzahl der versionierten Tabellen: 8. Eine große Anzahl von Datensatzversionen verlangsamt normalerweise die Leistung. Wenn es viele Datensatzversionen in einer Tabelle gibt, funktioniert die Garbage Collection nicht oder Datensätze werden von keiner SELECT-Anweisung gelesen. Sie können versuchen, select count(*) auf diesen Tabellen auszuführen, um die Garbage Collection zu erzwingen, aber dies kann lange dauern (wenn es viele Versionen und nicht-eindeutige Indizes gibt) und kann erfolglos sein, wenn mindestens eine Transaktion an diesen Versionen interessiert ist.

Hier ist die Liste der Tabellen mit einem Versions-/Datensatzverhältnis größer als 3:


Tabelle	Datensätze	Versionen	Dat/Vers-Größe
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%

Zusammenfassung

IBAnalyst ist ein unschätzbares Werkzeug, das einem Benutzer hilft, eine detaillierte Analyse der Firebird- oder InterBase-Datenbankstatistiken durchzuführen und mögliche Probleme mit einer Datenbank in Bezug auf Leistung, Wartung und die Interaktion einer Anwendung mit der Datenbank zu identifizieren. Es nimmt kryptische Datenbankstatistiken und zeigt sie auf eine leicht verständliche, grafische Weise an und macht automatisch sinnvolle Vorschläge zur Verbesserung der Datenbankleistung und zur Erleichterung der Datenbankwartung.

1 InterBase 7.5 und Firebird 1.5 verfügen über spezielle Funktionen, die nicht gespeicherte Seiten regelmäßig leeren können, wenn Forced Writes deaktiviert ist.

2 Die älteste Transaktion ist dieselbe älteste interessante Transaktion, die überall erwähnt wird. Die Gstat-Ausgabe zeigt diese Transaktion nicht als „interessant“.

3 Ann Harrison sagt, dass „Oldest active“ die älteste Transaktion ist, die aktiv war, als die aktuell älteste aktive Transaktion gestartet wurde. Für Anwendungen macht dies hier keinen großen Unterschied.