Ckpdb and Rollforwarddb commands

Introduction All Ingres database administrators should have the skills to manage their database in the event of a disaster, restoring the database to a previous point in time and minimizing or ideally avoiding data loss. Ingres has the facilities to restore the database from a checkpoint (a snapshot of the database), and optionally using journal files to restore the database right up to the moment before the disaster. In order to be able to restore the database to a previous state you need to know also how to create backup copies (checkpoints) of Ingres databases. Checkpoints There are two types of checkpoints available in Ingres, offline and online. Each works slightly differently, but at the basic level they both take a snapshot of the database to provide a recovery mechanism. Offline Checkpoint An offline checkpoint can only be run when it has an exclusive lock on the database. If a user is connected to the database the checkpoint will fail. Optionally, when running an offline checkpoint you can specify for the checkpoint to wait until it can acquire an exclusive lock however long that may be. While the checkpoint is running no other user is allowed access to the database. As soon as the checkpoint gains an exclusive lock on the database, a marker will be written to disk in the journal files to indicate that all previous journals pertain to the previous checkpoint. All new journal records will be associates with the new checkpoint. The checkpoint will then force a consistency point. It is to ensure the data areas are consistent before they are written out to the checkpoint files. Online Checkpoint Unlike an offline checkpoint, an online checkpoint can run while the database is still open. As users may be still connected to the database, the checkpoint has to place a stall lock on the database to briefly prevent any new users connecting and to wait until all open transactions have completed. The purpose of this is to find a consistent starting point for the checkpoint to begin from. Once a consistent starting point has been established for the database, a marker will be written to disk in the journal files to mark all previous journals as pertaining to the previous checkpoint which means all new journal records will be associated with this new checkpoint. When the marker has been written to the journal logs a consistency point is then invoked for the database. The main purpose is to ensure that the data areas for the database are consistent with the journals. The stall lock is then released on the database whilst the checkpoint writes the data to the checkpoint files. Users can now carry on using the database while this is happening. Certain actions are restricted while the checkpoint is running though, such as creating tables or modifying columns. If any data is modified during an online checkpoint the affected pages from the data file are copied to the dmp location before the update is made. This ensures that any changes to data made during the checkpoint will not be reflected in the checkpoint snapshot when it is restored. Any updates to data made during an online checkpoint will be captured in journal files if journaling is enabled. The benefits of an online backup are that the database is made available to users while the checkpoint is running. Only a small amount of time is needed to gain a consistent starting point before the actual process begins. Sandyxsystems.co.uk Copyright 2008 Page 2 of 5

The ckpdb command The ckpdb command is used to initiate a checkpoint. You will use the same command to start an offline or online checkpoint. Offline checkpoint This is the command to start an offline checkpoint in its most basic form: ckpdb l {dbname} The l switch above means offline. Substitute {dbname} with the name of your database. Online checkpoint This is the command to start an online checkpoint: ckpdb {dbname} When the l is not present then the command will default to running an online checkpoint. Checkpointing multi-location databases If a database has 2 or more data locations then they can be checkpointed concurrently to help reduce checkpoint runtimes. Although concurrent checkpoints are usually faster than their serial equivalents they are typically resource hungry and will consume more CPU and disk resource depending on how many physical disks the database makes use of. For more details on concurrent checkpoints of multi-location databases there is another white paper available on the Sandyx Systems website that covers the topic in more detail. Validate your checkpoints After a checkpoint has completed it is best to always check to see if the checkpoint has completed successfully and that the checkpoint is valid itself. To check to see if the checkpoint is valid run the following command: Infodb {dbname} This will give you lots of information regarding your database, but near the top of the results will show a list of all of the checkpoints which have been run on the database. There should be a column which should say valid. If it displays 1 next to the time and date which you have run your checkpoint, it is valid. If it displays 0, it could mean the checkpoint is still running or the checkpoint is invalid. Rollforwarddb command The rollforwarddb command is used to roll the database back to a previous point in time. The database can be rolled back to a previous checkpoint or even rolled back up until the point of a disaster if journal files are enabled. Sandyxsystems.co.uk Copyright 2008 Page 3 of 5

Basic syntax The basic syntax to recover the database is: rollforwarddb {dbname} The above command will restore the database {dbname} using the last checkpoint available and any associated journal files, this is the default behavior of the command. Restoring a database to a specific time and date The command can also allow Ingres database administrators to restore a database to a specific moment in time, so long as checkpoints are available with journaling enabled. rollforwarddb +j e22-oct-2008:16:15:00 {dbname} The above command will restore the database to the 22 nd October 2008 at 4:15pm using the journal files. Restoring a checkpoint without using journal files This particular method only applies to Unix. Each checkpoint that exists for a database has a sequence number. If you wish to restore the database to a particular checkpoint you can find the sequence number using the command infodb (which also informs you of more useful information regarding the database). rollforwarddb #c4 j {dbname} The above command is will restore the checkpoint number 4 without applying the journal files. On some terminals you may have to escape the # by preceding it with a \. For example: rollforwarddb \#c4 j {dbname} Parallel restoration If your database uses multiple locations when you come to use the rollforwarddb command you can reduce the time needed for restoration of a checkpoint by restoring the locations in parallel. This works using exactly the same principle as concurrent checkpoints but in reverse. If your database had 5 different database locations, the default action would be to restore one location at a time. Using the following may reduce the time to restore depending on your hardware configuration: rollforwarddb {dbname} #m5 If you use more than 5 different database locations you can substitute the number 5 above in the example. On some terminals you may have to escape the # by preceding it with a \. Best practice As soon as you have restored a checkpoint using the rollforwarddb command you should ideally re-checkpoint the database and validate the data within the newly restored database. About Sandyx Systems Sandyx Systems are an Ingres partner and provide Ingres remote support and consultancy services. These services have included off-site database support and UNIX systems administration. Our flexible approach has meant that we have the ability to offer our services from one-off independent healthchecks to 24/7 remote database support. Sandyxsystems.co.uk Copyright 2008 Page 4 of 5

Please call us on 0870 350 7701 or visit us at www.sandyxsystems.co.uk for more details. Disclaimer The Information in this document should be used as a guide only and should not be relied upon as the sole source of information relating to its content. Additional sources of information may be listed herein. No warranty, either express or implied, is made with respect to the information contained herein. Neither is Sandyx Systems responsible for any loss, inconvenience, damage (whether special or consequential) or claims arising out of the use of the information contained in this document. Sandyxsystems.co.uk Copyright 2008 Page 5 of 5