Tuesday, July 28, 2009

Extract Controlfile from a backupset using RMAN

In my previous post, I had talked about extracting controlfiles, datafiles and archivelogs from RMAN backupsets using the package dbms_backup_restore.



In this post, I would like to throw light upon using RMAN as an alternate method that could be employed to extract controlfiles from RMAN backupsets. This method uses the RMAN command "restore controlfile from '<FULL_PATH_TO_CONTROLFILE_BACKUP>'".



The RMAN method can be used in 3 scenarios. So, make sure that at least any one of the backups is indeed available. Else, you are DOOMED!


I. the controlfile autobackup is turned on in RMAN. In this case the file format would be "c<DBID>-<DATE>-<COUNT>".

It is turned on using the command:

configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to '/opt/apps/vision/backup/%F';

II. the controlfile snapshot backup is configured in RMAN.

It is turned on using the command:

configure snapshot controlfile name to '<FULL_PATH_TO_SNAP_CTRL_FILE>';

III. the controlfile is included in the RMAN backupset i.e., using the clause "include current controlfile" in the backup database command.


Scenario I - Restoring controlfile using RMAN and controlfile autobackup.

a. Startup the database in nomount state.



b. Run RMAN commands as below:


$ rman target /


Recovery Manager: Release 9.2.0.6.0 - 64bit Production


Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.


connected to target database: BKP (not mounted)


RMAN> restore controlfile from '/opt/apps/vision/backup/c-261506738-20090722-02';
Starting restore at 23-JUL-09
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete
replicating controlfile
input filename=/opt/apps/vision/bkpdata/bkpdatacontrol01.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol02.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol03.ctl

Finished restore at 23-JUL-09

RMAN>


Scenario II - Restoring controlfile using RMAN and controlfile snapshot.



a. Startup the database in nomount state.

b. Run RMAN commands as below:


$ rman target /


Recovery Manager: Release 9.2.0.6.0 - 64bit Production


Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.


connected to target database: BKP (not mounted)


RMAN> restore controlfile from '/opt/apps/vision/backup/snap_BKP_controlfile.ctl';


Starting restore at 23-JUL-09

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK
channel ORA_DISK_1: copied controlfile copy
replicating controlfile
input filename=/opt/apps/vision/bkpdata/bkpdatacontrol01.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol02.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol03.ctl

Finished restore at 23-JUL-09


RMAN>


Scenario III - Restoring controlfile using RMAN and backupsets (provided backup is taken using the "include current controlfile" clause).


Note: The RMAN backup log would record the backup piece name which includes the controlfile. If you are not sure which backup pice contains the controlfile, then try this on all the backup pieces till the controlfile is restored.


a. Startup the database in nomount state.

b. Run RMAN commands as below:


$ rman target /


Recovery Manager: Release 9.2.0.6.0 - 64bit Production


Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.


connected to target database: BKP (not mounted)


RMAN> restore controlfile from '/opt/apps/vision/backup/BKP_LVL0_20090722_09kkof7i_s9_p1';

Starting restore at 23-JUL-09


using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete
replicating controlfile
input filename=/opt/apps/vision/bkpdata/bkpdatacontrol01.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol02.ctl
output filename=/opt/apps/vision/bkpdata/bkpdatacontrol03.ctl

Finished restore at 23-JUL-09


RMAN>

Monday, July 27, 2009

Extract Controlfile, Datafiles & Archivelogs from RMAN Backupsets

The other day, one of my colleagues posed me this interesting and thought-provoking question/scenario: "Suppose, you were to lose both your production and your RMAN catalog databases irrevertably. You do have a full/incremental RMAN backup, however. How are you going to recover?"


How indeed? I scratched my head and shone a torch upon the dark recesses of my memory to come up with an answer. The light (of the torch) did indeed reveal something - that is that a note existed in Metalink which list the method that could be used to delve into a RMAN backup set to extract the controlfile, the datafiles and also the archivelogs and Voilà, I hit the nail right on the head.


I did some more digging and found a bunch of "Notes" in Metalink that pointed me to the eventual answer to the above question. The Notes that I am referring to are listed below. A summary of the procedure to be followed in such scenarios is also provided. All the notes mentioned use the package dbms_backup_restore.


Scenario:


A successful production backup (RMAN) is available (cold or hot - if hot, then the archivelogs are also available) while the production and the RMAN catalog databases are irrevertably lost.



Assumptions:


1. RMAN is being used to backup the database.


2. The RMAN backup is a "good" backup and is restore and recovery ready.


3. The list of datafiles (file name + full file path) and their datafile numbers is available (this can be obtained from the RMAN backup log file).



Solution Summary (from Note ID: 388057.1):


1. Start the target instance (nomount).


2. Restore the latest controlfile, ideally from the same backupset as the last incremental to be restored (Note 388052.1 : restore controlfile using PLSQL).


3. Make further copies if necessary as per the target database init.ora (pfile).


4. Mount the target instance (alter database mount).


NOTE: (RMAN may be able to be used to restore / recover the database at this point if the controlfile restored knows about the backup required to be restored and recovered).

5. Restore the datafiles from the level 0 backupset (Note 388053.1 : restore datafiles using PLSQL).


6. Restore (apply) the datafiles from the incremental backupsets (Note 388054.1 : restore incremental backups using PLSQL).


7. Restore the archivelogs from the archivelog backupset (Note 388055.1 : restore archivelogs using PLSQL).


8. Using traditional recovery techniques, recover the database using SQLPLUS. (until cancel using backup controlfile).


9. Open the database (resetlogs).


10. Rebuild the recovery catalog & re-register the target database.


11. Make backups of the target database and recovery catalog database.


References:


1. 60545.1 - How to Extract Controlfiles, Datafiles, and Archived Logs from RMAN Backupsets


2. 388052.1 - How to Extract the Control file from an RMAN backupset using PL/SQL


3. 388053.1 - How to Extract Datafile(s) from an RMAN backupset Level-0(Full) backup using PL/SQL.


4. 388054.1 - How to Extract Incremental Backups of Datafile(s) from an RMAN Incremental backupset Level-1 or higher using PL/SQL.


5. 388055.1 - How to Extract archive logs from an RMAN using PL/SQL.


6. 388057.1 - How to Restore an RMAN Backed up database using PL/SQL.

Wednesday, July 1, 2009

Creating defaultsfile - an easy guide!

This post is for the automation fanatics and enthusiasts. Of course, the others aren't excluded! The defaultsfile option that can be used with adutilities is a handy option to save time during patching or other maintenance activities.

Though the defaultsfile gets a mention by almost everyone in the context of reducing downtime, the method of creating it is not, unfortunately. In this post, I'd like to share this using an example - compiling apps schema using adadmin.
Note: The full explanation of creating a defaultsfile is mentioned in Chapter 2 (Maintaining Your System) of the Oracle Applications Maintenance Procedures.
1. Run adadmin command as below:

adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/<DEFAULTS_FILE_NAME>


e.g.:

adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/adadmin_cmpl_apps_schema.txt


The above command searches for a file with name adadmin_cmpl_apps_schema.txt in $APPL_TOP/admin/$TWO_TASK directory. If it exists, it uses the values provided in that file. Else, it creates a new file and the contents of the new file would be the answers that one provides at the subsequent prompts of adadmin.

Note: Not mentioning the correct path would error out as below. So, always ensure that you mention the full path to the default file.

$ adadmin defaultsfile=adadmin_maint_on.txt

Copyright (c) 2002 Oracle Corporation
Redwood Shores, California, USA
Oracle Applications AD Administration
Version 11.5.0

NOTE: You may not use this utility for custom development unless you have written permission from Oracle Corporation.

You have not specified the correct path for defaults file.

The expected location of the defaults file is
$APPL_TOP/admin/$TWO_TASK
and you must provide full access path to the file.

2. Assuming that the defaultsfile does not exist, proceed as you normally would for compiling apps schema.

3. Once the compilation is complete, exit out of adadmin and look for the file $APPL_TOP/admin/$TWO_TASK/adadmin_cmpl_apps_schema.txt.

4. Voilà! You are done! You have the defaultsfile (including passwords) for compiling apps schema. Whenever you want to compile apps schema using adadmin NON-INTERACTIVELY, run the below command:

$ adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/adadmin_cmpl_apps_schema.txt