<< Datenbankvalidierung (Datenbankzustand) | IBExpert | Datenbankeigenschaften >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation

Datenbankstatistik

Datenbankstatistiken bieten einen wertvollen Einblick in das Herz des Datenbankservers. Firebird/InterBase^® Statistiken sollten regelmäßig ausgewertet und aufbewahrt werden, denn wenn etwas nicht planmäßig funktioniert, ist es sehr hilfreich nachsehen zu können, wie die Datenbank aussah, als alles glatt lief. Schlechte oder abnehmende Datenbankleistung hängt fast immer mit schlechter Programmierung und/oder schlechter Transaktionshandling zusammen. Die IBExpert Datenbankstatistik holt und zeigt wichtige statistischen Informationen an, die in verschiedenen Dateiformaten exportiert und gedruckt werden kann. Dieser Menüpunkt befindet sich im IBExpert Systemdienste Menü.

Die Datenbankstatistiken helfen bei der Entdeckung und Aufhebung einer Vielfalt Leistungsprobleme, zum Beispiel, die Aufdeckung einer alten offenen Transaktion, die die Datenbankleistung wegen der Verwaltung einer immer großer werdenden Anzahl Rekordversionen verlangsamt. Ist die Datenseitenfülle effizient? Könnte sie durch die Aufteilung bestimmter großen Tabellen in mehrere kleinen verbessert werden? Oder verwenden Sie die Statistiken, um alle Indizes zu analysieren - löschen Sie die bad (schlechten) und useless (sinnlosen), vergleichen Sie die actual selectivity (verwendete Selektivität) mit der real selectivity (echter Selektivität). Und so weiter und so fort.

Support für Firebird 3.0 zusätzliche Tabellendaten wurde in IBExpert Version 2014.06.17 implementiert.

Um aktuelle Datenbankstatistiken für eine ganze Datenbank zu generieren, klicken Sie zuerst auf den Button oben links, um von einer Liste aller registrierten Datenbanken auszuwählen:

oder ziehen Sei einfach einen Datenbanknode oder einen oder mehrere ausgewählten Tabellennodes vom Datenbank Explorer auf die Datenbankstatistik Text-Seite:

um automatisch Statistiken für Ihre Auswahl zu generieren. Diese Methode kann auch über den Datenbank Explorer kontext-sensitiven Menüpunkt, Hole Statistiken für ausgewählte Tabelle(n)... ausgeführt werden.

Sie können aber auch eine bereits gespeicherte Statistikendatei öffnen, um die Statistiken zu analysieren.

Sie können bei Bedarf den Standardwert, Empfange alle Statistiken durch eine der folgenden Optionen ersetzen:

• Beende Empfang nach "Header Page" Statistik
• Beende Empfang nach "Log Pages" Statistik
• Beende Empfang nach Benutzerindex Statistik
• Beende Empfang nach Datentabellenstatistik
• Beende Empfang nach Systemtabellen- and Index Statistik

Aktivieren Sie gegebenfalls die Option, Analyse average record and version length (Durchschnittliche Rekord- und Versionslänge analysieren) (seit Firebird 1.5 und InterBase^® 7), die direkt unter der Symbolleiste zu finden ist. Dann klicken Sie auf das Statistik abfragen Symbol (grüner Pfeil) oder drücken Sie [F9], um die Statistikabfrage zu starten.

Die statistische Zusammenfassung wird sowohl als Text:

als auch tabellarisch (auf der Tabellen-Seite) angezeigt.

zurück zum Seitenanfang

Text

Die Textzusammenfassung bietet bestimmte Datenbankinformationen (siehe Abbildung oben) und auch eine statistische Zusammenfassung pro Tabelle (siehe Abbildung unten), die auch auf der Tabellen-Seite tabellarisch dargestellt werden.

Diese Zusammenfassung zeigt bestimmte Loginformation wie Timestamp, Seitengröße und ODS Version an. Dann werden die Oldest transaction (älteste Transaktion), Oldest active transaction (die älteste Transaktion, die bereits angefangen, aber weder committet noch zurückgerollt wurde), Oldest snapshot (diese zeigt wo die Garbage Collector seine Arbeit aufnehmen wird) und Next transaction (nächste Transaktion) angezeigt. Auf diese Statistiken sollten Sie ein Auge halten, da sie auf eine mögliche Ursache abnehmender Leistung hinweisen. Ein großer Unterschied zwischen der älteste aktive Transaktion (OAT) und der nächsten Transaktion deutet auf eine offene Transaktion irgendwo in der Datenbank hin (d.h. eine Transaktion, die angefangen aber noch nicht committet wurde). Solches Problem kann zum Verlangsamen der Datenbank führen, da der Server immer mehr und mehr offene Versionen verwalten muss, und die Garbage Collection ältere Versionen noch nicht löschen darf. Weitere Information zum Thema kann im Firebird administration using IBExpert Kapitel, Using the IBExpert Database Statistics nachgelesen werden.

Die Datenbankstatistiken zeigen folgende Informationen für alle Tabellen in der Datenbank an, sowohl als Protokollskript als auch tabellarisch: Table name (Tabellenname), Location (Speicherstelle), Pages (Seiten), Size (bytes) (Größe), Slots, Fill (%) (Fülle), DP usage (%) (Datenseitenverbrauch) and Fill distribution (Fülleverteilung) (eine optimale Seitenfülle ist circa 80%). Für jede Tabelle beinhalten die Indexstatistiken: Depth (Tiefe), Leaf buckets, Nodes (Knoten), Average data length (durchschnittle Datenlänge) and Fill distribution (Fülleverteilung).

Primary Pointer page: (Primäre Zeigerseite) In der Abbildung oben hat die primäre Zeigerseite der EMPLOYEE-Tabelle die Nummer 188. Es fängt beim Byte an, der die Seitennummer 188 gleicht, multipliziert mit der Seitengröße. Dies ist eine Art Inhaltsverzeichnis für die EMPLOYEE-Tabelle; es zeigt auf die Datenseiten, die die Tabellendaten enthalten.

Index root page: (Indexrootseite) Die gleiche Information wird für die Indexrootseiten (IRT) für Indizes in dieser Tabelle angezeigt.

Average record length: (Durchschnittliche Datensatzlänge) Hier wird die durchschnittliche Länge der Datensatz Versionen (in Bytes) angezeigt. Zum Beispiel, wenn eine dBase-Tabelle mit zwei Feldern je CHAR(100) erzeugt wird, ist die durchschnittliche Datesatzlänge immer 200. Firebird/InterBase^® speichert aber keine nebenstehenden Leerplatze. So wird, zum Beispiel, ein CHAR(100)-Feld mit einer Stringlänge von 65, gefolgt von 35 Leerplätzen,von Firebird/InterBase^® als einen String 65 plus 1 Leerplatz multipliziert mit 35. Deshalb sind importierte Daten in Firebird/InterBase^® manchmal kleiner als die ursprüngliche Datenquelle. (Siehe bitte den Datenbanktechnologie Artikel, The Firebird server and VARCHARs, für weitere Information.)

Total records: (Anzahl Datensätze) Die Anzahl Datensätze in den einzelnen Tabellen.

Average version length: (Durchschnittliche Versionslänge) Die durchschnittliche Länge der Datensatzversionen. Wenn Updates ausgeführt werden, können Sie hier sehen, wieviele Bytes - im Vergleich zum ursprünglichen Datensatz - durchschnittlich geändert wurden.

Total versions: (Anzahl Versionen) Wieviele Datensatzversionen für diese Tabelle vorhanden sind. Diese Zahl sollte immer so niedrig wie möglich gehalten werden, da sie auf die Anzahl Versionen, die Firebird/InterBase^® verwalten muss, hinweist.

Max versions: (Höchstanzahl Versionen) Die maximale Anzahl Versionen eines Datensatzes. Dies deutet auf den Datensatz hin, die diese Anzahl Versionen hat und die Firebird/InterBase^® verwalten muss, weil es immer noch eine aktive Transaktion irgendwo in der Datenbank befindet, was verhindert, dass alte Versionen gelöscht werden können.

Interessant hier ist, dass in diesem Fall Versionen nicht nur für die bearbeiteten Tabellen sondern für alle Tabellen aufrechterhalten werden. In Repeatable Read Mode wird, so bald eine Transaktion gestartet wird, einen Schnappschuss der gesamten Datenbank aufgenommen.

Data pages: (Datenseiten) Wieviele Datenseiten verwendet werden.

Average fill: (Durchschnittliche Fülle) Die Datenseitenfülle in %.

Fill distribution: (Fülleverteilung) Die durchschnittliche Fülle wird durch die bereits vorhandene Datenmenge auf den Datenseiten kalkuliert. Der Firebird/InterBase^® Server füllt in der Regel Seiten bis zu einem Maximum von 80%. Der freie Platz wird verwendet für die Aufbewahrung von Backversionen; wenn ein Update an einem dieser Datensätze auf dieser Seite ausgeführt wird, kann der neue Datensatz auf derselben Seite gespeichert werden. So müssen weniger Seiten geladen werden, müßte man zurück zum ursprünglichen Datensatz kehren.

Die Fülleverteilung gibt auch Hinweise, ob die Fülle für eine einzelne Tabelle eine Anomalie ist, oder ob ähnliche Probleme mit allen Tabellen auftauchen.

Es gibt bestimmte Situationen, wo Sie eventuell eine 100%-Fülle wünschen (z.B. wenn Sie eine Adressendatenbank auf einer CD speichern möchten). Diese können Sie mit der Use all space- Option beim Datenbank Restore verwirklichen.

zurück zum Seitenanfang

Tabellen

Die Tabellen wird alphabetisch nach Namen aufgelistet, aber - wie immer in IBExpert können sie nach allen angegebenen Kriterien durch Anklicken der entsprechenden Spaltenüberschrift bewegt oder sortiert werden. Spaltenüberschrifte können oben auf der Tabellen-Seite hingezogen werden, um die Daten nach dieser Spalte gruppiert, anzuzeigen.

Sie können bestimmte Aggregatfunktionen auf den einzelnen Spalten ausführen (siehe die Fülle %-Spalte in der Abbildung oben).

Das Tabellengitter bietet einige Information über die Fülle und Datenbanknutzung Ihrer Tabellen, z.B. Sie können schnell eine Tabelle mit tausenden von Seiten mit 50% Fülle aufdecken, was die Hälfte des Speicherplatzes verschwendet und die Cachebuffer doppel so schnell verbraucht. So was könnte auf eine Tabelle mit vielen Insert- und Deleteoperationen deuten, wobei der Platz schnell wieder gefüllt wird. Allerdings könnte die Ursache eine ungeeignete Seitengröße sein, z.B.mit einer Seitengröße von 4K oder 8K und Tabellen, die mit der Zeit immer neue Felder bekommen haben; wenn die Datensätze so groß sind, dass lediglich ein oder zwei Datensätze auf einer Seite passen, wird viel Platz verschwendet.

Vielleicht entdecken Sie eine Tabelle, die über n Datenseiten spannt, mit einer Gesamtgröße von x Bytes und mit y Datensätzen angezeigt wird, aber eine durchschnittliche Datensatzlänge von 0 hat. Die Versions-Spalten zeigen dieselbe Anzahl Datensätze mit einer durchschnittlichen Datensatzlänge von z Bytes. Diese Information zeigt, dass die Tabelle gelöscht wurde und keine Datensätze mehr hat, jedoch müssen die Datensatzversionen für alte offenen Transaktionen noch verwaltet werden

Unter dem Tabellengitter zeigt ein Indexgitter die Statistiken für alle Indizes für eine ausgewählte Tabelle. Folgende Information wird für Indizes angezeigt: Indexname, Fields, Unique (Eindeutig), Active, Sorting Order (Sortierreihenfolge), Statistics, Depth (Tiefe), Leaf Buckets, Knoten, Durchschnittliche Datenlänge, Total Dup (Anzahl Duplikate) und Fülleverteilung. Weitere Information finden Sie unter Indices.

Diese tabellarische Information kann exportiert werden (siehe Exportiere Daten) und als Datei gespeichert oder gedruckt werden.

Weitere Information über die Auswertung der Datenbankstatistiken, um die Datenbankleistung zu optimieren, finden Sie im Firebird Administration using IBExpert Kapitel, Using the IBExpert Database Statistics.

zurück zum Seitenanfang

Indizes

Neben der Zusammenfassung auf der Tabellen-Seite, bietet die Indizes-Seite die Möglichkeit, alle Datenbankindizes eingehend zu analysieren. Mit der Aufklappliste können Sie auswählen, welche Index-Typen Sie ansehen möchten:

• All indices (alle Indizes)
• Bad indices (schlechte Indizes)
• Useless indices (sinnlose Indizes)
• Too deep indices (zu tiefe Indizes)
• Active indices (aktive Indizes)
• Inactive indices (inaktive Indizes)
• Unique indices (eindeutige Indizes)
• Non-unique indices (nicht eindeutige Indizes)

Die Indizes werden nach Tabelle und Feld aufgelistet, aber - wie immer in IBExpert können sie nach allen angegebenen Kriterien durch Anklicken der entsprechenden Spaltenüberschrift bewegt oder sortiert werden. Spaltenüberschrifte können oben auf der Tabellen-Seite hingezogen werden, um die Daten nach dieser Spalte gruppiert, anzuzeigen. Sie können sofort den Indextyp erkennen:(Unique, Active, Ascending oder Descending).

Die Selectivity-Spalte zeigt die tatsächliche Selektivität an, die vom Firebird/InterBase^® Server bei der Abfragebearbeitung berücksichtigt wird. Die Real Selectivity-Spalte zeigt die Selektivität, die bei einer Neuberechnung der Indexselektivität erreicht werden könnte. Sollten Sie Abweichungen zwischen diesen beiden Spalten merken, klicken Sie auf dem Update selectivity (SET STATISTICS)-Button, um die Selektivität neu zu berechnen. Diese Abweichungen entstehen, weil die Selektivität nur bei der Erzeugung berechnet wird, oder beim Ausführen der IBExpert Selektivität aller Indizes erneut berechnen (im Statistiken-Dialog, im IBExpert Datenbank Menü, oder im Rechtsklick DB Explorer Menü. Alternativ kann man die Anweisung

 SET STATISTIC INDEX {INDEX_NAME} 

im SQL Editor verwenden, um einzelne Indizes neu zu berechnen.

Die Neuberechnung wird automatisch während eines Backup/Restores durchgeführt, da nicht der Index, sondern seine Definition gesichert und beim Restore wiederhergestellt wird.

Wenn der Optimierer eine Abfrage erhält, bereitet er als erstes die Ausführung vor. Er trifft Entscheidungen über Indizes basiert lediglich auf ihrer Selektivität. Der Firebird/InterBase^® Optimierer betrachtet Bad Indices als schlecht. Eine gute Selektivität hat einen Wert nah an der Null - die Selektivität ist das Ergebnis: 1/eindeutige Werte. Es kann mehrere Gründe geben, warum der Optimizer einen Index als schlecht betrachtet:

• Der Optimierer verwendet nur Indizes mit einer Selektivität < 0,01, wenn keine anderen geeigneten Indizes verfügbar sind.
• So ein Index verursacht in ältere Firebird und InterBase^® Versionen eine sehr langsame Garbage Collection. Dieses Problem ist seit InterBase^® 7.1/7.5 und Firebird 2.0 gelöst.
• Der Index verursacht beim Restore eine sehr langsame Wiederherstellungsprozess und er wird selbst nur sehr langsam wiederherstellt (CREATE/ALTER INDEX ACTIVE). Der Grund hierfür ist eine große Datensatznummerkette für einen einzelnen Indexschlüssel.
• Wenn der Index ein einer WHERE-Klausel verwendet wird, hängt die Speichernutzung vom gesuchten Wert ab (Bitmaskgröße). Da die Datensatzkette sehr groß sein kann (viele Schlüsselduplikate), wird der Speicherverbrauch auch sehr hoch sein.
• Wenn der Index in einem ORDER BY verwendet wird, und es gibt viele Duplikate - hauptsächlich im den unteren Schlüsselwerten (abhängig vom Sortierreihenfolge), wird es viele Indexseiten Lesevorgänge geben, die die Abfrage verlangsamen.

Der ungünstigste Fall für einen Index ist einen Unique-Wert von 1, d.h. alle Werte für eine indizierte Spalte sind gleich. Solche Indizes werden unter Useless aufgelistet. Es kann natürlich sein, dass es für Ihre Anwendung eine Situation gibt, wo so ein Index gut ist. Zum Beispiel, wenn Datensätze einen "Archiv"-Kennzeichen in einer Spalte haben und Ihre Anwendung sucht durch diese Spalte nach aktuellen und nicht nach archivierten Daten.

Normalerweise sollten schlechte und nutzlose Indizes geprüft werden und, wenn nicht absolut unentbehrlich für Ihre Anwendung (z.B. wenn Sie ihn nicht einsetzen, um Schüsseln mit weniger Duplikate als andere Schlüssel zu suchen), gelöscht werden. Allerdings wird das Löschen des Fremdschlüssels den entsprechenden Check Constraint deaktivieren, was eventuell nicht wünschenswert ist. Es ist möglich einen Fremdschlüssel durch Trigger zu ersetzen, jedoch gibt es einige Einschränkungen. Fremdschlüssel kontrollieren Datensatzbeziehungen mit dem Index, und der Index "sieht" alle Schlüssel für alle Datensätze unabhängig vom Transaktionsstatus. Ein Trigger arbeitet jedoch nur im Client Transaktionskontext. Wenn also Fremdschlüssel durch Trigger ersetzt werden, müssen Sie sicher sein, dass erstens, Datensätze nicht von der Mastertabelle oder in einem "Snapshot table reserving"-Modus gelöscht werden, und zweitens, dass die vom Primärschlüssel verwendete Spalte in der Mastertabelle nie modifiziert wird. Diese Einschränkung können Sie mit einem Before Update-Trigger erzwingen.

Wenn Sie diese Bedingungen einhalten, können Sie einen bestimmten Fremdschlüssel löschen.

Die nächste Spalte zeigt die Indextiefe an. Eine Indextiefe 2, zum Beispiel, bedeutet dass Firebird/InterBase^® 2 Schritte ausführen muss, um ein Ergebnis zu erzielen. Normalerweise soll dieser Wert nicht höher als drei sein. Sollte das der Fall sein, hilft meistens einen Datenbank Backup und Restore.

Leaf Buckets zeigen die Anzahl Registrierungsblätter, wo Firebird/InterBase^® sofort zugreifen kann. Weitere Statistiken beinhalten Nodes, Duplikate (Anzahl und Maximum) und Fülleverteilung.

zurück zum Seitenanfang

Options

Sie können auch eine automatische Analyse von Tabellen/Indizes mit Hervorhebung potentiell problematischer Tabellen/Indizes durchführen. Dieses Feature ist auf der IBEBlock Funktionalität basiert und ist daher völlig anpassbar.

Siehe auch:
deutschsprachig:
Index
englischsprachig:
Using the IBExpert Database Statistics
Multi-generational architecture (MGA) and record versioning
Firebird for the database expert: Episode 2 - Page types
Firebird for the database expert: Episode 4 - OAT, OIT and Sweep
Transaction
Transaction options explained

zurück zum Seitenanfang
<< Datenbankvalidierung (Datenbankzustand) | IBExpert | Datenbankeigenschaften >>