IBAnalyst: Was Sie in der Summary View sehen können

Dmitry Kuzmenko, letzte Aktualisierung 31-03-2014

Zusammenfassung

Dieses Dokument erklärt die Informationen auf der Seite „Summary view“ von IBAnalyst und wie Sie diese Informationen für Ihre eigene Datenbankstatistik interpretieren können. Außerdem haben wir der Installationspaket mehrere Beispiele für Statistiken hinzugefügt, um Ihnen das Studium aller Feinheiten der InterBase-Statistiken zu erleichtern. Diese befinden sich im Verzeichnis „Examples“ der IBAnalyst-Installation.

Wenn Sie nicht wissen, was „Oldest transaction“, „Oldest snapshot“, „active“ und „Next“ bedeuten, lesen Sie bitte zuerst Craig Stunz‘ Artikel „Understanding Transactions Lifetime“:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Transaktionsnummern

Wenn Sie den Artikel „Understanding Transaction Lifetimes“ gelesen haben, haben Sie möglicherweise noch Fragen zu den OIT/OST/OAT-Nummern. Hier ist eine kurze Beschreibung:


Nummer	Wird gehalten, …	Bewegt sich vorwärts, …
Oldest transaction	wenn eine Transaktion mit dieser Nummer zurückgerollt wurde und viele Datenänderungen enthielt, oder wenn die Client-Verbindung verloren ging	wenn ein automatischer oder manueller Sweep erfolgreich ist.
Oldest Snapshot	wenn eine Snapshot-Transaktion (oder Read Committed Write vor IB 7.1) lange Zeit aktiv ist (sie merkt sich den ältesten aktiven Snapshot als ihren lokalen OST)	wenn eine neue Transaktion startet, wenn die Transaktion, die den OST hält, beendet wird
Oldest Active	wenn eine Transaktion mit dieser Nummer lange Zeit aktiv ist	wenn eine neue Transaktion startet, wenn die Transaktion, die den OAT hält, beendet wird
Next	nie	wenn eine neue Transaktion startet

Hinweis: „Oldest transaction“ ist hier dasselbe wie „Oldest Interesting Transaction“ (OIT), das in vielen anderen Artikeln erwähnt wird.

Feine Statistik mit Standardeinstellungen

Starten wir IBAnalyst und öffnen wir (über das Menü Statistik/Statistik aus Datei laden) die Datei !allok.txt.

IBAnalyst meldet nicht nur das Erstellungsdatum der Datenbank, sondern erkennt auch das aktuelle Datum/Uhrzeit auf dem Server, wenn die Statistik über die Services API erfasst wurde, oder das Dateidatum, wenn eine Statistikdatei geladen wurde.

Deshalb empfehlen wir, Statistikdateien nicht zu verändern, da IBAnalyst in diesem Fall die durchschnittlichen Transaktionen pro Tag falsch berechnet. Die Zeile „Transaktionen pro Tag“ zeigt hier etwa ~12500 Transaktionen pro Tag und dass die Datenbank seit ihrer Erstellung oder Wiederherstellung 8 Tage „lebt“.

Oldest, Oldest snapshot, Oldest active und Next-Transaktionen sind hier in perfektem Zustand - wir wünschen Ihnen, dass Ihre Statistiken immer so aussehen.

Viele aktive Transaktionen

Öffnen Sie als Nächstes die Datei !lotofactive.txt (Sie können jederzeit auf das !allok-Bild zurückblicken, um die folgenden Beispiele damit zu vergleichen).

Hier ist die Zeile „Aktive Transaktionen“ rot markiert, weil es eine große Differenz zwischen „Oldest active“ und „Next“-Transaktion gibt. Das bedeutet, dass eine Transaktion zum Zeitpunkt der Statistikaufnahme noch aktiv war und nach ihrem Start bereits 55.000 Transaktionen gestartet wurden (sie können sich in jedem Zustand befinden - aktiv, committet, zurückgerollt). Da die durchschnittliche Anzahl der Transaktionen pro Tag ~12500 beträgt, zeigt IBAnalyst eine Warnung an, dass eine Transaktion seit 4,4 Tagen noch lebt. Dies kann passieren, wenn:

eine Anwendung noch läuft und mindestens eine Transaktion offen hat - ein Benutzer lässt die Anwendung möglicherweise lange laufen
eine Anwendung lange läuft und Transaktions-Handles verliert - d.h., Ihr Code (oder Komponenten/Bibliotheken, die Sie verwenden) startet dynamisch Transaktionen und „vergisst“ unter bestimmten Umständen, sie mit Rollback oder Commit zu beenden.
Ihre Anwendung keine expliziten Transaktionen verwendet (BDE) und die Transaktionsverwaltung den verwendeten Komponenten überlässt. Dadurch werden die Transaktionslebensdauern nicht von der Anwendung kontrolliert, und Sie können sicher sein, dass die meisten Next-OAT-Transaktionen tatsächlich aktiv sind.
Ihre Anwendung einen Treiber oder Komponenten verwendet, die eine „Standardtransaktion“ erlauben. Wenn Ihr Code diese Transaktion nicht kontrolliert, kann sie sehr lange laufen.

Leider zeigt die Statistik nicht die tatsächliche Anzahl der aktuell aktiven Transaktionen. Dies kann nur in InterBase 7.x über IBConsole, den IB Performance Monitor oder über eine direkte Abfrage der temporären Systemtabelle tmp$transactions angezeigt werden. In Firebird 1.5 können Sie isc_database_info mit dem Parameter isc_info_active_transactions aufrufen.

Sweeping

Öffnen wir nun !needsweep.txt.

Sweep ist ein Wartungsprozess innerhalb von InterBase. Der Sweep durchläuft alle Datensätze in der Datenbank und versucht, alle Garbage-Versionen zu bereinigen, und versucht dann, die Nummer der ältesten Transaktion nach oben zu bewegen. In einer neu erstellten Datenbank beträgt das Sweep-Intervall standardmäßig 20000. Wenn die Differenz zwischen Transaktionen (siehe Tabelle unten) größer als das Sweep-Intervall wird, wird der Sweep automatisch ausgeführt. So können Sie periodische Leistungseinbußen in Ihrer Datenbank beobachten. Zum Beispiel funktionieren Ihre Anwendungen am Montag und Dienstag einwandfrei, aber am Mittwoch melden Benutzer Leistungsprobleme für einige Stunden, und danach ist die Leistung wieder in Ordnung.

Wenn Sie ein ähnliches Verhalten sehen - handelt es sich um einen automatischen Sweep.


Serverversion	Wann der Sweep läuft
InterBase 7.x	(Oldest Active - Oldest) > Sweep-Intervall
InterBase 4.x, 5.x, 6.x, Firebird vor 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > Sweep-Intervall

Tabelle 1. Bedingungen für den automatischen Sweep

Hinweis: IBAnalyst zeigt automatisch die korrekten Sweep-Gap-Informationen für alle Versionen an. IBAnalyst kann Unterschiede zwischen Serverimplementierungen nur anhand der ODS-ID erkennen, z.B. hat InterBase 7.x ODS 11.x, andere moderne Server haben ODS 10.x. Wenn Sie nur mit InterBase 7.x-Datenbanken (ODS 11) arbeiten, können Sie die entsprechende Option im Optionsdialog umschalten.

Wenn Ihre Datenbank ein Sweep-Intervall <> 0 hat, markiert IBAnalyst diese Zeile grundsätzlich gelb (als Warnung, dass der automatische Sweep zu jedem unvorhersehbaren Zeitpunkt starten kann). Generell haben 60% aller Anwendungen Probleme mit dem automatischen Sweep. Der einfachste Weg, dieses Problem zu vermeiden, besteht darin, das Sweep-Intervall auf 0 zu setzen, was zum Abschalten des automatischen Sweeps führt. Wenn jedoch eine Anwendung viele Änderungen vornimmt und dann zurückrollt, wird die älteste Transaktion eingefroren und bewegt sich erst nach einem Sweep nach oben. Da der effektive Transaktionszustand von der ältesten bis zur nächsten Transaktion berechnet wird, wächst diese Distanz und die Leistung sinkt. Um dies zu verhindern, müssen Sie den Sweep manuell ausführen (gfix -sweep). Auf diesem Bild sehen Sie das Verhalten, wenn das Sweep-Intervall 0 ist und eine große Transaktion zurückgerollt wurde:

Hier zeigt der Sweep-Gap-Wert, dass eine große (viele Änderungen enthaltende) Transaktion vor etwa 4,5 Tagen zurückgerollt wurde. Wir empfehlen, den Sweep täglich manuell auszuführen.

Natürlich ist es für die erwähnten 60% der Anwendungen vielleicht besser, das Sweep-Intervall größer oder kleiner als 20000 zu setzen, aber das hängt von vielen Faktoren ab (die tägliche Transaktionsanzahl ist einer dieser Faktoren, zum Beispiel) und kann nur experimentell ermittelt werden. Wenn Sie das Sweep-Intervall auf 0 setzen, können Sie sicher sein, dass der Sweep nicht zu einem unvorhersehbaren Zeitpunkt automatisch läuft.

Dasselbe Bild sehen Sie für die Datei !rollback.txt.

Hinweis: Wenn der Sweep automatisch läuft, können bei einer großen Datenbank oder einer Datenbank mit vielen Garbage-Record-Versionen die Snapshot-, Active- und Next-Transaktionen während des Sweeps vorwärts wandern, und der Sweep kann beim nächsten Transaktionsstart erneut beginnen.

Wenn der Sweep seine Arbeit nicht erledigen kann

Es gibt viele Fälle, in denen der Sweep die älteste Transaktion nicht nach oben bewegen kann. Natürlich versucht der Sweep zuerst, seine Arbeit zu erledigen, d.h. alle Datensätze in der Datenbank zu überprüfen und unnötige Record-Versionen zu sammeln. Aber er wird immer wieder ohne Erfolg laufen, wenn

es ein Problem beim Sweep gab: Der Server wurde während des Sweeps gestoppt, oder es gab einen Fehler bei der Bereinigung der Garbage-Record-Versionen. Außerdem können Sie dieses Bild sehen, wenn:

die Statistik erfasst wurde, während der Sweep arbeitet
der Sweep läuft und versucht, Garbage für eine Tabelle zu sammeln, die ständig aktualisiert wird. Dies kann dauern, bis die Aktualisierungen enden.
der Sweep aufgrund von Seitensperren ins Stocken gerät, weil viele Benutzer mit Daten arbeiten.

Im Allgemeinen hat der Sweep bei hoher Datenbanklast keine Chance, fertig zu werden. Wenn die Leistung so weit abfällt, dass eine normale Arbeit unmöglich wird, startet der DBA den Server neu, und der Sweep läuft bei der ersten Benutzerverbindung. Da einige Zeit vergeht, bis sich andere Benutzer verbinden, hat der Sweep Zeit, seine Arbeit zu beenden.

Da InterBase 7.1/7.5 den Sweep-Gap anders berechnet als frühere Versionen, ist eine weitere Situation, in der der Sweep seine Arbeit nicht erledigen kann, wenn eine Anwendung eine lang laufende Snapshot-Transaktion hat:

Hier gibt es zwei Warnungen - eine (gelb) über eine lang laufende Snapshot-Transaktion und eine andere (rot) über das Sweep-Intervall und den Sweep-Gap.

Lang laufende Snapshot-Transaktion

Das vorherige Bild zeigt eine lang laufende Snapshot-Transaktion in InterBase 7.1/7.5. Wenn das Sweep-Intervall auf 0 gesetzt wäre, gäbe es keine roten Warnungen, nur gelbe. Ein ähnliches Bild zeigt eine lang laufende Snapshot-Transaktion in anderen InterBase-, Firebird- und Yaffil-Versionen:

Wie Sie sehen, wird der Sweep-Gap hier aus der Differenz zwischen Oldest Snapshot und Oldest transaction berechnet (für ODS 10, Pre-IB7.x-Versionen). Es gibt also keine Sweep-Warnung (außer dem Standard-Sweep-Intervall).

Aber nicht nur Snapshot-Transaktionen beeinflussen den Transaktionszustand auf diese Weise. Alle InterBase-, Firebird- und Yaffil-Versionen außer InterBase 7.1/7.5 zeigen das folgende Verhalten, das wir „Read Committed-Artefakt“ genannt haben.

Snapshots noch einmal und wenn ReadCommitted den Oldest Snapshot einfriert

Öffnen Sie !snapshot2.txt:

Beachten Sie, dass die älteste Transaktion größer als der älteste Snapshot ist. Und der Sweep-Gap hat einen negativen Wert. Dies kann in zwei Fällen passieren. Der erste Fall ist, wenn einige Snapshot-Transaktionen nacheinander starten und committen. D.h., dieses Bild kann sowohl mit Snapshots als auch mit dem vorherigen Bild auftreten. Der nächste Fall tritt nur auf Servern auf, die nicht IB 7.1/7.5 sind, mit ReadCommitted-Transaktionen (oder in Kombination von ReadCommitted- und Snapshot-Transaktionen). Sie können die Oldest-Snapshot-Nummer auf dieselbe Weise sperren wie Snapshot-Transaktionen. Der aktuelle Transaktionszustand kann mit der folgenden Sequenz emuliert werden:

Transaktion 1 starten, snapshot oder read_committed
einige read_committed-Transaktionen starten/committen
Transaktion 2 starten, snapshot oder read_committed
einige read_committed-Transaktionen starten/committen
Transaktion 1 committen

(natürlich sprechen wir hier von read_committed-Schreibtransaktionen, nicht von schreibgeschützten).

An diesem Punkt hält die aktuell aktive Transaktion 2 (Snapshot oder Read Committed), die nach Snapshot 1 gestartet wurde (Markierung 3), die Snapshot-Nummer als Oldest Snapshot (wenn Sie mit IB 7.1/7.5 arbeiten, kann dies nur bei gleichzeitigen Snapshot-Transaktionen passieren. read_committed oder read_committed+snapshot erzeugen diesen Effekt nicht). Da es keine großen Rollbacks gab, bewegt sich die älteste Transaktion nach oben und wird größer als der Oldest Snapshot.

Wenn Sie nun eine lang laufende Read Committed-Transaktion haben, sehen Sie ein Bild wie dieses. Leider können Sie hier nichts an Ihren Anwendungen ändern (außer den Parameter „read“ für schreibgeschützte Transaktionen hinzuzufügen). Und natürlich läuft der Sweep in diesem Fall nicht automatisch (wenn er <> 0 gesetzt ist).

Hinweis: Dieses Verhalten wird in Firebird 2.0 behoben.

Absolute und relative Ansichten

Standardmäßig füllt IBAnalyst die Transaktionszeilen entsprechend dem Prozentsatz ihres absoluten Werts. D.h., 100% ist von 0 bis zur Next-Transaktion. Manchmal, wenn eine Datenbank lange läuft, können Sie die Transaktionsinformationen wie folgt sehen:

Während es viele Transaktionen gibt, sieht die Differenz zwischen Snapshot, Active und Oldest sehr klein aus (nahe 98%). Um die Situation klarer zu machen, öffnen Sie den Optionsdialog, die Registerkarte „Transaktionen“, und aktivieren Sie die Option „Relative (von ältester) Balken %“ (Sie können dieses Kontrollkästchen nicht setzen, wenn Sie die alte Ansicht ohne Diagrammbalken verwenden). Nach dem Klicken auf OK ändert sich die Transaktionsansicht zu

Jetzt sehen Sie die Transaktionsdifferenz in relativer Ansicht (100% bezieht sich auf die älteste (oder Snapshot-) Transaktion bis zur nächsten, nicht ab 0). Es ist einfacher, die aktuelle Situation zu verstehen und Warnungen (falls vorhanden) zu sehen.

Diese Ansicht bleibt erhalten, bis Sie sie im Optionsdialog deaktivieren. Sie können erkennen, welche Ansicht Sie sehen, anhand der Zeile “Älteste Transaktion” oder “Ältester Snapshot” - in der relativen Ansicht ist eine dieser Zeilen nie mit grüner Farbe gefüllt. In der absoluten Ansicht ist sie immer (natürlich teilweise) gefüllt.

Haben Sie noch Fragen? Fragen Sie uns unter [email protected]