RMAN Restore and Recovery Chapter 19 RMAN Restore and Recovery

Introduction to RMAN Restore and Recovery Prior two chapters prepares you to be able to perform perhaps the most critical DBA tasks: restore and recovery of a damaged mission critical database. Good news is that RMAN automates much of the restore and recovery process.

Determining Media Recovery Required Media recovery error is thrown when Oracle can’t read or write to a critical database file: ORA-01157: cannot identify/lock data file 1 - see DBWR trace file ORA-01110: data file 1: '/u02/oracle/oradata/E64208/system01.dbf'

Performing Media Recovery Determine what files need to be restored. Depending on the damage, set your database mode to nomount, mount, or open. Use the RESTORE command to retrieve files from RMAN backups. Use the RECOVER command for datafiles requiring recovery. Open your database.

Using Data Recovery Advisor Listing failures: RMAN> list failure; Suggesting corrective action: RMAN> advise failure 665; Running commands to repair failures: RMAN> repair failure;

Using RMAN to Shutdown/Startup You can use RMAN to shutdown and startup your database. Many times during a restore and recovery scenario, it’s easier to use RMAN top stop/start your database. RMAN> shutdown immediate; RMAN> ..... RMAN> startup;

Previewing Backups Used for Recovery Use the RESTORE...PREVIEW command to list the backups and archive redo log files that RMAN will use to restore and recover database datafiles. The RESTORE...PREVIEW does not actually restore any files. RMAN> restore database preview; RMAN> restore database preview summary;

Validating Backup Files Before Restoring Instruct RMAN to verify that the files exist and check the file headers, the use the RESTORE...VALIDATE HEADER command like so:   RMAN> restore database validate header; Further instruct RMAN to verify the integrity of blocks within backup files required to restore the database datafiles via the RESTORE...VALIDATE command: RMAN> restore database validate;

Testing Media Recovery Instruct RMAN to verify the recovery process via the RECOVER...TEST command: RMAN> connect target / RMAN> startup mount; RMAN> restore tablespace users; RMAN> recover tablespace users test;

Restoring Entire Database Using Current Control File This example assumes that you haven’t lost the control files as part of the media failure: RMAN> connect target / RMAN> startup mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open;

Restoring Entire Database Using Backup Control File This example assumes that you have lost the current control files as part of the media failure: RMAN> connect target / RMAN> startup nomount; RMAN> restore controlfile from autobackup; RMAN> alter database mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open resetlogs;

Restoring Tablespace While Database is Open Do this is you have an isolated tablespace that needs its datafiles to be restored and recovered: RMAN> connect target / RMAN> sql 'alter tablespace users offline immediate'; RMAN> restore tablespace users; RMAN> recover tablespace users; RMAN> sql 'alter tablespace users online';

Restoring Tablespace While Database in Mount Mode You can also restore tablespace datafiles while the database is in mount mode: RMAN> connect target / RMAN> shutdown immediate; RMAN> startup mount; RMAN> restore tablespace system; RMAN> recover tablespace system; RMAN> alter database open;

Restoring Read-Only Tablespaces RMAN will restore read-only tablespaces along with the rest of the database when you issue a RESTORE DATABASE command: RMAN> restore database; This is different in versions prior to 11g where you had to specify that read-only tablespaces were restored.

Restoring Temporary Tablespaces RMAN doesn’t backup temporary tablespaces. Starting with Oracle Database 10g, you don’t have to restore or re-create missing locally managed temporary tablespace tempfiles. When you open your database for use, Oracle automatically detects and re-creates locally managed temporary tablespace tempfiles.

Restoring Datafile While Database Is Open Use the RESTORE DATAFILE and RECOVER DATAFILE commands to restore and recover at the datafile level. When your database is open, you’re required to take offline any datafiles you’re attempting to restore and recover. RMAN> sql 'alter database datafile 32, 33 offline'; RMAN> restore datafile 32, 33; RMAN> recover datafile 32, 33; RMAN> sql 'alter database datafile 32, 33 online';

Restoring Datafile While Database Is Not Open You can only restore the system datafile while the database is not open: RMAN> connect target / RMAN> shutdown abort; RMAN> startup mount; RMAN> restore datafile 1; RMAN> recover datafile 1; RMAN> alter database open;

Restoring Datafiles to Non-Default Locations Sometimes a failure will occur that renders the disks associated with a mount point inoperable. In situations like this, you will need to restore and recover the datafiles to a different location from where they originally resided. RMAN> connect target / RMAN> startup mount; RMAN> run{ 2> set newname for datafile 32 to '/ora02/dbfile/O11R2/mvdata01.dbf'; 3> set newname for datafile 33 to '/ora02/dbfile/O11R2/mvindex01.dbf'; 4> restore datafile 32, 33; 5> switch datafile all; # Updates repository with new datafile location. 6> recover datafile 32, 33; 7> alter database open; 8> }

Performing Block Level Recovery Block-level corruption is rare and is usually caused by some sort of I/O error. However, if you do have an isolated corrupt block within a large datafile, it’s nice to have the option of performing a block-level recovery. Block-level recovery is useful when a small number of blocks are corrupt within a datafile. Block recovery is not appropriate if the entire datafile needs media recovery. RMAN> recover datafile 5 block 20;

Restoring Archive Redo Logs to the Default Location RMAN will automatically restore any archived redo log files that it needs during a recovery process. You normally don't need to manually restore archived redo log files. However, if you need to, you can restore all via: RMAN> restore archivelog all;

Restoring Archive Redo Logs to the Non-Default Location Sometimes the default location may not be available (due to media failure) or it may not have enough room. Use SET ARCHIVELOG DESTINATION RMAN> run{ 2> set archivelog destination to '/ora01/archtemp'; 3> restore archivelog from sequence 68 force; 4> }

Restoring the Spfile RMAN allows you to restore the spfile You may have one of the following scenarios: You accidentally set a value in the spfile that keeps your instance from starting. You accidentally deleted the spfile. You are required to see what it looked like at some time in the past. If you are using a recovery catalog, it’s a fairly simple procedure to restore the spfile: RMAN> connect target / RMAN> connect catalog rmancat/foo@rcat RMAN> startup nomount; RMAN> restore spfile;

Restoring a Control File Using a Recovery Catalog If you lose all of your control files, then you’ll need to restore one from a backup: RMAN> connect target / RMAN> connect catalog rcat/rcat@recov RMAN> startup nomount; RMAN> list backup of controlfile;

Restoring a Control File Using an Autobackup Restore If you’re using the autobackup of the control file feature, it’s fairly simple to restore a control file: RMAN> connect target / RMAN> startup nomount; RMAN> restore controlfile from autobackup;

Performing Time-Based Recovery Incomplete Recovery Time based is appropriate when you have a specific time in the past you’d like to reset the database to: RMAN> connect target / RMAN> startup mount; RMAN> restore database until time 2> "to_date('04-sep-2010 14:00:00', 'dd-mon-rrrr hh24:mi:ss')"; RMAN> recover database until time RMAN> alter database open resetlogs;

Performing Log Sequenced-Based Recovery Incomplete Recovery Use this type of incomplete recovery when you’re missing an archive log or required online redo log: RMAN> connect target / RMAN> startup mount; RMAN> restore database until sequence 45; RMAN> recover database until sequence 45; RMAN> alter database open resetlogs;

Performing Change/SCN-Based Incomplete Recovery If you know the SCN number to which you’d like to restore to in the past, then use SCN-based incomplete recovery: RMAN> connect target / RMAN> startup mount; RMAN> restore database until scn 95019865425; RMAN> recover database until scn 95019865425; RMAN> alter database open resetlogs;

Restoring to a Restore Point RMAN also allows you to restore back to a restore point: RMAN> connect target / RMAN> startup mount; RMAN> restore database until restore point MY_RP; RMAN> recover database until restore point MY_RP; RMAN> alter database open resetlogs;

Table Level Restore New in Oracle Database 12c, table level restore Allows you to use RMAN to restore a table based on SCN, time, or log sequence number Consider using flashback table to restore a table instead of RMAN table level restore

Flashing Back a Table Flashback to before drop (uses recyclebin) Flashback to prior point in time (uses undo)

Flashback Database Another form of incomplete recovery Often used as a mechanism to set a database back to a prior state Prior to an application upgrade, create a restore point, if the application upgrade goes bad, flashback database to the restore point

Restoring and Recovering to Different Server Create an RMAN backup on the originating database. Copy RMAN backup to the destination server. All steps after this step are performed on the destination database server. Ensure that Oracle is installed. Source the required OS variables. Create an init.ora file for the database to be restored. Create any required directories for datafiles, control files, and dump/trace files. Startup the database in NOMOUNT mode. Restore a control file from the RMAN backup. Startup the database in MOUNT mode. Make the control file aware of the location of the RMAN backups. Rename and restore the datafiles to reflect new directory locations. Recover the database. Set the new location for the online redo logs. Open the database. Add tempfile. Rename the database.

Summary RMAN automates most of the restore and recovery tasks. Very flexible in ways to perform complete and incomplete recovery. Arguably restore and recovery are the most critical skills a DBA can posses.