Rman

Note: The scripts listed below should be customised and tested thoroughly before implementation on a production system. Please read through the Oracle backup documentation before implementing your backups

RMAN can do everything a normal backup can do, however RMAN has its own backup catalog to record the backups that took place. The database can be in two formats archivelog mode or nonarchivelog mode · archivelog - Oracle saves the filled redo logs files, which means you can recovery the database to any point in time using the archived logs · nonarchivelog - the redo logs are overwritten and not saved, but can only be recovery from the last backup. There are several types of backup · whole backup - you backup the database as a whole which includes the controlfiles · partial backup - you back only a part of the database such a tablespace, one data file · consistent - a consistent backup does not need to go through recover when being restored, normally assiocated with a closed backup · inconsistent - a inconsistent backup always needs to be recovered · open - is backup taken when the database is running, also known as a hot, warm, online backup · closed - is a backup taken when the database is shutdown also know as a cold, offline backup The benefits to using RMAN are · Human error is minimized as RMAN keeps tracks of all the backups · Simple command interface · Unused block compression lets you skip unused data blocks, thus saving space and time. · RMAN can be fully automated · Can perform error checking when backing up or during recovery · Can perform image copies which are simular to operating system backup · Can be used with 3rd party backup management software like Veritas Netbackup · It is well intergrated into OEM, so you can make use of Oracle's scheduler RMAN Architecture The production database that you are backing up is called the target. A separate database, called the recovery catalog, contains information about datafile and control-file copies, backup sets, archived redo logs, and other key elements needed for recovery. RMAN performs two main functions: - It maintains the RMAN metadata in the control file or the recovery catalog. - It communicates with the Oracle database and the operating system in order to create, restore, and recover backup sets and image copies. (RMAN writes image copies to disk only, not to tape.) RMAN creates several client connections, or channels, between the target database and the backup storage device. RMAN can create backup sets on disk or directly on tape. To use tape storage, RMAN requires a media manager. If you have more than one database to back up, you can create more than one recovery catalog and have each database serve as the other's recovery catalog. For example, assume there are two production databases, one called "prd1," and a second called "prd2." You can install the recovery catalog for "prd1" in the "prd2" database, and the recovery catalog for the "prd2" database in "prd1." This enables you to avoid the extra space requirements and memory overhead of maintaining a separate recovery catalog database. However, this solution is not practical if the recovery catalog databases for both reside in tablespaces residing on the same physical disk. To get the most out of RMAN, you should always use a recovery catalog, which contains details of all backup-and-recovery-related operations. RMAN uses the catalog to identify the relationship between backups and database files, automatically deciding which recovery events will minimize the mean time to recover (MTTR). If you run RMAN without using a recovery catalog, it will gather the necessary information from the database's control file but won't

support point-in-time recovery. And if you lose all copies of your control file you'll be out of luck. That's why unless you have only one computer running the Oracle software, you should always use a recovery catalog and store it on totally separate hardware from any of your production or target instances - preferably in a separate location. The catalog itself rarely occupies more than 40MB.

The Recovery Catalog RMAN will use the controlfile on the target database to store repository information regarding any backups for that server, this information can also be stored in a recovery catalog (optional) which resides (on the target server) on its own database (default size should be about 115MB) on the target server or on a server dedicated to RMAN, information is still written to controlfile even if a recovery catalog is used The information stored in the controlfile is stored in the reusable sections called circular reuse records and noncircular reuse records. The circular reuse records have non-critical information that can be overwritten if needed. Some of the non-circular reuseable sections consists of datafiles and redo log information. RMAN can backup archive logs, controlfile, datafiles, spfile and tablespaces it does not backup temporary tablespaces, redo logs, password file, init.ora. The controlfile based repository will retain data for only the time specified by the instance parameter CONTROL_FILE_RECORD_KEEP_TIME this defaults to seven days. Media Management Layer If you backup to tapes you require additional software called MML (media management layer) or media manager. MML is a API that interfaces with different vendors tape libraries. RMAN Configuration STEP 1 Modify your Net Connnections and Create the Recovery Catalog Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. Much of the RMAN LIST output is date/time related. It is often necessary to have this information displayed as accurately as possible when performing time-based recovery. Example NLS settings: NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS Your TNSNAMES.ORA file should have an entry for both your catalog and target databases. For our paper, we will use two databases, the catalog database (RMAN) and the target database (PROD). Connect to the Oracle RMAN instance by using your DBA account, create an account for RMAN, and grant it appropriate rights. sqlplus "sys@RMAN as sysdba" create tablespace RMAN datafile '.......' size 150M autoextend on next 10M maxzize 700M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; create user RMAN identified by rman temporary tablespace TEMP default tablespace RMAN quota unlimited on RMAN; grant recovery_catalog_owner, connect, resource, dba to RMAN; connect RMAN/RMAN@RMAN Then, create the catalog. rman catalog=rman/rman@RMAN rman> create catalog; To drop the catalog run (no backups performed yet): rman> drop catalog;

STEP 2 Check Flash Recovery Area for your PROD (optional) This is where the backups are going to be saved. You can check this parameter by quering query v$recovery_file_dest view. If the space is not big enough, then increase it. If this parameter is not defined yet do it by: alter system db_recovery_file_dest = '/temp/...' scope=both; alter system db_recovery_file_dest_size = 10G scope=both; (ALTER SYSTEM set db_recovery_file_dest_size=60G scope=both sid='*' ; if using RAC) STEP 3 Register Your Database Now you need to register your target database (PROD) with the catalog you've created. This populates the catalog with initial information regarding the configuration of your target database and includes a full synchronization of the catalog with the target database's control file. Make the call to the rman file from your TARGET DB. Example from the PROD box: rman target / catalog=rman/rman@RMAN OR rman target <qstring> [rcvcat <qstring> | cmdfile <qstring> | msglog <qstring> | append | trace <qstring>] Argument Quoted String Description TARGET= A connect string containing a userid and password for the database on which Recovery Manager is to operate. RCVCAT= A connect string that contains a userid and password for the database that contains the recovery catalog (RMAN). CMDFILE= The name of a file that contains the input commands for RMAN. If this argument is specified, RMAN operates in batch mode; otherwise, RMAN operates in interactive line mode. MSGLOG= The name of a file where RMAN records commands and output Results. If not specified, RMAN outputs to the screen. APPEND= This parameters causes the msglog file to be opened in append mode. If this parameter is not specified and a file with the same name as the msglog file already exists, it is overwritten. TRACE= A file name where RMAN will dump a trace information. (useful feature for RMAN jobs debugging) Note: RMAN automatically requests a connection to the target database as SYSDBA. In order to connect to the target database as SYSDBA, you must either: Be part of the operating system DBA group with respect to the target database. This means that you have the ability to CONNECT INTERNAL to the target database without a password. -or Have a password file setup. This requires the use of the "orapwd" command and the initialization parameter "remote_login_passwordfile". --As a comment, you can start RMAN from any PROD server using: rman catalog=rman/rman@RMAN target=sys/passwd@PROD or rman connect target sys/mh_flyers@PROD connect rcvcat rman/rman@RMAN # then enter your RMAN commands here Then Register the Database: rman> register database

Once complete, the DBID, DB_NAME and structure are captured in the recovery catalog. To verify the registration run: rman> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------38 39 PROD 4283267716 YES 19688901 10-MAY-01 STEP 4 Back Up the Catalog and Synchronize All Databases If you lose your catalog, you can partially regenerate it from the information in the control file, but you should avoid that predicament by backing it up. You can use RMAN to back up the catalog by creating a recovery-catalog schema in one of your other instances, using that as the catalog for your primary catalog instance. Providing that these two instances do not share any common resources, this role reversal is free from single points of failure. It's important that your recovery catalog has an up-to-date view of your database. When you execute RMAN operations on the database, RMAN automatically synchronizes the catalog with the target. However, depending on the volatility of your database, you may need to resynchronize the catalog more frequently. Always include catalog resynchronization as part of any structural database change (the addition of files, tablespaces, and so on) and ensure that a resynchronization occurs at intervals less than the init.ora setting for the parameter CONTROL_FILE_RECORD_KEEP_TIME. To perform this action, issue the RESYNC CATALOG command from within RMAN.

STEP 5 Setup RMAN Settings You can always setup the settings from the OEM Console: DB Home Page/Maint Property / Backup and Recovery. This settings are specified only one time. Use the following command to check your settings once you connect: rman target / catalog=rman/rman@RMAN rman> show all; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/9.2.0/dbs/snapcf_ORA920.f'; # default rman> show all; CONFIGURE RETENTION POLICY TO REDUNDANCY 2; #Keep at least two copies of each datafile and controlfile backup. #This determines which backups and copies are eligible for deletion because they are no longer needed. # Note that when configuring a retention policy, RMAN will not cause backups to be automatically deleted. #The retention policy will, however, mark backups as OBSOLETE that have fallen outside the retention period. #RMAN commands like "REPORT OBSOLETE" and "DELETE OBSOLETE" will work with these obsolete backups. CONFIGURE BACKUP OPTIMIZATION OFF; # default #If we turn this command ON, then RMAN will not backup already backuped READ ONLY

tablespaces CONFIGURE DEFAULT DEVICE TYPE TO DISK; #By Default save all the Backups to disk CONFIGURE CONTROLFILE AUTOBACKUP ON; #Performs backup of controlfile and spfile to the same backup piece each time a backup is performed (by default will go to the FRA) CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/some_location/%F'; #Performs Backups on that place instead of the Flash Recovery Area, # The "%F" in the file name translates into c-IIIIIIIIII-YYYYMMDD-QQ, where: * IIIIIIIIII - stands for the DBID. (The DBID is printed in decimal so that it can be easily associated with the target database. * YYYYMMDD - is a time stamp in the Gregorian calendar of the day the backup is generated. * QQ - is the sequence in hexadecimal number that starts with 00 and has a maximum of 'FF' (256). CONFIGURE DEVICE TYPE DISK PARALLELISM 2; #By default put 2 channels per backup: CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024 M; #Device Type Format: This specifies the location and name of the backup files. We need to specify the format for each channel. The "%U" ensures that Oracle appends a unique identifier to the backup file name. The MAXPIECESIZE (optional) attribute sets a maximum file size for each file in the backup set. CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/some_location/snapcf_ORA920.f'; # Where to create the snapshot file for resync CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; (10g only) Governs archived redo log deletion policy for the flash recovery area. Possible options : APPLIED ON STANDBY - enables flash recovery area to delete archivelogs that are applied on mandatory standby. NONE - enables flash recovery area to delete archivelogs that are backed up to tertiary device and that are obsolete based on the configured backup retention policy. This is the default configuration. CLEAR - clears the deletion policy and returns the specified configuration to default value. The default value is NONE. By default, archived redo log files in a FRA that were backed up to a tertiary device or made obsolete (as defined by the RMAN retention policy) are eligible for deletion. Examples of the CONFIGURE ARCHIVELOG DELETION POLICY Command: When backups of archived redo log files are taken on the standby database: 1. Issue the following command on the primary database: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; 2. Issue the following command on the standby database: CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; When backups of archived redo log files are taken on the primary database: 1. Issue the following command on the standby database: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; 2. Issue the following command on the primary database: CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Reconfiguring the Deletion Policy After a Role Transition : After a switchover or failover, you may need to reissue the RMAN CONFIGURE ARCHIVELOG DELETION POLICY command on each database. If the backup site for archived redo log files remains the same, then do nothing. Otherwise, you must switch the archivelog deletion policy by issuing the CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY statement on the database where backups are not taken, and issuing the CONFIGURE ARCHIVELOG DELETION POLICY TO NONE statement on the database where backups are taken. Viewing the Current Deletion Policy To view the current setting (APPLIED ON STANDBY, CLEAR, NONE) for a database,issue the following query: SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%'; NAME VALUE ----------------------------- -------------ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY You can also find the existing configuration using the RMAN SHOW ARCHIVELOG DELETION POLICY command: RMAN> SHOW ARCHIVELOG DELETION POLICY RMAN configuration parameters are: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

Other RMAN Commands #Backup Some tablespaces only: rman> backup tablespace users, tools; rman> backup tablespace SYSTEM format '/u01/oracle/db/AKI1/bck/ora_df%t_s%s_s%p'; #Backup a datafile and tablespace and database rman>backup as copy datafile 1; rman>backup as copy tablespace system; #Also backup the Archve log Files: rman>backup ....... plus archivelog; #Backup all the archive log Files: rman> backup archivelog all; #Backup all the archive log Files and delete them from their location: rman> backup archivelog all delete all input; #Backup current control file to specific place: rman> backup current controlfile to '/.../....';

Scripting your Backups To save a script into the catalog you can use: create script prod_full_backup { # backup the complete database to disk, backup all Arch Logs and delete them backup database plus archivelog tag="Full_Database" format '/data/archdata/DBbackup/%d_t%t_s%s_p%p';

sql "alter system archive log current"; backup archivelog all delete all input; } To Drop it from RMAN just perform: delete script script_name; To Execute it from RMAN just perform: run {execute script prod_full_backup;} To read the code from the Database you can run the following query: select text from rc_stored_script_line where script_name='prod_full_backup'; Step 7 (optional) - You can create a Unix Script That will call the saved script in RMAN We want to run it every Sunday night as a scheduled job. Let's run it as a cron job. Create a Korn shell script called "rman_backup.ksh". This shell script will run the RMAN script, prod_full_backup.rcv. #!/bin/ksh # Shell script to run RMAN script prod_full_backup.rcv # Logging messages to prod_full_backup.log # Set environment variables export ORACLE_SID=PROD export ORACLE_HOME=/usr/local/OraHome1 # Connect to RMAN and run the backup script (all in one line) rman target / rcvcat rman/rman@rman cmdfile /home/oracle/script/rman_prod_full_backup.rcv msglog /home/oracle/script/rman_full_backup.log exit Change permissions on the shell script appropriately. chmod 755 rman_backup.ksh Now, create the RMAN script file, prod_full_backup.rcv. This just runs the previously stored catalog script, prod_full_backup. Here are the contents of prod_full_backup.rcv run {execute script prod_full_backup;} Finally, schedule the shell script using the crontab. [prod-server:oracle] $ crontab -e 00 21 * * 0 /home/oracle/script/rman_backup.ksh We have scheduled our script to run every Sunday night at 9:00 PM. <!--[if !supportLineBreakNewLine]--> Query RMAN LIST (no catalog needed) -> List Backups and DB Incarnations REPORT(no catalog needed) -> Shows files that needs backups, backups that are obsolete PRINT SCRIPT (use catalog) -> names of the scripts in the catalog Recovery Full DB This example shows how to restore all of the datafiles of the target database. RMAN will go to its last good backup set and restore the datafiles to the state they were in when that backup set was created. When restoring database files with Oracle9i, RMAN reads the datafile header and makes the determination as to whether the file needs to be restored. The recovery is done by allocating a channel for I/O and then issuing the RMAN restore database command. The database must not be open when restoring or recovering the entire database. SQL> startup mount; or RMAN> startup force mount;

then connect to rman and perform: RMAN> restore database; RMAN> recover database; RMAN> alter database open; Recovery from missing or corrupted datafile(s): This scenario deals with a situation where a datafile has gone missing, or is corrupted beyond repair. Note that if it is the system tablespace datafiles to be restored, the database must be closed. It is not possible to offline the system tablespace. Example, you get the following error message: ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01110: data file 4: 'D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF' The error message tells us that file# 4 is missing. The DB can be in mount state, thus, the database control file, which is also the RMAN repository can be accessed by the instance and by RMAN. We now recover the missing file using RMAN. The transcript of the recovery session is reproduced below : --logon to RMAN --restore missing datafile RMAN> restore datafile 4; --recover restored datafile - RMAN applies all logs automatically RMAN> recover datafile 4; --open database for general use RMAN> alter database open; database opened In the previous scenario, the database is already in the mount state before the RMAN session is initiated. If the database is not mounted, you should issue a "startup mount" command before attempting to restore the missing datafile. The database must be mounted before any datafile recovery can be done. If the database is already open when datafile corruption is detected, you can recover the datafile without shutting down the database. The only additional step is to take the relevant tablespace offline before starting recovery. In this case you would perform recovery at the tablespace level. The commands are: --offline affected tablespace RMAN> sql 'alter tablespace USERS offline immediate'; using target database controlfile instead of recovery catalog sql statement: alter tablespace USERS offline immediate --recover offlined tablespace RMAN> recover tablespace USERS; --online recovered tablespace RMAN> sql 'alter tablespace USERS online'; (b) Tablespace recovery RMAN> sql "alter tablespace users offline immediate"; RMAN> restore tablespace users; RMAN> recover tablespace users; RMAN> sql "alter tablespace users online"; Recovery from block corruption It is possible to recover corrupted blocks using RMAN backups. This is a somewhat exotic scenario, but it can be useful in certain circumstances, as illustrated by the following example. Here's the situation: a user connected to SQLPlus gets a data block corruption error when she queries a table. Corruption can be reported in alert logs, trace files or results of SQL queries..

Here's a part of the session transcript: select count(*) from test_table; * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 4, block # 2015) ORA-01110: data file 4: 'D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF' Since we know the file and block number, we can perform block level recovery using RMAN. This is best illustrated by example: --restore AND recover specific block RMAN> blockrecover datafile 4 block 2015; A couple of important points regarding block recovery: 1. Block recovery can only be done using RMAN. 2. The entire database can be open while performing block recovery. 3. Check all database files for corruption. This is important - there could be other corrupted blocks. Verification of database files can be done using RMAN or the dbverify utility. To verify using RMAN simply do a complete database backup with default settings. If RMAN detects block corruption, it will exit with an error message pointing out the guilty file/block.

Recovery from missing or corrupted redo log group: Case 1: A multiplexed copy of the missing log is available. If a redo log is missing, it should be restored from a multiplexed copy, if possible. This is the only way to recover without any losses. Here's an example, where I attempt to startup from SQLPlus when a redo log is missing: SQL> startup ORACLE instance started. Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: 'D:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG' To fix this we simply copy REDO03A.LOG from its multiplexed location on E: to the above location on E:. After copying the file, we issue an "alter database open" from the above SQLPlus session: SQL> alter database open; Database altered. That's it - the database is open for use. Case 2: All members of a log group lost. In this case an incomplete recovery is the best we can do. We will lose all transactions from the missing log and all subsequent logs. We illustrate using the same example as above. The error message indicates that members of log group 3 are missing. We don't have a copy of this file, so we know that an incomplete recovery is required. The first step is to determine how much can be recovered. In order to do this, we query the V$LOG view (when in the mount state) to find the system change number (SCN) that we can recover to (Reminder: the SCN is a monotonically increasing number that is incremented whenever a commit is issued): --The database should be in the mount state for v$log access SQL> select first_change# from v$log where group#=3 ; FIRST_CHANGE# -------------

370255 The FIRST_CHANGE# is the first SCN stamped in the missing log. This implies that the last SCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest SCN that we can recover to. In order to do the recovery we must first restore ALL datafiles to this SCN, followed by recovery (also up to this SCN). This is an incomplete recovery, so we must open the database resetlogs after we're done. Here's a transcript of the recovery session (typed commands in bold, comments in italics, all other lines are RMAN feedback): --Restore ENTIRE database to determined SCN RMAN> restore database until scn 370254; --Recover database RMAN> recover database until scn 370254; --open database with RESETLOGS (see comments below) RMAN> alter database open resetlogs; The following points should be noted: 1. The entire database must be restored to the SCN that has been determined by querying v$log. 2. All changes beyond that SCN are lost. This method of recovery should be used only if you are sure that you cannot do better. Be sure to multiplex your redo logs, and (space permitting) your archived logs! 3. The database must be opened with RESETLOGS, as a required log has not been applied. This resets the log sequence to zero, thereby rendering all prior backups worthless. Therefore, the first step after opening a database RESETLOGS is to take a fresh backup. Note that the RESETLOGS option must be used for any incomplete recovery.

Recovery from missing or corrupted control file: Case 1: A multiplexed copy of the control file is available. On startup Oracle must read the control file in order to find out where the datafiles and online logs are located. Oracle expects to find control files at locations specified in the CONTROL_FILE initialisation parameter. The instance will fail to mount the database if any one of the control files are missing or corrupt. A brief error message will be displayed, with further details recorded in the alert log. The exact error message will vary depending on what has gone wrong. Here's an example: SQL> startup ORACLE instance started. ORA-00205: error in identifying controlfile, check alert log for more info On checking the alert log, as suggested, we find the following: ORA-00202: controlfile: 'e:\oracle_dup_dest\controlfile\ORCL\control02.ctl' ORA-27046: file size is not a multiple of logical block size OSD-04012: file size mismatch (OS 5447783) The above corruption was introduced by manually editing the control file when the database was closed. The solution is simple, provided you have at least one uncorrupted control file - replace the corrupted control file with a copy using operating system commands. Remember to rename the copied file. The database should now start up without any problems. Case 2: All control files lost What if you lose all your control files? In that case you have no option but to use a backup control file. The recovery needs to be performed from within RMAN, and requires that all logs (archived and current online logs) since the last backup are available. The logs are required

because all datafiles must also be restored from backup. The database will then have to be recovered up to the time the control files went missing. This can only be done if all intervening logs are available. Here's an annotated transcript of a recovery session (as usual, lines in bold are commands to be typed, lines in italics are explanatory comments, other lines are RMAN feedback): -- Connect to RMAN C:\>rman target / connected to target database: ORCL (not mounted) -- set DBID - get this from the name of the controlfile autobackup. -- For example, if autobackup name is -- CTL_SP_BAK_C-1507972899-20050124-00 the the DBID is -- 1507972899. This step will not be required if the instance is started up from RMAN RMAN> set dbid 1507972899 executing command: SET DBID --restore controlfile from autobackup. The backup is not at the default --location so the path must be specified RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050124-00'; Starting restore at 26/JAN/05 using channel ORA_DISK_1 channel ORA_DISK_1: restoring controlfile channel ORA_DISK_1: restore complete replicating controlfile input filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTL output filename=E:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL02.CTL output filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTL Finished restore at 26/JAN/05 -- Now that control files have been restored, the instance can mount the -- database. RMAN> mount database; database mounted -- All datafiles must be restored, since the controlfile is older than the current -- datafiles. Datafile restore must be followed by recovery up to the current log. RMAN> restore database; --Database must be recovered because all datafiles have been restored from backup RMAN> recover database; -- Recovery completed. The database must be opened with RESETLOGS -- because a backup control file was used. Can also use -- "alter database open resetlogs" instead. RMAN> open resetlogs database; Several points are worth emphasising. 1. Recovery using a backup controlfile should be done only if a current control file is unavailable. 2. All datafiles must be restored from backup. This means the database will need to be recovered using archived and online redo logs. These MUST be available for recovery until the time of failure. 3. As with any database recovery involving RESETLOGS, take a fresh backup immediately. 4. Technically the above is an example of complete recovery - since all committed transactions were recovered. However, some references consider this to be incomplete recovery because the database log sequence had to be reset.

After recovery using a backup controlfile, all temporary files associated with locally-managed tablespaces are no longer available. You can check that this is so by querying the view V$TEMPFILE - no rows will be returned. Therefore tempfiles must be added (or recreated) before the database is made available for general use. In the case at hand, the tempfile already exists so we merely add it to the temporary tablespace. This can be done using SQLPlus or any tool of your choice: SQL> alter tablespace temp add tempfile 'D:\oracle_data\datafiles\ORCL\TEMP01.DBF'; Check that the file is available by querying v$TEMPFILE. Disaster recovery – A situation in which your database server has been destroyed and has taken all your database files (control files, logs and data files) with it. Obviously, recovery from a disaster of this nature is dependent on what you have in terms of backups and hardware resources. We assume you have the following available after the disaster: The last full hot backup on tape. It is possible to recover all data up to the last full backup. One can do better if subsequent archive logs (after the last backup) are available. In our case these aren't available, since our only archive destination was on the destroyed server . Oracle provides methods to achieve better data protection. We will discuss some of these towards the end of the article. Now on with the task at hand. The high-level steps involved in disaster recovery are: Build replacement server. Restore backup from tape. Install database software. Create Oracle service. Restore and recover database. It sounds quite straightforward and it is reasonably so. However, there are some details that are often missed in books and documentation. The devil, as always, is in these details. Here we hope to provide you with enough detail to plan and practice disaster recovery in your test environment. Build the server You need a server to host the database, so the first step is to acquire or build the new machine. This is not strictly a DBA task, so we won't delve into details here. The main point to keep in mind is that the replacement server should, as far as possible, be identical to the old one. In particular, pay attention to the following areas: Disk layout and capacity: Ideally the server should have the same number of disks as the original. This avoids messy renaming of files during recovery. Obviously, the new disks should also have enough space to hold all software and data that was on the original server. Operating system, service pack and patches: The operating system environment should be the same as the original, right up to service pack and patch level. Memory: The new server must have enough memory to cater to Oracle and operating system / other software requirements. Oracle memory structures (Shared pool, db buffer caches etc) will be sized identically to the original database instance. Use of the backup server parameter file will ensure this. Although you probably won't build and configure the machine yourself. It is important to work with your systems people so that the above items are built to the recovery server specs. Restore backup from tape The next step is to get your backup from tape on to disk. In our example from Part I, the directory to be restored is e:\backup. The details of this depend on the backup product used, so we can't go into it any further. This task would normally be performed your local sysadmin. Install Oracle Software

Now we get to the meat of the database recovery process. The next step is to install Oracle software on the machine. The following points should be kept in mind when installing the software: Install the same version of Oracle as was on the destroyed server. The version number should match right down to the patch level, so this may be a multi-step process involving installation followed by the application of one or more patchsets and patches. Do not create a new database at this stage. Create a listener using the Network Configuration Assistant. Ensure that it has the same name and listening ports as the original listener. Relevant listener configuration information can be found in the backed up listener.ora file. Create directory structure for database files After software installation is completed, create all directories required for datafiles, (online and archived) logs, control files and backups. All directory paths should match those on the original server. This, though not mandatory, saves additional steps associated with renaming files during recovery. Don't worry if you do not know where the database files should be located. You can obtain the required information from the backup spfile and control file at a later stage. Continue reading we'll come back to this later. Create Oracle service As described in section 2 of Part II, an Oracle service must be exist before a database is created. The service is created using the oradim utility, which must be run from the command line. The following commands show how to create and modify a service (comments in italics, typed commands in bold): --create a new service with manual startup C:\>oradim -new -sid ORCL -startmode m --modify service to startup automatically C:\>oradim -edit -sid ORCL -startmode a Unfortunately oradim does not give any feedback, but you can check that the service exists via the Services administrative panel. The service has been configured to start automatically when the computer is powered up. Note that oradim offers options to delete, startup and shutdown a service. See the documentation for details. Restore and recover database Now it is time to get down to the nuts and bolts of database recovery. There are several steps, so we'll list them in order: Copy password and tnsnames file from backup: The backed up password file and tnsnames.ora files should be copied from the backup directory (e:\backup, in our example) to the proper locations. Default location for password and tnsnames files are ORACLE_HOME\database ORACLE_HOME\network\admin respectively. Set ORACLE_SID environment variable: ORACLE_SID should be set to the proper SID name (ORCL in our case). This can be set either in the registry (registry key: HKLM\Software\Oracle\HOME<X>\ORACLE_SID) or from the system applet in the control panel.

Invoke RMAN and set the DBID: We invoke rman and connect to the target database as usual. No login credentials are required since we connect from an OS account belonging to ORA_DBA. Note that RMAN accepts a connection to the database although the database is yet to be recovered. RMAN doesn't as yet "know" which database we intend to connect to. We therefore need to identify the (to be restored) database to RMAN. This is done through the database identifier (DBID). The DBID can be figured out from the name of the controlfile backup. Example: if you use the controlfile backup format suggested in Part I, your controlfile backup name will be something like "CTL_SP_BAK_C-1507972899-20050228-00". In this case the DBID is 1507972899. Here's a transcript illustrating the process of setting the DBID: C:\>rman Recovery Manager: Release 9.2.0.4.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. RMAN> connect target / connected to target database (not started) RMAN> set dbid 1507972899 executing command: SET DBID RMAN> Restore spfile from backup: To restore the spfile, you first need to startup the database in the nomount state. This starts up the database using a dummy parameter file. After that you can restore the spfile from the backup (which has been restored from tape in Section 3). Finally you restart the database in nomount state. The restart is required in in order to start the instance using the restored parameter file. Here is an example RMAN transcript for the foregoing procedure. Note the difference in SGA size and components between the two startups: RMAN> startup nomount startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file 'C:\ORACLE\ORA92\DATABASE\INITORCL.ORA' trying to start the Oracle instance without parameter files ... Oracle instance started Total System Global Area 97590928 bytes Fixed Size 454288 bytes Variable Size 46137344 bytes Database Buffers 50331648 bytes Redo Buffers 667648 bytes RMAN> restore spfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00'; Starting restore at 01/MAR/05 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=9 devtype=DISK

channel ORA_DISK_1: autobackup found: e:\backup\CTL_SP_BAK_C-1507972899-2005022800 channel ORA_DISK_1: SPFILE restore from autobackup complete Finished restore at 01/MAR/05 RMAN> startup force nomount Oracle instance started Total System Global Area 1520937712 bytes Fixed Size 457456 bytes Variable Size 763363328 bytes Database Buffers 754974720 bytes Redo Buffers 2142208 bytes RMAN> The instance is now started up with the correct initialisation parameters. We are now in a position to determine the locations of control file and archive destination, as this information sits in the spfile. This is done via SQL Plus as follows: C:\>sqlplus /nolog ....output not shown SQL>connect / as sysdba Connected. SQL> show parameter control_file ....output not shown SQL> show parameter log_archive_dest ....output not shown The directories listed in the CONTROL_FILES and LOG_ARCHIVE_DEST_N parameters should be created at this stage if they haven't been created earlier. Restore control file from backup: The instance now "knows" where the control files should be restored, as this is listed in the CONTROL_FILES initialisation parameter. Therefore, the next step is to restore these files from backup. Once the control files are restored, the instance should be restarted in mount mode. A restart is required because the instance must read the initialisation parameter file in order to determine the control file locations. At the end of this step RMAN also has its proper configuration parameters, as these are stored in the control file. Here is a RMAN session transcript showing the steps detailed here: RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00'; Starting restore at 01/MAR/05 allocated channel: ORA_DISK_1 hannel ORA_DISK_1: sid=13 devtype=DISK channel ORA_DISK_1: restoring controlfile

channel ORA_DISK_1: restore complete replicating controlfile input filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTL output filename=E:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL02.CTL output filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTL Finished restore at 01/MAR/05 RMAN> shutdown Oracle instance shut down RMAN> exit Recovery Manager complete. C:\>rman target / Recovery Manager: Release 9.2.0.4.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database (not started) RMAN> startup mount; Oracle instance started database mounted Total System Global Area 1520937712 bytes Fixed Size 457456 bytes Variable Size 763363328 bytes Database Buffers 754974720 bytes Redo Buffers 2142208 bytes RMAN> show all; using target database controlfile instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'e:\backup\ctl_sp_bak_%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\ORA92\DATABASE\SNCFORCL.ORA'; # default RMAN>

At this stage we can determine the locations of data files and redo logs if we don't know where they should go. This is done from SQL Plus as follows: C:\>sqlplus /nolog ...output not shown SQL> connect / as sysdba Connected. SQL> select name from v$datafile; ...output not shown SQL> select member from v$logfile; ...output not shown SQL> The directories shown in the output should be created manually if this hasn't been done earlier. Restore all datafiles: This is easy. Simply issue a "restore database" command from RMAN, and it will do all the rest for you: RMAN> restore database; Starting restore at 01/MAR/05 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=11 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=8 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBF restoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS02.DBF channel ORA_DISK_2: starting datafile backupset restore channel ORA_DISK_2: specifying datafile(s) to restore from backup set restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF restoring datafile 00005 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF restoring datafile 00006 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS02.DBF channel ORA_DISK_2: restored backup piece 1 piece handle=E:\BACKUP\80G6E1TT_1_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 1 piece handle=E:\BACKUP\81G6E1TU_1_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_2: restored backup piece 2 piece handle=E:\BACKUP\80G6E1TT_2_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 2 piece handle=E:\BACKUP\81G6E1TU_2_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 3 piece handle=E:\BACKUP\81G6E1TU_3_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restore complete channel ORA_DISK_2: restored backup piece 3 piece handle=E:\BACKUP\80G6E1TT_3_1.BAK tag=TAG20041130T222501 params=NULL

channel ORA_DISK_2: restore complete Finished restore at 01/MAR/05 RMAN> Recover database: The final step is to recover the database. Obviously recovery is dependent on the available archived (and online) redo logs. Since we have lost our database server and have no remote archive destination, we can recover only up to the time of the backup. Further, since this is an incomplete recovery, we will have to open the database with resetlogs. Here's a sample RMAN session illustrating this: RMAN> recover database; Starting recover at 01/MAR/05 using channel ORA_DISK_1 using channel ORA_DISK_2 starting media recovery unable to find archive log archive log thread=1 sequence=1388 RMAN-00571: ============================== RMAN-00569: =ERROR MESSAGE STACK FOLLOWS = RMAN-00571: =============================== RMAN-03002: failure of recover command at 04/01/2005 14:14:43 RMAN-06054: media recovery requesting unknown log: thread 1 scn 32230460 RMAN> alter database open resetlogs; database opened RMAN> Note that RMAN automatically applies all available archive logs. It first applies the backed up log and then searches for subsequent logs in the archive destination. This opens the door for further recovery if the necessary logs are available. In our case, however, we have no more redo so we open the database with resetlogs. The error message above simply indicates that RMAN has searched, unsuccessfully, for subsequent logs. That's it. The database has been recovered, from scratch, to the last available backup. Now having done this, it is worth spending some time in discussing how one can do better - i.e. recover up to a point beyond the backup.