The SIRA_PRISE monitor commands allow to inspect and/or intervene in an active SIRA_PRISE server. This page explains the available monitor commands.
The shutdown command starts the server's graceful-shutdown procedure. The port listener is stopped to prevent new connections from becoming active, all idle connections that do not have a transaction running are closed, and then the server waits for all currently running transactions to end, after which point the corresponding connections are also closed, the java virtual machine exits, and the server can be restarted.
Should there be a running
transaction that doesn't ever seem to
end, even after the transaction has already been set to cancel via the KILLCONNECTION
command, then there is no other option left but to stop the SIRA_PRISE
server by whatever facility is available for that purpose at the OS
level (or some other even more drastic kind of cold restart, such as
switching the hardware off and on), and restoring all databases to a
guaranteeably consistent state from the most recent backup (and
possibly running a rollforward recovery procedure after that).
The luws command can be used to obtain an overview of the currently active luws (= user transactions) in the SIRA_PRISE server's universe. Idle connections (i.e. connections awaiting a new transaction) are not listed. The output is a relation with the following heading :
HEADING(CONNECTIONID(STRING)USERID(NAME)STATUS(STRING))
A request to terminate an
active Connection/Luw can be sent
using the KILLCONNECTION
command. The syntax is KILLCONNECTION
CONNECTIONID(...), with the
ellipsis replaced by the precise
value of the CONNECTIONID
returned by the LUWS
command for the connection/transaction/luw to be killed. The format of
this connectionID attribute is as follows : a forward slash, followed
by the IP address in dotted decimal of the connected client, followed
by a colon, followed by the client port number of the connection.
Observe that sending this command will not guarantee the immediate termination of the running luw/transaction. Such will only occur at the point where that transaction attempts to communicate with the client side of the connection. This will obviously never occur if the transaction has gotten in an infinite loop or so, which of course we believe is totally impossible :-)
The RELVARS
command can be used to obtain an
overview of which relvar definitions currently reside in SIRA_PRISE's
relvar pool. The output is a relation with the following heading :
HEADING(RELVARNAME(NAME)
EXCLUSIVEUSERS(RELATION(HEADING(EXCLUSIVEUSER(NAME))))
SHAREDUSERS(RELATION(HEADING(SHAREDUSER(NAME)))))
The FILES
command can be used to obtain an
overview of which dbms file definitions currently reside in
SIRA_PRISE's file pool. The output is a relation with the following
heading :
HEADING(FILENAME(FILENAME))
The memory command can be used to obtain information about the current memory usage by the SIRA_PRISE server. The output is a singleton relation with four attributes :
PROCESSORS(INT)
- the number of available
processors as reported by the server's JVM.
USEDMEMORY(INT)
- the size of occupied memory within
the SIRA_PRISE server.
FREEMEMORY(INT)
- the size of currently unused memory
allocated to SIRA_PRISE.
MAXMEMORY(INT)
- the maximum amount of memory that can
be allocated to SIRA_PRISE.
Memory sizes are expressed as a number of Kilobytes.
The STATISTICS
command can be used to collect
statistics about a recorded relvar. The command must be specified as 'STATISTICS
RELVARNAME(...)', with the
ellipsis replaced by some valid
relvar name.
When given this command, the engine will start scanning the named relvar's tuples, and collect statistics about them. The statistics collected include the relvar cardinality (the number of tuples held in the body of the relvar), and value distribution statistics for the most important attributes of the relvar (that is, all attributes that appear as an index component in any index on any of the relvar's record types).
The relvar cardinality is recorded in the catalog relvar RELVARCARDINALITY, while the attribute value distribution statistics are recorded in the catalog relvar ATTRIBUTEVALUEDISTRIBUTION.