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.

docnext count = 5

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.

Revisionshistorie

1.0

29. Okt. 2009

Neues gstat-Handbuch erstellt.

1.1

30. Nov. 2009

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

1.2

14. Dez. 2009

Ein paar kleinere Korrekturen und Rechtschreibfehler wurden korrigiert.

1.3

17. Feb. 2010

Formatierungsfehler in den Befehlszeilenschaltern wurden korrigiert.

1.4

23. Mär. 2011

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

Aktualisiert für Firebird 2.5.

Rechtschreibfehler korrigiert.

1.6

19. Jun. 2020

Konvertierung in AsciiDoc, geringfügige Bearbeitung von Texten

1.6-de

31. Jul. 2020

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.

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

Datensatz- Versionsdetails