Monitoring with System Temporary Tables

From InterBase

Go Up to Database Statistics and Connection Monitoring

The InterBase Server has always kept a lot of statistics about what was going on, but it has not been easy, or in some cases possible, to surface that information. Now, InterBase captures that information and makes it available in a set of global system temporary tables. These tables describe the runtime behavior of a database. They also provide a level of control.

Although it has always been possible to see a list of users who were currently attached to a database, you can now find out much more. For example, you can see how long each user has been connected, what application each user is running, or the total amount of data I/O used by each attachment. A glance at the temporary table metadata listed in the Language Reference Guide will suggest the vast possibilities that are available here.

It is also possible to exercise a certain amount of control over the state of a database by performing updates to these tables. See Updating System Temporary Tables.

These system temporary tables are specific to each database attachment and are visible only to the sysdba user and the database owner. There is therefore no need for unique names and no danger of collisions by separate attachments. Each table is populated only at the point when a client queries it.

The following system temporary tables are available. Their structure is documented in the Language Reference Guide.

InterBase Temporary System Tables
Table name Description


One row for each connection to a database.


One row for each database you are attached to.


One row for each entry in the InterBase Random and Block heap.


One row for each index loaded in to database cache.


One row for each block of memory in each pool.


One row for each current memory pool.


One row for each procedure executed since the current connection began.


One row for each relation referenced since the current connection began.


One row for each statement currently executing for any current connection.


One row for each transaction that is active or in limbo.


One row for each trigger loaded in to the database cache.


Advance To: