Querying the history file (db2 list history backup all for sample) shows that it contains the following entry for the backup image whose timestamp is 20040618185359: Op Obj Timestamp Sequence Type Dev Earliest Log Current Log Backup IDī D 20040618185359001 F D S0000001.LOG S0000001.LOGĠ0002 Location: D:\WorkDir\SAMPLE.0\DB2\NODE0000\CATN0000\20040618 Rows with ID values ranging from 17 to 19 were inserted after the point in time to which we rolled the logged transactions forward. Querying the STAFF table confirms that the only new rows remaining are those with ID values ranging from 11 to 16. Next, we will restore the most recent backup image and then roll the transactions forward to a point in time that precedes the last three insert operations. The timestamp for this second backup image is 20040618185359. Next, we will insert some new data into the STAFF table, and then we will create another full database backup image: db2 connect to sampleĭb2 insert into staff values (11,’Smith’,20,’Sales’,10,70000,15000)ĭb2 insert into staff values (12,’Cheney’,20,’Sales’,7,65000,14000)ĭb2 insert into staff values (13,’Stier’,20,’Sales’,9,72000,17000) The timestamp for this backup image is 20040618185309. We will start by configuring the database to be recoverable, and then create a full database backup image: db2 update db cfg for sample using logretain on userexit yes We will use the SAMPLE database that comes with DB2 UDB. Let’s develop a straightforward recovery scenario to demonstrate database recovery before “Stinger”, and then compare that to simplified database recovery in “Stinger”. You do not need to specify which database backup image is to be restored, and you do not need to know which log files on which log chain are required to reach the specified point in time.ĭatabase Recovery before DB2 UDB “Stinger” The new RECOVER DATABASE command allows you to simply specify a point in time to which to recover the database. With this information, and with the database backup and restore information already stored in the history file, the DB2 database recovery utilities can figure out which database backup image, and exactly which log files are required to restore to any point in time. “Archived log” entries in the history file indicate precisely when log files have been archived, and exactly where they have been archived. “Stinger” solves this problem by adding a new entry type to the history file. It would sometimes be difficult to determine when it was safe to delete archived logs, and there was no automated way to ensure that the appropriate chain of log files was made available to the DB2 rollforward utility after a database restore operation. Before “Stinger,” things could get complicated when re-used log files were archived, overwriting older archived log files. The current log chain (or sequence) is determined by which particular database backup image has been restored, and the log files that have been processed. Recovering a database to a specific point in time, or restoring the database without rolling transactions forward creates a new log chain and causes transaction log files to be re-used. The RECOVER DATABASE command combines the functionality of the RESTORE DATABASE and the ROLLFORWARD DATABASE commands, and does not require you to specify which database backup image must be restored, or which log files are needed for point-in-time (PIT) recovery. In this article, we will introduce the new RECOVER DATABASE command and significant changes to the history file that, together, make it easier to recover a database from a backup image. This article is another in a series that introduces some of the key features in DB2 UDB “Stinger,” and includes “work-through” examples that you can use with the open beta today. As of the publication date of this article, it is available as an open beta for download at. The technology preview of the next release of IBM DB2 Universal Database (DB2 UDB) for Linux, UNIX, and Windows is codenamed “Stinger”.
0 Comments
Leave a Reply. |