Appendix E. Monitoring Tables
The Firebird engine can monitor activities in a database and make them available for user queries via the monitoring tables.
The definitions of these tables are always present in the database, all named with the prefix MON$
.
The tables are virtual: they are populated with data only at the moment when the user queries them.
That is also one good reason why it is no use trying to create triggers for them!
The key notion in understanding the monitoring feature is an activity snapshot. The activity snapshot represents the current state of the database at the start of the transaction in which the monitoring table query runs. It delivers a lot of information about the database itself, active connections, users, transactions prepared, running queries and more.
The snapshot is created when any monitoring table is queried for the first time.
It is preserved until the end of the current transaction to maintain a stable, consistent view for queries across multiple tables, such as a master-detail query.
In other words, monitoring tables always behave as though they were in SNAPSHOT TABLE STABILITY
(consistency
) isolation, even if the current transaction is started with a lower isolation level.
To refresh the snapshot, the current transaction must be completed and the monitoring tables must be re-queried in a new transaction context.
SYSDBA and the database owner have full access to all information available from the monitoring tables
Regular users can see information about their own connections; other connections are not visible to them
In a highly loaded environment, collecting information via the monitoring tables could have a negative impact on system performance.
- Section E.1, “
MON$ATTACHMENTS
” Information about active attachments to the database
- Section E.3, “
MON$CALL_STACK
” Calls to the stack by active queries of stored procedures and triggers
- Section E.2, “
MON$COMPILED_STATEMENTS
” Virtual table listing compiled statements
- Section E.4, “
MON$CONTEXT_VARIABLES
” Information about custom context variables
- Section E.5, “
MON$DATABASE
” Information about the database to which the
CURRENT_CONNECTION
is attached- Section E.6, “
MON$IO_STATS
” Input/output statistics
- Section E.7, “
MON$MEMORY_USAGE
” Memory usage statistics
- Section E.8, “
MON$RECORD_STATS
” Record-level statistics
- Section E.9, “
MON$STATEMENTS
” Statements prepared for execution
- Section E.10, “
MON$TABLE_STATS
” Table-level statistics
- Section E.11, “
MON$TRANSACTIONS
” Started transactions
E.1. MON$ATTACHMENTS
MON$ATTACHMENTS
displays information about active attachments to the database.
Column Name | Data Type | Description |
---|---|---|
|
| Connection identifier |
|
| Server process identifier |
|
| Connection state:
|
|
| Connection string — the file name and full path to the primary database file |
|
| The name of the user who is using this connection |
|
| The role name specified when the connection was established.
If no role was specified when the connection was established, the field contains the text |
|
| Remote protocol name |
|
| Remote address (address and server name) |
|
| Remote client process identifier |
|
| Connection character set identifier (see |
|
| The date and time when the connection was started |
|
| Garbage collection flag (as specified in the attachment’s DPB): 1=allowed, 0=not allowed |
|
| The full file name and path to the executable file that established this connection |
|
| Statistics identifier |
|
| Client library version |
|
| Remote protocol version |
|
| Name of the remote host |
|
| Name of remote user |
|
| Name of authentication plugin used to connect |
|
| Flag that indicates the type of connection:
|
|
| Connection-level idle timeout in seconds.
When |
|
| Idle timer expiration time |
|
| Connection-level statement timeout in milliseconds.
When |
|
| Wire compression active (TRUE) or inactive (FALSE) |
|
| Wire encryption active (TRUE) or inactive (FALSE) |
|
| Name of the wire encryption plugin used |
|
| Name of the session time zone |
|
| Maximum number of parallel workers for this connection, |
Retrieving information about client applications
|
SELECT MON$USER, MON$REMOTE_ADDRESS, MON$REMOTE_PID, MON$TIMESTAMP
|FROM MON$ATTACHMENTS
|WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION
E.1.1. Using MON$ATTACHMENTS
to Kill a Connection
Monitoring tables are read-only.
However, the server has a built-in mechanism for deleting (and only deleting) records in the MON$ATTACHMENTS
table, which makes it possible to close a connection to the database.
All the current activity in the connection being deleted is immediately stopped and all active transactions are rolled back
The closed connection will return an error with the
isc_att_shutdown
code to the applicationSubsequent attempts to use this connection (i.e. use its handle in API calls) will return errors
Termination of system connections (MON$SYSTEM_FLAG = 1
) is not possible.
The server will skip system connections in a DELETE FROM MON$ATTACHMENTS
.
Closing all connections except for your own (current):
|
DELETE FROM MON$ATTACHMENTS
|WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION