|
|
|
The infodb command displays a variety of information on a database, including its status, the location of its files (from the configuration file aaaaaaaa.cnf), and a history of checkpoints and journaling.
To use this command, you must be a privileged user or the DBA of the specified database. If you are a privileged user, you can use the -u flag to impersonate another user. On VMS, to use this command against a database in a group level installation, you must be a privileged user (VMS CMKRNL, SYSPRV, and PHY_IO privileges).
The infodb command has the following format:
infodb [dbname[/server_class]][#c[n]][-uusername][-help]
Indicates the name of the database, and if required, the server_class, as described in Standard Flags and Parameters.
If no database is specified, infodb prints a report for each database.
Provides detailed information about a specific checkpoint for the database. The checkpoint number n must be a valid checkpoint number. If n is omitted, information about the most recent completed checkpoint is displayed.
UNIX: In bash shell, you must place this option in quotes; otherwise characters after the # will be treated as a comment. For example:
infodb empdata "#c1"
Specifies the effective user for the session, as described in Standard Flags and Parameters.
Displays command syntax online.
|
|
|
The following is sample output from the database information section. This guide includes the callouts (1) and (2) to aid in explanation:
(1)================11-FEB-2001 14:05:55.02 Database Information==========
Database : (doc,kbref) ID : 0x2D5BF682
Extents : 5 Last Table Id : 171
Config File Version Id : 0x00040001 Database Version Id : 5
Status : VALID,JOURNAL,CKP,DUMP,ROLL_FORWARD,CFG_BACKUP
(2) The Database has been Checkpointed.
The Database is Journaled.
Journals are valid from checkpoint sequence : 1
Fields are as follows:
Identifies the date and time the infodb operation was run.
Identifies the name (doc) and owner (kbref) of the database.
Shows the internal identifier of the database.
Indicates the number of locations the database is using.
Indicates the integer identifier assigned to the last created table.
Shows the major (upper 2 bytes) and minor (lower 2 bytes) versions of the configuration file.
The version of DMF that created the database. Note that this is not related to the Ingres version of the database.
Displays status information for the database. Status abbreviations are as follows:
CFG_BACKUP—automatic backup of the configuration file is enabled.
CKP—indicates that you must perform a rollforward +c (back to saveset) before you can do a rollforward -c +j..
DUMP—the database has undergone dump processing (that is, a dump file was created in the dump location) via some online checkpoint
JOURNAL—the database is journaled.
JOURNAL_DISABLED—journaling has been disabled.
NOLOGGING—the database has been opened by a set nologging session. Note that if this session encounters an error, the database will be marked inconsistent.
ROLL_FORWARD—indicates that rollforward is available on the database and has not been run to completion since the last checkpoint was taken.
SMINC—indicates the system catalogs are in an inconsistent state.
VALID—the database is consistent and available for use. If this does not appear, the database is marked inconsistent.
This section displays comments on the status of the database. Important state information is shown.
Shown if the database is inconsistent. The cause of inconsistency can be one of the following:
NOLOGGING_ERROR—a transaction failed while the database was in the nologging state.
NOLOGGING_OPENDB—the database was opened for the first time, but was in the nologging state. This means a session exited abnormally.
OPEN_COUNT—the database was opened for the first time, but the database open count in the configuration file was not zero. This means the configuration file could not be read during a recovery attempt.
REC_OPEN_FAILURE—the RCP could not recover a database because the database could not be opened.
RECOVER_ERROR—the RCP failed to recover a database due to an unexpected logging system or recovery protocol problem.
REDO_ERROR—the RCP failed to recover a database due to an error in REDO processing.
RFP_FAIL—the rollforward of the database level checkpoint failed.
UNDO_ERROR—the RCP failed to recover a database due to an error in UNDO processing.
WILL_COMMIT_ERR—the RCP was unable to restore a transaction to the willing commit state.
Shown if the database has been checkpointed.
Shows the journaling status.
Shown if journaling has been disabled.
Shown if a set nologging session is active on the database.
Shows the earliest checkpoint from which rollforward is allowed.
Shown if rollforward is not valid from any checkpoint, or there are no checkpoints.
|
|
|
The following is sample output from the journal information section:
----Journal information-----------------------------------------------
Checkpoint sequence : 3 Journal sequence : 3
Current journal block : 2 Journal block size : 16384
Initial journal size : 4 Target journal size : 512
Last Log Address Journaled : <760829464:19666:188>
Fields are as follows:
Indicates the current checkpoint sequence number. Incremented when a checkpoint operation is performed.
Indicates the current journal file sequence number.
Indicates the current journal file block sequence number. This is the logical end-of-file of the current journal file.
Indicates the block size of the current journal file, in bytes.
Indicates the number of blocks initialized in the "first journal file" when it is created. The first journal file is the journal file created during the checkpoint +j operation. Subsequent journal files created before the next checkpoint is done will not be initialized.
Indicates the size, in blocks, to which the current journal file may grow before a new journal file should be created. A new journal file will be created at the start of the next archive cycle after the current journal file reaches this size.
Indicates the log address (log sequence number, log page number, log word offset) of the last log record written to a journal file.
|
|
|
The following is sample output from the dump information section:
----Dump information----------------------------------------------------
Checkpoint sequence : 3 Dump sequence : 1
Current dump block : 1 Dump block size : 16384
Initial dump size : 4 Target dump size : 512
Last Log Address Dumped : <760829464::21100:100>
Fields are as follows:
Indicates the current checkpoint sequence number. Incremented when a checkpoint operation is performed.
Indicates the current dump file sequence number.
Indicates the current dump file block sequence number. This is the logical end-of-file of the current dump file.
Indicates the block size of the current dump file, in bytes.
Indicates the initial allocation of the current dump file, in blocks. The number of blocks initialized when a dump file is created.
Indicates the size, in blocks, to which the current dump file may grow before a new dump file should be created. A new dump file will be created at the start of the next archive cycle after the current dump file reaches this size.
Indicates the log address (log sequence number, log page number, log word offset) of the last log record written to a dump file.
|
|
|
The following is sample output from the checkpoint history for journal section:
----Checkpoint History for Journal--------------------------------------
Date Ckp_sequence First_jnl Last_jnl valid mode
--------------------------------------------------------------------
11-NOV-2001 13:23:43.57 1 1 1 1 OFFLINE
11-NOV-2001 13:24:50.40 2 2 2 1 ONLINE
11-NOV-2001 13:58:52.65 3 3 3 1 ONLINE,
TABLE
Fields are as follows:
Indicates the date and time the checkpoint operation was done.
Indicates the sequence number of the checkpoint.
Indicates the journal sequence number of the first (or oldest) journal file corresponding to the checkpoint.
Indicates the journal sequence number of the last (or youngest) journal file corresponding to the checkpoint.
Indicates whether the checkpoint is valid (1 implies valid, 0 implies invalid).
Indicates whether the checkpoint operation was online or offline. Also indicates TABLE if the checkpoint was a table checkpoint.
To recover the entire database, you must specify #c2, for example, in the rollforwarddb command to roll forward from the database checkpoint. Checkpoint 3 was taken on selected tables.
|
|
|
The following is sample output from the checkpoint history for dump section:
----Checkpoint History for Dump------------------------------------------
Date Ckp_sequence First_dmp Last_dmp valid mode
---------------------------------------------------------------------
11-NOV-2001 13:58:52.65 2 1 1 1 ONLINE
11-NOV-2001 13:58:52.65 3 1 1 1 ONLINE,
TABLE
Fields are as follows:
Indicates the date and time the checkpoint operation was done.
Indicates the sequence number of the checkpoint.
Indicates the dump sequence number of the first (or oldest) dump file corresponding to the checkpoint.
Indicates the dump sequence number of the last (or youngest) dump file corresponding to the checkpoint.
Indicates whether the checkpoint is valid (1 implies valid, 0 implies invalid).
Indicates whether the checkpoint operation was online or offline (should always be online). Also indicates TABLE if the checkpoint was a table checkpoint.
|
|
|
The following is sample output from the cluster journal history section:
----Cluster Journal History--------------------------------------------
Node ID Current Journal Current Block Last Log Address
------------------------------------------------------------
0 1 1 <760829462:4731:1592>
1 3 10 <760829464:35000:188>
Fields are as follows:
Indicates the integer identifier of the node.
Indicates the node's current journal file sequence number.
Indicates the node's current journal file block sequence number. This is the logical end-of-file of the node's current journal file.
Indicates the log address (log sequence number, log page number, log word offset) of the last log record written to a journal file on this node.
|
|
|
The following is sample output from the extent directory section, which shows all locations used by the database:
----Extent directory-------------------------------------------------------------
Location Flags Physical_path
-----------------------------------------------------------------------------
ii_database ROOT,DATA c:\Ingres\IngresII\ingres\data\default\iidbdb
ii_journal JOURNAL c:\Ingres\IngresII\ingres\jnl\default\iidbdb
ii_checkpoint CHECKPOINT c:\Ingres\IngresII\ingres\ckp\default\iidbdb
ii_dump DUMP c:\Ingres\IngresII\ingres\dmp\default\iidbdb
ii_work WORK c:\Ingres\IngresII\ingres\work\default\iidbdb
Fields are as follows:
Identifies the logical name of the location.
Indicates the types of database files stored in the location. The possibilities are:
ALIAS—this is a location alias. This means at least one other location points to the same area as this location. This flag is used only for checkpoint and rollforward operations so that locations are neither checkpointed nor rolled forward more than once.
AWORK—this is an auxiliary work file location. Work files (that is, for sorts and temporary tables) are stored in the location.
CHECKPOINT—checkpoint files are stored in the location.
DATA—user data (such as tables, indexes) is stored in the location.
DUMP—dump files are stored in the location.
JOURNAL—journal files are stored in the location.
ROOT—system data (that is, system catalogs) is stored in the location.
WORK—work files (for sorts and temporary tables) are stored in the location.
Identifies the physical path of the location.