- IBM DB2 9.7 Advanced Administration Cookbook
- Adrian Neagu Robert Pelletier
- 647字
- 2021-08-20 15:33:21
Creating a database from an existing backup
Let's suppose you want to copy a production database into a QA server. You can prepare a script using the GUI. It will walk you through the process, and will allow you to save the script. With the GUI, you can also schedule this script as a regular task so you can refresh your QA environment on a weekly basis or at any frequency you wish.
Getting ready
Identify the backup you want to recover, and do a verification to make sure it's valid. In our example, we'll start here from a cold (offline) backup stored on disk, so there is no tape command or rollforward to do.
How to do it...
- Make sure the backup is valid.
Log in as instance owner. Go to the backup location and, from the operating system command line (Linux in this example), type
db2ckbkp:[db2inst1@nodedb21 ~]$ cd /maint/backups [db2inst1@nodedb21 backups]$ db2ckbkp NAV.0.db2inst1.NODE0000. CATN0000.20101114190028.001 [1] Buffers processed: ####### Image Verification Complete - successful. - Restore the database:
Within the Control Center's GUI, right-click on the
Databasesfolder and select Create database, and on the next sub menu, From Backup. - Define location information for the new database:
- Let's say you want to create a development database from a production database. Both databases have the same name. Copy your production backup file on your development server.
Enter the source database NAV, and the target database,
NAV, located in directory/data/db2;logs, if any, will be stored in/data/db2/logs. Click Next. - Select the backup image to use:
On the next screen, leave Media Type to File System, and click Add to specify the filesystem directory where the backup is located. In our example, this is in /maint/backups. Locate the backup you want—
NAV.0.db2inst1.NODE0000.CATN0000.20101114190028.001.
[db2inst1@nodedb21 ~]$ cd /maint/backups/ [db2inst1@nodedb21 backups]$ ls -al *001 -rw------- 1 db2inst1 dba 25186304 2010-11-14 19:00 NAV.0.db2inst1.NODE0000.CATN0000.20101114190028.001 -rw------- 1 db2inst1 dba 20992000 2010-11-15 18:15 POS.0.db2inst1.NODE0000.CATN0000.20101115181505.001 [db2inst1@nodedb21 backups]$
- You see from part of the filename,
20101114190028, that the date is November 14, 2010 and the time is 19:00:28. You can now click Finish; the newNAVdatabase will be created. Go back to Control Center and, from the menu, select View and Refresh.
How it works...
DB2 will restore the database to the state of the specified backup. All containers from the current database will be deleted and the containers from the backup will be restored.
If you created a table space with a file container, since the previous backup, and you do a restore from a previous backup, this container will be deleted, as it's not recognized as being part of the database.
There's more...
Now, we do the actual restore (here, from the Linux command line); the following time stamp is part of DB2 backup file's naming convention:
[db2inst1@nodedb21 backups]$ db2 RESTORE DATABASE NAV FROM "/maint/backups" TAKEN AT 20101114190028 WITH 2 BUFFERS BUFFER 1024 REPLACE HISTORY FILE PARALLELISM 1 WITHOUT PROMPTING DB20000I The RESTORE DATABASE command completed successfully.
Backups are not compatible between Windows and Linux/Unix; this is an example error message when attempting to restore a Windows database from a backup made on a Linux platform. Backups between Linux/Unix are compatible under certain conditions.
Roll-forward recovery lets you replay archived logs after a database recovery so you can recover the database to a specific moment, for example, just before a disk crash. We will cover this feature in Chapter 7.
Redirected restore lets you recover a database in a different location, for example if you want to create a QA environment from a prod database backup, so that they can coexist on the same server. We will cover this situation in Chapter 7.
See also
Backup and recovery recipe in this chapter