IBAnalyst: So erhalten Sie Statistiken aus einer InterBase/Firebird-Datenbank auf die richtige Weise

Dmitry Kuzmenko, letzte Aktualisierung 31-03-2014

Zusammenfassung

Dieses Dokument widmet sich Tipps und Tricks zum Sammeln und Analysieren von Statistiken aus InterBase/Firebird-Datenbanken, mit oder ohne IBAnalyst.

Der richtige Zeitpunkt, der richtige Ort

Es klingt seltsam, aber das bloße Erfassen von Statistiken über gstat oder die Services-API reicht nicht aus. Statistiken müssen zum richtigen Zeitpunkt erfasst werden, um zu zeigen, wie Anwendungen Daten und Transaktionen in der Datenbank beeinflussen. Der schlechteste Zeitpunkt für Statistiken ist

• Direkt nach einer Wiederherstellung
• Nach einem Backup (gbak -b db.gdb) ohne den Schalter -g
• Nach einem manuellen Sweep (gfix -sweep)

Es ist auch richtig, dass es während der Arbeit Momente geben kann, in denen sich die Datenbank in einem korrekten Zustand befindet, zum Beispiel wenn Anwendungen weniger Datenbanklast erzeugen als üblich (Benutzer beim Start, Mittagspause oder durch spezifische Geschäftsprozesszeiten).

Wie erkennt man, wann etwas mit der Datenbank nicht stimmt?

Ja, Ihre Anwendungen können so perfekt entworfen sein, dass sie immer korrekt mit Transaktionen und Daten arbeiten, keine Sweep-Lücken, viele aktive Transaktionen, lang laufende Snapshots usw. verursachen. Normalerweise passiert das nicht. Zumindest, weil einige Entwickler ihre Anwendungen nur mit 2-3 gleichzeitigen Benutzern testen, nicht mehr. Wenn sie die geschriebenen Anwendungen also für 15 und mehr gleichzeitige Benutzer einrichten, kann sich die Datenbank unvorhersehbar verhalten. Natürlich kann der Mehrbenutzermodus funktionieren, weil die meisten Mehrbenutzerkonflikte mit 2-3 gleichzeitig laufenden Anwendungen getestet werden können. Aber wenn dann mehr gleichzeitige Anwendungen laufen, können Probleme mit der Garbage Collection auftreten (zumindest). Und das kann erkannt werden, wenn Sie Statistiken zu den richtigen Zeitpunkten erfassen.

Wenn Sie keine periodischen Leistungsprobleme haben

Dies kann passieren, wenn Ihre Anwendungen korrekt entworfen sind, die Datenbanklast gering ist oder Ihre Hardware modern und sehr leistungsfähig ist (ausreichend, um die aktuelle Benutzeranzahl und Daten gut zu bewältigen).

Die wertvollsten Informationen sind Transaktionslast und Versionsansammlung. Dies kann nur gesehen werden, wenn Sie regelmäßiges Speichern von Statistiken einrichten.

InterBase hat keinen internen Aufgabenplaner, daher können Sie jeden externen verwenden, wie den Standard-Aufgabenplaner (Windows) oder cron (Unix).

Die beste Einrichtung ist, stündliche Transaktionsstatistiken zu erfassen. Dies kann durch Ausführen von

gstat -h db.gdb >db_stat_.txt

erreicht werden, wobei

db.gdb Ihr Datenbankname ist,

db_stat_.txt die Textdatei ist, in der die Statistiken gespeichert werden,

_ das aktuelle Datum und die Uhrzeit, zu der die Statistiken erfasst wurden.

Wenn Sie periodische Leistungsprobleme haben

Diese Probleme werden normalerweise durch den automatischen Sweep-Lauf verursacht. Zuerst müssen Sie den Zeitraum zwischen solchen Leistungseinbrüchen bestimmen. Teilen Sie dann dieses Intervall minimal durch 4 (8, 16 usw.). Informationssysteme haben jetzt viele gleichzeitige Benutzer, und die meisten Leistungsprobleme mit nicht konfiguriertem Server und Datenbank treten 2 oder 3 Mal pro Tag auf. Wenn Leistungseinbrüche zum Beispiel alle 3 Stunden auftreten, müssen Sie

gstat -h db.gdb

Statistiken alle 30-45 Minuten erfassen, und

gstat -a -r db.gdb -user SYSDBA -pass masterkey

alle 1-1,5 Stunden.

Am besten ist es, wenn Sie gstat -a -r Statistiken direkt vor dem bevorstehenden Leistungseinbruch erfassen. Es zeigt, wo sich echter Müll befindet und wie viele veraltete Datensatzversionen angesammelt wurden.

Was mit diesen Statistiken zu tun ist

Wenn Ihre Anwendung explizit Transaktionen verwendet und sie gut nutzt, d.h. Sie wissen, was read_committed ist und wann es zu verwenden ist, Ihre Snapshot-Transaktionen nicht länger als nötig dauern und Transaktionen nur minimal aktiv sind, können Sie das Sweep-Intervall abstimmen oder es deaktivieren und sich dann nur darum kümmern, wie viele Updates die Anwendung(en) durchführen und welche Tabellen weniger aktualisiert oder gepflegt werden müssen.

Was bedeutet das, könnten Sie fragen? Wir geben ein Beispiel für ein System, bei dem Leistungsprobleme jeden Morgen für 20-30 Minuten auftraten. Das war sehr ausreichend für “morgendliche” Anwendungen und konnte nicht länger dauern.

Der Datenbankadministrator wurde mit den richtigen Fragen konfrontiert, und hier ist das Bild:

Die tägliche Arbeit war in Abschnitte unterteilt - Analysten arbeiten am Morgen, dann werden Daten von normalen Operatoren eingefügt und bearbeitet, und am Ende des Tages starteten spezielle Prozeduren, um Daten zu sammeln, die am nächsten Tag (zumindest) für die Analyse verwendet würden.

Die letzte Arbeit an der Datenbank am Ende des Tages bestand aus vielen Updates, und Updates der Tabellen, die Analysten am Morgen verwendeten. Es gab also viele Garbage-Versionen, die von der am Morgen laufenden Anwendung gesammelt wurden.

Und die Antwort auf dieses Problem war einfach - gfix -sweep am Ende des Tages auszuführen.

Sweep liest alle Tabellen in der Datenbank und versucht, alle Garbage-Versionen für festgeschriebene und zurückgerollte Transaktionen zu sammeln. Nach dem Sweep wurde die Datenbank fast so klar wie nach einer Wiederherstellung.

Und das “Morgenproblem” war verschwunden.

Sie müssen also Statistiken mit vielen anderen Faktoren berücksichtigen:

1. Wie viele gleichzeitige Benutzer (durchschnittlich) während des Tages arbeiten

2. Wie lang der Arbeitstag ist (8, 12, 16, 24 Stunden)

3. Welche Art von Anwendungen zu verschiedenen Tageszeiten laufen und wie sie Daten beeinflussen, die von anderen Anwendungen verwendet werden, die gleichzeitig oder danach laufen. D.h. Sie müssen die Geschäftsprozesse verstehen, die den ganzen Tag und die ganze Woche über stattfinden.

Wenn der DBA nichts tun kann

Leider müssen wir sagen, dass diese Situationen vorkommen. Und wieder ein Beispiel:

Ein System wurde für ~15 Benutzer installiert. Periodisch ist die Leistung so schlecht, dass der DBA den Server neu starten muss. Nach dem Serverneustart funktioniert alles für einige Zeit gut, dann wird die Leistung wieder schlecht. Statistiken zeigten, dass die durchschnittliche tägliche Transaktionsanzahl etwa 75.000 beträgt und es aktive Transaktionen gibt, die vom Beginn des Tages bis zum Moment des Leistungsabfalls laufen.

Leider wurden die Anwendungen mit BDE und ohne jegliche Transaktionsnutzung geschrieben; d.h. die gesamte Transaktionsverwaltung war automatisch und wurde von BDE selbst übernommen. Dies führte dazu, dass einige Transaktionen lange aktiv blieben und sich Garbage (Datensatzversionen) ansammelte, bis der DBA den Server neu startete. Nach dem Neustart lief der automatische Sweep, und der Garbage wurde gesammelt (eliminiert).

All dies wurde durch die Anwendungen verursacht, weil sie nur mit 2-3 gleichzeitigen Benutzern getestet wurden, und als es ~15 wurden, begannen die Anwendungen, eine sehr hohe Last zu erzeugen.

Es muss gesagt werden, dass in dieser Konfiguration 70% der Benutzer nur Daten lasen und die anderen 30% einige (!) Daten einfügten und aktualisierten.

In dieser Situation ist das Einzige, was die Leistung verbessern kann, die Anwendungen vollständig neu zu entwerfen.

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