FirebirdSQL logo

Auswählen der zu analysierenden Tabellen

Wenn Sie anstelle aller Benutzertabellen eine bestimmte Liste von Tabellen in die Analyse aufnehmen möchten, können Sie mit dem Schalter -table die Tabellen angeben, die Sie einbeziehen möchten.Beachten Sie, dass durch die Angabe von Tabellennamen auf diese Weise auch alle diesen Tabellen zugeordneten Indizes analysiert werden.

gstat employee -t EMPLOYEE JOB COUNTRY >employee.gst

Die resultierende Ausgabe wird wie oben beschrieben interpretiert.

Wenn Sie einen Tabellennamen haben, der von einem Benutzer erstellt wurde, der die Groß- und Kleinschreibung des Tabellennamens beibehalten möchte, anstatt ihn in Großbuchstaben konvertieren zu lassen, zum Beispiel:

tux> isql myMusic
Database:  mymusic

SQL> CREATE TABLE "MyMusic_Artists" (
CON> art_id integer,
CON> art_name ....);

SQL> COMMIT;

... Dann müssen Sie die Tabellennamen in doppelten Anführungszeichen und in genau der gleichen Groß- und Kleinschreibung wie der Name der Tabelle in der Datenbank angeben:

gstat mymusic -t "MyMusic_Titles" "MyMusic_Artists" > MyMusic.gst

Wenn Sie einen nicht vorhandenen Tabellennamen angeben oder den Namen im falschen Fall usw. erhalten, ignoriert gstat ihn einfach.

Systemtabellen und -indizes einschließen

Bei der normalen Verwendung von gstat sind die Systemtabellen und -indizes nicht in der Ausgabe enthalten.Wenn Sie gstat mit dem Schalter -system aufrufen, werden diese Tabellen in die Analyse einbezogen.

gstat employee -system >employee.gst

Die Interpretation der Ergebnisse für die verschiedenen Systemtabellen und -indizes ist genau wie oben für Benutzertabellen und -indizes beschrieben.

docnext count = 7

Datensatz- & Versionsdetails

Wenn Sie gstat entweder mit den Standardschaltern oder -d[ata] oder -t[able] ausführen und den Schalter -r[record] hinzufügen, erhalten Sie zusätzliche Informationen im Bericht, in dem das angezeigt wird durchschnittliche Datensatzlänge und durchschnittliche Versionsdetails für die betreffende(n) Tabelle(n):

Average record length: 96.55, total records: 62372
    Average version length: 0.00, total versions: 0, max versions: 0
Average record length

Einfach die durchschnittliche Datensatzlänge aller Datensätze in der Tabelle in Byte.Wenn diese Zahl 0,00 beträgt, können Sie ziemlich sicher sein, dass alle Ihre Datensätze gelöscht wurden oder dass Sie keine Datensätze in der Tabelle haben.

Total records

Die Gesamtzahl der Datensätze in der Tabelle.Der Wert kann Datensätze in aktuell aktiven Transaktionen enthalten und Datensätze enthalten, die gelöscht wurden.

tux> # In session 1.
tux> gstat test -r -t NORMAN

...
Analyzing database pages ...
NORMAN (142)
    Primary pointer page: 268, Index root page: 269
    Average record length: 9.00, total records: 15
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1, data page slots: 1, average fill: 10%

tux> isql tset -user norman -password secret
Database:  employee

SQL> SELECT COUNT(*) FROM NORMAN;

       COUNT
============
          15

Zu diesem Zeitpunkt können wir sehen, dass die NORMAN-Tabelle 15 Datensätze enthält und dass die durchschnittliche Länge dieser 15 Datensätze 9,00 Byte beträgt.Als nächstes starten wir eine weitere isql-Sitzung und löschen alle Datensätze aus der NORMAN-Tabelle.

tux> # In session 2.
tux> isql test -user norman -password secret
Database:  employee

SQL> DELETE FROM NORMAN;
SQL> COMMIT;
SQL> shell;

Noch in der zweiten Sitzung führen wir gstat aus, um Statistiken für die NORMAN-Tabelle abzurufen. Die Ergebnisse sind unten gezeigt.

tux> gstat test -r -t NORMAN

...
Analyzing database pages ...
NORMAN (142)
    Primary pointer page: 268, Index root page: 269
    Average record length: 0.00, total records: 15
    Average version length: 9.00, total versions: 15, max versions: 1
    Data pages: 1, data page slots: 1, average fill: 16%
...

tux> # Return to isql.
tux> exit

Wenn wir den obigen Bericht mit dem Bericht vergleichen, der vor dem Löschen der Datensätze erstellt wurde, können wir sofort feststellen, dass:

  • Die durchschnittliche Datensatzlänge gibt an, dass die Tabelle keine Datensätze enthält, die Gesamtzahl der Datensätze zeigt jedoch, dass (noch) 15 vorhanden sind.Dies ist ein guter Indikator dafür, dass eine Sitzung alle Datensätze gelöscht hat, die Speicherbereinigung jedoch noch nicht ausgeführt wurde.

  • Die Versionsdetails haben sich alle geändert. Es gibt jetzt Statistiken zur durchschnittlichen Versionslänge, Gesamtversionen und Maximalversionen.

  • Die durchschnittliche Füllung für die Seite(n) in dieser Tabelle ist von 10% auf 16% gestiegen, obwohl alles gelöscht wurde.Der zusätzliche Speicherplatz wird von den früheren Versionen der gelöschten Datensätze verwendet.

Wenn wir in der zweiten Sitzung fortfahren und einen vollständigen Tabellenscan der NORMAN-Tabelle ausführen, werden keine Ergebnisse angezeigt, aber die Back-Versionen werden im Müll gesammelt.

SQL> SELECT * FROM NORMAN;

SQL> shell;

tux> gstat test -r -t NORMAN

...
Analyzing database pages ...
NORMAN (142)
    Primary pointer page: 268, Index root page: 269
    Average record length: 0.00, total records: 0
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 0, data page slots: 0, average fill: 0%

Alles ist jetzt auf Null zurückgekehrt.Es gibt keine früheren Versionen, keine aktuellen Versionen und die Seite ist nicht mehr gefüllt.

Average version length

Dies ähnelt der durchschnittlichen Datensatzlänge, gilt jedoch für die früheren Versionen des Datensatzes.Wenn Sie beispielsweise eine Reihe von Datensätzen gelöscht und andere aktualisiert haben, werden die alten — früheren — Versionen dieser Datensätze hier gemeldet.Wenn die Zahl 0,00 ist, hat die Speicherbereinigung stattgefunden und die früheren Versionen entfernt — siehe oben für ein Beispiel.

Total versions

Entspricht den oben genannten Gesamtdatensätzen, enthält jedoch nur die früheren Versionen.Wenn die Zahl 0 ist, hat die Speicherbereinigung stattgefunden und die früheren Versionen entfernt — siehe oben für ein Beispiel.

Max versions

Wenn ein Datensatz mehrmals aktualisiert wurde, zeigt die Statistik der maximalen Versionen die Anzahl der früheren Versionen des betreffenden Datensatzes (oder der betreffenden Datensätze) an.In einer Tabelle, in der alle Zeilen siebenmal aktualisiert wurden, eine jedoch 20mal aktualisiert wurde, gibt diese Statistik den Wert 20 aus.Wenn die Zahl 0,00 ist, hat die Speicherbereinigung stattgefunden und die früheren Versionen entfernt — siehe oben für ein Beispiel.

Wenn Sie eine beschädigte Datenbank haben

Im unwahrscheinlichen Fall einer Datenbankbeschädigung kann Ihre gstat -Ausgabe im Bericht Folgendes enthalten:

Database file sequence:
File /opt/firebird/examples/empbuild/corrupt.fdb is the only file

Analyzing database pages ...
    Expected b-tree bucket on page 337334 from 146314

Wenn Sie jemals eine Meldung wie die oben genannte sehen, die direkt nach den Header-Informationen angezeigt wird, sollten Sie sofort alle Verbindungen zur Datenbank beenden, eine Kopie der Datenbankdatei(en) auf Betriebssystemebene erstellen und versuchen, gbak auszuführen `gegen die Datenbank, um eine vollständige Sicherung zu erstellen.Die Verwendung von `nbackup kopiert die Datenbank möglicherweise problemlos, meldet jedoch keine Fehler.gbak hingegen meldet Fehler.

gstat-Fallstricke

Das Folgende ist eine kurze Liste von Fallstricken und Funnies, die ich bei meiner eigenen Verwendung von gstat entdeckt habe.Einige davon sind oben erwähnt, andere möglicherweise nicht.Wenn Sie sie alle hier an einem Ort sammeln, sollten Sie herausfinden können, was passiert, wenn Sie Probleme haben.

Der Schalter -t[able] kann Probleme machen

Der Schalter -t[able] erwartet, dass eine Liste von Tabellennamen (in Großbuchstaben) angegeben wird.Wenn Sie den Datenbanknamen nach einem Tabellennamen angeben, wird dieser leider als Tabellenname angenommen und Sie werden zur Eingabe eines Datenbanknamens aufgefordert.

tux> gstat -t EMPLOYEE JOB employee
please retry, giving a database name

Rufen Sie aus diesem Grund immer gstat mit dem Datenbanknamen als ersten Parameter auf:

tux> gstat employee -t EMPLOYEE JOB

Database "/opt/firebird/examples/empbuild/employee.fdb"
Database header page information:
...

Database file sequence:
File /opt/firebird/examples/empbuild/employee.fdb is the only file

Analyzing database pages ...
...

Alternativ können Sie einen zusätzlichen Schalter nach dem letzten Tabellennamen und vor dem Datenbanknamen angeben:

tux> gstat -t EMPLOYEE JOB -z employee
gstat version LI-V2.1.3.18185 Firebird 2.1

Database "/opt/firebird/examples/empbuild/employee.fdb"
Database header page information:
...

Database file sequence:
File /opt/firebird/examples/empbuild/employee.fdb is the only file
        Firebird/linux Intel (access method), version
"LI-V2.1.3.18185 Firebird 2.1"
        Firebird/linux Intel (remote server), version
"LI-V2.1.3.18185 Firebird 2.1/tcp (greenbird)/P11"
        Firebird/linux Intel (remote interface), version
"LI-V2.1.3.18185 Firebird 2.1/tcp (greenbird)/P11"
        on disk structure version 11.1

Analyzing database pages ...

Die Schattenzahl scheint falsch zu sein

Es scheint, dass das Hinzufügen und/oder Löschen von Schattendateien aus einer Datenbank nicht immer von gstat gemeldet wird, wenn ein Datenbankbericht erstellt wird.

tux> # Use gstat to display shadow details
tux> gstat employee -h|grep -i sh[a]dow
        Shadow count            0

tux> isql employee
Database: employee

SQL> SHOW DATABASE;
Database: employee
        Owner: SYSDBA
 Shadow 1: "/u00/firebird/databases/employee.shd1" auto
...

Es ist sofort offensichtlich, dass der Bericht von gstat falsch ist, da die Mitarbeiterdatenbank eine Schattendatei enthält.Wenn wir isql verwenden, um dieser Datenbank eine neue Schattendatei hinzuzufügen, wie unten gezeigt, besteht gstat weiterhin darauf, dass keine Schatten vorhanden sind.

SQL> CREATE SHADOW 7 AUTO '/u00/firebird/databases/employee.shd7';

SQL> SHOW DATABASE;
Database: employee
        Owner: SYSDBA
 Shadow 1: "/u00/firebird/databases/employee.shd1" auto
 Shadow 7: "/u00/firebird/databases/employee.shd7" auto
...

SQL> shell;

tux> gstat employee -h | grep -i sh[a]dow
        Shadow count            0

Dokumentenhistorie

Der genaue Dateiversionsverlauf wird im Firebird-Dokumentations-Git-Repository aufgezeichnet; siehe https://github.com/FirebirdSQL/firebird-documentation

Revisionshistorie

1.0

29. Okt. 2009

ND

Neues gstat-Handbuch erstellt.

1.1

30. Nov. 2009

ND

Viele von Paul Vinkenhoog vorgeschlagene Korrekturen sowie eine allgemeine Aufräumaktion und einige weitere Beispiele wurden hinzugefügt.

1.2

14. Dez. 2009

ND

Ein paar kleinere Korrekturen und Rechtschreibfehler wurden korrigiert.

1.3

17. Feb. 2010

ND

Formatierungsfehler in den Befehlszeilenschaltern wurden korrigiert.

1.4

23. Mär. 2011

ND

ODS 9.1 für Interbase 5.0 wurde zur Liste der bekannten ODS-Werte hinzugefügt.

Verweis auf Verwalten von Limbo-Transaktionen im gfix-Handbuch hinzugefügt.

Korrigierte Erklärung, wann ein automatischer Datenbank-Sweep durchgeführt wird, basierend auf OIT und OST im Gegensatz zu OIT und OAT.Wie von Vlad Khorsun empfohlen.

1.5

11.Okt. 2011

ND

Aktualisiert für Firebird 2.5.

Rechtschreibfehler korrigiert.

1.6

19. Jun. 2020

MR

Konvertierung in AsciiDoc, geringfügige Bearbeitung von Texten

1.6-de

31. Jul. 2020

MK

Deutsche Übersetzung.

Lizenzhinweis

Der Inhalt dieser Dokumentation unterliegt der "Public Documentation License Version 1.0" (der “License”);die Dokumentation darf nur unter Respektierung dieser Lizenz genutzt werden.Kopien der Lizenz sind verfügbar unter https://www.firebirdsql.org/pdfmanual/pdl.pdf (PDF) und https://www.firebirdsql.org/manual/pdl.html (HTML).

Die Original-Dokumentation trägt den Titel Firebird Database Statistics Reporting Tool.

Der ursprüngliche Autor der Original-Dokumentation ist: Norman Dunbar.

Copyright © 2005-2020.Alle Rechte vorbehalten.Kontakt zum Original-Autor: NormanDunbar at users dot sourceforge dot net.

Mitwirkende: Norman Dunbar; Mark Rotteveel; Martin Köditz - siehe Dokumenthistorie.