`gstat` caveats

The following is a brief list of gotchas and funnies that I have detected in my own use of gstat. Some of these are mentioned above, others may not be. By collecting them all here in one place, you should be able to find out what's happening if you have problems.

The `-t[able]` switch can cause problems

The -t[able] switch expects a list of table names (in upper case) to be supplied. Unfortunately, if you supply the database name after a table name, it is assumed to be a table name and you are prompted for a database name.

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

For this reason, always call gstat with the database name as the very first parameter:

 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 ...
 ...

Alternatively, supply an additional switch after the last table name and before the database name:

 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 ...

The shadow count seems wrong

It appears that adding and/or dropping shadow files from a database is not always reported by gstat when it produces a database report.

 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
 ...

Straight away, it is obvious that the report from gstat is incorrect as the employee database has one shadow file. If we use isql to add a new shadow file to this database, as shown below, gstat still insists that there are no shadows.

 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

back to top of page
<< gstat examples and interpretation | Firebird Database Statistics Reporting Tool | A: Document history >>