Analysieren der gesamten Datenbank

Die Analyse der gesamten Datenbank ist die Standardeinstellung für gstat.Bei Verwendung werden alle Benutzertabellen und -indizes analysiert und die gesammelten Statistiken gemeldet.Da die Ausgabe höchstwahrscheinlich sehr groß sein wird, ist es ratsam, die Ausgabe in eine Datei zu leiten:

gstat employee >employee.gst

Die Ausgabe besteht aus einer Analyse jeder Benutzertabelle und aller zugehörigen Benutzerindizes.Die Interpretation dieser Ergebnisse wird nachstehend in den Abschnitten zur Analyse von Daten und Indexseiten behandelt.

Nur Datenseiten analysieren

Der Befehl, nur Benutzertabellen in der Datenbank zu analysieren, lautet:

gstat employee -data >employee.gst

Die mit diesem Befehl ausgegebenen Ergebnisse listen die Benutzertabellen in alphabetischer Reihenfolge auf.Es werden keine Indizes analysiert oder aufgelistet, unabhängig davon, wie viele in der Datenbank vorhanden sind.

Sobald der Bericht fertiggestellt ist, können die Ergebnisse wie folgt analysiert werden, wobei insbesondere eine Tabelle betrachtet wird.

CONFIGREVISIONSTORE (213)
    Primary pointer page: 572, Index root page: 573
    Data pages: 2122, data page slots: 2122, average fill: 82%
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 79
        80 - 99% = 2042

Der obige Auszug aus dem Bericht beginnt mit der Anzeige des Tabellennamens — CONFIGREVISIONSTORE — und der Tabellen-ID — 213.Die ID der Tabelle ist tatsächlich die Spalte RDB$RELATION_ID in der Systemtabelle RDB$RELATIONS, wie die folgende isql-Sitzung zeigt:

SQL> select rdb$relation_name
CON> from rdb$relations
CON> where rdb$relation_id = 213;

RDB$RELATION_NAME
===================================
CONFIGREVISIONSTORE

Primary pointer page: Dies ist die Seitenzahl innerhalb der Datenbank der ersten Seite mit Zeigern auf die Datenseiten dieser Tabelle.Die Struktur der Datenbank ist so, dass jede Tabelle exklusive Datenseiten enthält und eine Liste dieser Seiten irgendwo aufbewahrt werden muss.Diese Statistik gibt Ihnen die Seitenzahl für diesen Ort.
Index root page: Dies ist die Seitenzahl, auf der sich die erste Seite mit Zeigern auf die Tabellenindizes in der Datenbank befindet.Jede Tabelle in der Datenbank hat eine Seite, die Indexstammseite, die Zeiger auf die Apex-Seiten für jeden einzelnen Index enthält.
Data pages: Die Gesamtzahl der dieser Tabelle zugewiesenen Seiten.Da gstat keine transaktionsbezogene Verbindung zur Datenbank herstellt, kann es nicht feststellen, ob es sich bei einer dieser Seiten um alte Datensatzversionen (Garbage) oder um gelöschte Datensätze in derzeit nicht festgeschriebenen Transaktionen handelt. Daher ist die Anzahl möglicherweise höher als erforderlich da diese zusätzlichen Seiten in der Gesamtsumme enthalten sind.
Data page slots: Dieser Wert sollte der Anzahl der Datenseiten entsprechen.Es gibt die Anzahl der Zeiger auf Seiten in dieser Tabelle an, die auf verschiedenen Zeigerseiten innerhalb der Datenbank gespeichert sind.Wenn sich die Zahlen unterscheiden, kann dies an dem Müll liegen, der nicht gesammelt wird.
Average fill: Der berechnete Speicherplatz, der durchschnittlich auf jeder Seite der Tabelle verwendet wird.Die Abbildung enthält Speicherplatz, der von früheren Versionen von Datensätzen in der Tabelle verwendet wird.Die Füllverteilung (unten) enthält weitere Details.
Fill distribution: In diesem Abschnitt des Berichts wird ein 5-Band-Histogramm angezeigt, in dem jedes Band 20% des auf jeder Seite ausgefüllten Speicherplatzes darstellt.Im obigen Beispiel sehen wir, dass diese Tabelle eine einzelne Seite enthält, die zu weniger als 20% gefüllt ist. 79 Seiten sind zu 60% bis 79% gefüllt, während die überwiegende Mehrheit, 2042, zu 80% bis 99% gefüllt ist.

docnext count = 10

Nur Indexseiten analysieren

Der Befehl, nur Benutzerindizes in der Datenbank zu analysieren, lautet:

gstat employee -index >employee.gst

Die mit diesem Befehl ausgegebenen Ergebnisse listen die Benutzertabellen in alphabetischer Reihenfolge auf.Es werden keine Tabellen analysiert.Der Bericht listet jedoch die Tabellennamen in alphabetischer Reihenfolge auf und listet alle anwendbaren Indizes unter dem entsprechenden Tabellennamen auf.

Nach Abschluss der Analyse können die Ergebnisse wie folgt interpretiert werden.Das folgende Beispiel zeigt die Ausgabe eines einzelnen Index in einer Datenbank.

CONFIGREVISIONSTORE (213)
    Index PK_CONFIGREVISIONSTORE (0)
        Depth: 3, leaf buckets: 174, nodes: 62372
        Average data length: 2.58, total dup: 0, max dup: 0
        Fill distribution:
             0 - 19% = 15
            20 - 39% = 0
            40 - 59% = 55
            60 - 79% = 68
            80 - 99% = 36

Der obige Auszug aus dem Bericht beginnt mit der Anzeige des Tabellennamens — CONFIGREVISIONSTORE — und der Tabellen-ID — 213 wie oben beschrieben.

Nach den Details der Tabelle — und nur der Name und die ID werden angezeigt — werden die Indexdetails angezeigt.Wie oben werden der Indexname und seine ID angezeigt.Dieses Mal bezieht sich die ID auf die Position des Index in der Liste aller in der Tabelle erstellten Indizes.ID Null ist der erste erstellte Index, ID 1 ist der nächste und so weiter.Die Ausgabe von gstat listet die Indizes möglicherweise nicht in der ID-Reihenfolge auf. Wenn Indizes erstellt, aber anschließend gelöscht wurden, kann es zu Lücken in der ID-Sequenz kommen.

In den nächsten beiden Zeilen nach dem Indexnamen und der ID werden die Gesamtstatistiken für diesen Index angezeigt.

Depth

Diese Statistik zeigt die Anzahl der Seiten an, auf die zugegriffen werden muss, um zu einem Indexeintrag zu gelangen.In diesem Beispiel müssen wir drei separate Seiten in den Puffercache lesen, bevor wir die Indexdetails verwenden können, um auf die gewünschte Zeile in der Tabelle zuzugreifen.Dies wird häufig als Index-Indirektion bezeichnet.

Depth: 3

Auf der Festplatte befindet sich eine Index-Stammseite (Root Page) der obersten Ebene, die gleichzeitig mit der Datenbank erstellt wird.Diese Seite enthält eine Liste von Zeigern auf die obere Seite (Apex) für jeden Index — eine Seite pro Index.Für jeden Index enthält diese Seite eine Liste mit Zeigern auf Folgendes:

Apex-Seiten einer anderen Ebene, wenn die Tiefe größer als 1 ist, oder,
zu den Blattseiten (Leaf Pages) für die tatsächlichen Indexdaten, wenn Tiefe = 1.

Auf den Blattseiten wird der Speicherort der indizierten Daten gespeichert.Die Indextiefe ist die Anzahl der Ebenen, die Sie von der Apex-Seite des Index herabsteigen müssen, um zu den Blattseiten zu gelangen.Weder die Indexstammseite noch die Apex-Seite des Index werden in der Tiefe gezählt.

Im Durchschnitt zeigt eine Tiefe von 2 oder weniger einen Index an, der effizient ist.Wenn die Tiefe 3 oder mehr beträgt, funktioniert der Index höchstwahrscheinlich nicht optimal.Die Lösung in dieser Situation besteht darin, gbak zu verwenden, um die Größe der Datenbankseite zu erhöhen, indem eine Sicherung erstellt und wie folgt wiederhergestellt wird:

tux> # Datenbank herunterfahren
tux> gfix -shut -tran 60 employee

tux> # Datenbank sichern
tux> gbak -backup employee /backups/employee.fbk

tux> # Aktuelle Seitengröße ermitteln
tux> gstat employee -header | grep -i "page size"
     page size             4096

tux> # Datenbank mit einer größeren Seitengröße wiederherstellen
tux> gbak -replace overwrite -page 8192 /backups/employee.fbk employee

tux> # Neue Seitengröße prüfen
tux gstat employee -header | grep -i "page size"
     page size             8192

tux> # Datenbank hochfahren
tux> gfix -online normal employee

Sobald dies ausgeführt wurde, sollten Sie feststellen, dass die Tiefe des Index 2 oder weniger beträgt.Ist dies nicht der Fall, wiederholen Sie einfach den obigen Vorgang mit einer noch größeren Seitengröße.

Warning

Der obige Befehl zum Wiederherstellen der Sicherung überschreibt die ursprüngliche Datenbankdatei.Dies funktioniert, indem die Originaldatei gelöscht und neu erstellt wird. Sie müssen also wirklich sicherstellen, dass Ihre Datenbanksicherung tatsächlich funktioniert und dass die erstellte Sicherungsdatei verwendet werden kann, bevor Sie versuchen, eine Datenbank zu überschreiben.Weitere Informationen finden Sie im gbak-Handbuch.

Leaf buckets

Diese Statistik informiert uns über die Anzahl der Blattseiten, die dieser bestimmte Index verwendet.Eine Seite und ein Bucket sind synonym, aber Seite ist der modernere Begriff, der häufig verwendet wird.

leaf buckets: 174

In unserem Beispielindex sehen wir, dass die Datenbank 174 Seiten enthält, die die Details der indizierten Werte für diese Tabelle enthalten. Alle diese Seiten enthalten Zeiger auf die Daten.

Die Anzahl der Blattseiten sollte mit der Summe der Gesamtzahl der Seiten in jeder Histogrammleiste in der unten gezeigten Füllverteilung übereinstimmen.

Nodes

Dies ist die Gesamtzahl der Datensätze in der Tabelle, die indiziert wurden.Es ist jedoch möglich — da gstat nicht transaktionsbewusst funktioniert --, dass diese Zahl möglicherweise Zeilen enthält, die gelöscht (und nicht durch Müll gesammelt) wurden und / oder Datensätze mehr als zählen einmal, wenn sie so geändert wurden, dass die indizierten Spalten geändert wurden.

nodes: 62372

Aus den oben genannten Gründen ist es ratsam, vor dem Ausführen von gstat einen Sweep oder eine Datenbanksicherung und -wiederherstellung durchzuführen, um sicherzustellen, dass die gesammelten Statistiken korrekt sind und die wahre Position der Datenbank widerspiegeln.

Average data length

Diese Statistik gibt die durchschnittliche Länge der Schlüsselspalte(n) in Bytes an.

Average data length: 2.58

+Dies ist höchstwahrscheinlich weniger als die tatsächliche Summe der Spaltengrößen, da Firebird die Indexkomprimierung verwendet, um die Datenmenge auf einer Indexblattseite zu reduzieren.

Duplicates

Duplikate sind in einem Primärschlüssel oder einem eindeutigen Index nicht zulässig.Andere Indizes erlauben Duplikate, und diese Statistiken geben Auskunft über die Anzahl der Duplikate, die der Index enthält.Die folgende isql-Abfrage zeigt die Details von Duplikaten für eine indizierte Spalte in einer anderen Tabelle als der bisher verwendeten — die keine Duplikate enthält.

SQL> SELECT IDX, COUNT(*)
CON> FROM NORMAN_TEST
CON> GROUP BY IDX;

         IDX        COUNT
============ ============
           1           10
           2            4
           3            1

Von oben sehen wir insgesamt 15 Zeilen, von denen es 14 doppelte Werte gibt (alle mit einer 1 oder 2 in der IDX-Spalte). Das Folgende ist der Auszug für die Duplikate für diese Tabelle:

Index NORMANX (0)
        Depth: 1, leaf buckets: 1, nodes: 15
        Average data length: 0.27, total dup: 12, max dup: 9

Total dup ist die Gesamtzahl der Duplikate im Index.Beachten Sie, dass nur 12 Duplikate aufgelistet sind, wir jedoch bereits wissen, dass der Index 14 Duplikatzeilen enthält.Wie ist das möglich?

Das erste Auftreten einer 1 und das erste Auftreten einer 2 werden von gstat nicht als Duplikate gezählt.Nur die zweite und die nachfolgenden Kopien gelten als Duplikate.

Note	Meiner Meinung nach ist dies kein ganz korrektes Verhalten.In der obigen Tabelle gibt es 15 Zeilen und nur drei eindeutige Werte in der IDX-Spalte, die indiziert ist.Mein Index enthält daher 14 doppelte Werte und nicht nur 12.

Sie können jedoch den Gesamt-Dup-Wert verwenden, um die Anzahl der eindeutigen Werte im Index zu extrahieren, indem Sie sie vom Knotenwert subtrahieren.

Max dup gibt die Anzahl der Indexeinträge an, die die längste Kette von Duplikaten gemeinsam haben.Mit anderen Worten — für den obigen Index — gibt es 9 Indexeinträge, die den gleichen Wert in der indizierten Spalte haben.Wir können sehen, dass dies wahr ist, da die Zeilen, in denen IDX 1 ist, 9 doppelte Einträge haben.

Wenn sich max dup dem Gesamtdup nähert, ist es eine vernünftige Annahme, dass der Index möglicherweise eine so geringe Selektivität aufweist, dass er möglicherweise nie in Abfragen verwendet wird.

Fill distribution

Der Rest des Berichts für unseren ursprünglichen Beispielindex zeigt, wie die Seiten im Index verwendet werden.

Fill distribution:
             0 - 19% = 15
            20 - 39% = 0
            40 - 59% = 55
            60 - 79% = 68
            80 - 99% = 36

Die Abbildungen stellen eine Grafik (oder ein Histogramm) dar, wie der Platz auf den Indexseiten genutzt wird.Jeder Wert des Histogramms repräsentiert die Anzahl der Seiten im gesamten Index, die bis zu einem bestimmten Prozentsatz gefüllt wurden.Jeder Balken des Histogramms repräsentiert den Prozentsatz, der für die Seite gefüllt ist.

Die Füllverteilung des Beispielindex ist oben dargestellt. Aus diesen Zahlen geht hervor, dass die überwiegende Mehrheit der Seiten zu 40 bis 99% gefüllt ist. Die einzelnen Zahlen am Ende jeder Zeile oben geben die Anzahl der Seiten in diesem Band an.Das Beispiel zeigt Folgendes:

15 pages have been filled to less than 20%; and
0 pages have been filled to between 20% and 39%; and
55 pages have been filled to between 40% and 59%; and
68 pages have been filled to between 60% and 79%; and
36 pages are filled to between 80% and 99%.

Die Summe aller dieser Seiten sollte sich zu der oben für Blattknoten gezeigten Zahl addieren.

Dieser Index zeigt eine recht gute Speicherplatznutzung, da die meisten Seiten gut gefüllt sind.Idealerweise möchten Sie, dass alle Seiten zu 80 bis 99% gefüllt sind. Wenn der Bericht andererseits zeigt, dass alle Seiten leicht gefüllt sind - beispielsweise weniger als 60% -, wäre der Index ein guter Kandidat für eine Wiederherstellungsübung.

Berücksichtigen Sie unbedingt die Gesamtzahl der Knoten, bevor Sie mit der Neuerstellung beginnen. Wenn der Index nur eine geringe Anzahl von Knoten enthält, hilft die Neuerstellung nicht bei der Speicherplatznutzung, da möglicherweise nicht genügend Datensätze vorhanden sind, um die Indexseiten tatsächlich zu füllen.

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.

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.

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.

Analysieren Der Gesamten Datenbank