Backup and Recovery
Ingres is a fully transactional DBMS. These transactions may be recorded as journals associated with the database under the II_JOURNAL path. The journals created by the DBMS may then be examined as part of auditing activity or used in a database recovery. To enable journaling on a database is a two step process. Namely: Enable journaling on the database as a whole. This is done by specifying the '+j'
flag to the ckpdb command. Nominate tables within the database for journaling. Note that indexes do not
need to be nominated, views cannot be journalled. Note that the configuration of the Ingres DBMS allows for the new tables to be automatically journal enabled via the default journaling parameter. Some care should be taken with this facility as not all tables should be journaled. For example a work table which is constantly emptied and refreshed should not be journal enabled as it places extra data in the journal system which is generally irrelevant to auditing and not required for database recovery. A tables journaling status may be easily altered. However if journaling is enabled on the table the journaling will not commence until after the next occasion the database is backed up using the ckpdb command. If the table is created journal enabled, the journaling will commence immediately. If journaling is disabled the effect is also immediate. To examine the journals for a database in a human readable form is simply a matter of using the auditdb command. The command is option rich and has many features for auditing transactions committed within a given time frame, by specified users on a nominated set of tables etc. The command has other options which can be used as part of an audit trail recovery for a database. Backup The principal backup utility provided in the dbms is the command: ckpdb Ingres backups may be taken On-line where some user activity is permitted on the database, or Off-line where no user activity is permitted on the database. During On-line
checkpoints users may still select, insert, update or delete from the database but are not permitted to drop tables, modify existing structures or other DDL statements. Backups will capture the entire database by default, however the ckpdb command may be directed to restrict itself to specific tables. This ckpdb utility would typically create a tar file snapshot of the database. These snapshots are referred to as checkpoints. The files created are stored in the databases II_CHECKPOINT location. To allow for changes being made to the databases tables during the lifetime of the backup, the system will also create dump files. These reflect the changes being made and are used to ensure the database will be restored to a consistent state as at the start of the checkpoint if a database recovery is required. The dump files created are stored in the databases II_DUMP area. A databases backup history may be examined using the infodb command. It will print a human readable summary of the databases backup history ... as well as other datum. For example infodb iidbdb would generate the backup history of the master catalog database iidbdb. Other archiving tools may be used. More recent versions of ingres also provide a cpio based version. Furthermore, some customisation of the backup is achievable by editing theCheckpoint template file. A typical user customisation is to direct tar to use compression. Multiple template files may be created and a specific one selected by pointing to it with the environment variable II_CKTMPL_FILE. The default template file is: II_SYSTEM/ingres/files/cktmpl.def. The alternatives to ckpdb are the utilities: copydb or unloaddb. These provide static snapshots only. If these utilities are used, care should be taken to ensure the correct representation of floating point numbers and dates. It is not a good idea to back up an Ingres database with an OS dump of the databases data areas.
The principal means of recovering an Ingres database from a checkpoint is the utility: rollforwarddb
By default rollforwarddb will restore the database from its most recent valid backup and then apply all the databases journals and thus restore the database as completely as possible. Furthermore, the command is option rich, and it may be directed to: use an older checkpoint, not apply journals, apply journals up to a specified end time. The time ensuring all
transaction committed at or before this time are restored. apply journals from a specified begin time. The time ensuring that all
transactions committed on or after this time are restored. This is a rarely employed option. Note that for time based recoveries the critical feature is when the transaction was committed, not when it was started. If it becomes necessary to see what transactions will be included in the recovery the time parameters can be used in the auditdb utility. That utility will display the included transactions and their details. Customisation of the rollforwarddb utility may also be performed by editing the checkpoint template file. For example, if the checkpoints were compressed the rollforwarddb command will need a customisation installed to allow it to process the compressed tar file.