RMAN RECOVERY

Performing Complete Database Recovery

how to use RMAN to return your database to normal operation after the loss of one or more datafiles.

Purpose of Complete Database Recovery

some or all of your datafiles are lost or damaged. Typically, this situation is caused by a media failure or
accidental deletion. Your goal is to return the database to normal operation by restoring the damaged files
from RMAN backups and recovering all database changes.

To see the corruption, run the backup validate database command from RMAN and
check the v$database_block_corrupton view.
RMAN> backup validate database;
( easy technique for determining which datafiles are missing is to run a VALIDATE DATABASE command)
SQL>

select * from v$database_block_corruption;

FILE#
BLOCK#
BLOCKS CORRUPTION_CHANGE# CORRUPTION
---------- ---------- ---------- ------------------ ---------5
13
1
0 CHECKSUM
6
13
1
0 CHECKSUM
4
69
1
0 CHECKSUM

RMAN> blockrecover datafile 5 block 13 datafile 6 block 13;

RMAN> backup validate datafile 4;

SQL> select * from v$database_block_corruption;
RMAN> blockrecover datafile 4 block 76;

To restore and recover the whole database:RMAN> CONNECT TARGET /

STARTUP MOUNT;
SHOW ALL;
RMAN>RESTORE DATABASE;
RMAN>RECOVER DATABASE;
ALTER DATABASE OPEN;

Performing Complete Recovery of a Tablespace :-

Start RMAN and connect to a target database.

If the database is open, then take the datafile requiring recovery offline.
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";

Use the SHOW command to see which channels are preconfigured.

SHOW ALL;
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";

If you are RESTORING SOME DATAFILES TO NEW LOCATIONS, then execute RESTORE
TABLESPACE and RECOVER TABLESPACE in a RUN command. Use the SET NEW_NAME to rename datafiles,
as described in "Restoring Datafiles to a Nondefault Location".
The following example restores the datafiles in tablespaces users to a new location, then performs
recovery. Assume that the Old Datafiles were stored in the /disk1 path and the New Ones will be stored
in the /disk2 path.
RUN
{
# specify the new location for each datafile
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users01.f' TO
'/disk2/users01.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users02.f' TO
'/disk2/users02.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users03.f' TO
'/disk2/users03.f';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;
# update control file with new filenames
RECOVER TABLESPACE users;
}
SQL "ALTER TABLESPACE users ONLINE";

Performing Block Media Recovery

How to restore and recover individual data blocks within a datafile

target database must run in ARCHIVELOG mode and be open or mounted with a current
control file
RMAN can use only archived redo logs for the recovery.

block corruption is reported in the following locations:

Results of the LIST FAILURE, VALIDATE, or BACKUP ... VALIDATE command

The V$DATABASE_BLOCK_CORRUPTION view
Error messages in standard output
The alert log
User trace files
Results of the SQL commands ANALYZE TABLE and ANALYZE INDEX
Results of the DBVERIFY utility
Third-party media management output

Obtain the datafile numbers and block numbers of the corrupted blocks
locate trace files and the alert log is to connect SQL*Plus to the target database and execute the following
query:
SELECT NAME, VALUE
FROM
V$DIAG_INFO;

Start RMAN and connect to the target database, which must be mounted or open
Run the SHOW ALL command to make sure that the appropriate channels are preconfigured.
Recovers two blocks.
RECOVER
DATAFILE 8 BLOCK 13
DATAFILE 2 BLOCK 19;

Performing RMAN Tablespace Point-in-Time Recovery

(TSPITR)
Recovery Manager (RMAN) automatic TSPITR enables you to quickly recover one or more tablespaces
in a database to an earlier time without affecting the rest of the tablespaces and objects in the database.

You want to recover data lost after DDL operations that change the structure of tables. You
cannot use Flashback Table to rewind a table to before the point of a structural change such as
a truncate table operation.

You want to recover a table after it has been dropped with the PURGE option.

You want to recover from the logical corruption of a table.

Recovering a NOARCHIVELOG Database with Incremental

Backups

Only consistent backups can be used in restoring a database in NOARCHIVELOG mode.

Media recovery is not possible because no archived redo logs exist.

To recover a NOARCHIVELOG database with incremental backups:

When recovering a NOARCHIVELOG database, specify the NOREDO option on the RECOVER command to
indicate that RMAN should not attempt to apply archived redo logs. Otherwise, RMAN returns an error.
After connecting to trgt and the catalog database, place the database in a mounted state:
STARTUP FORCE MOUNT

Restore and recover the database.

For example, you can perform incomplete recovery with the following commands:
RESTORE DATABASE
FROM TAG "consistent_whole_backup";
RECOVER DATABASE NOREDO;

Open the database with the RESETLOGS option.

ALTER DATABASE OPEN RESETLOGS;

Validating Database Files and Backups

Main purpose of RMAN validation is to check for corrupt blocks and missing files. You can also use
RMAN to determine whether backups can be restored. You can use the following RMAN commands to
perform validation:

VALIDATE
BACKUP ... VALIDATE
RESTORE ... VALIDATE

Checksums and Corrupt Blocks

A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to
find. Block corruptions can be caused by a number of different failures including, but not limited to the
following:

Faulty disks and disk controllers

Faulty memory
Oracle Database software defects

set DB_BLOCK_CHECKSUM=typical so that the database calculates datafile checksums automatically

You can use the VALIDATE command to manually check for physical and logical corruptions in database
files. This command performs the same types of checks as BACKUP VALIDATE, but VALIDATE can check a
larger selection of objects. For example, you can validate individual blocks with the VALIDATE DATAFILE
... BLOCK command.
If the backup validation discovers corrupt blocks, then RMAN updates the
V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions
Start RMAN and connect to a target database.
Execute the VALIDATE command with the desired options.
For example, to validate all datafiles and control files (and the server parameter file if one is in
use), execute the following command at the RMAN prompt:
RMAN> VALIDATE DATABASE;

Alternatively, you can validate a particular backup set by using the form of the command shown
in the following example (sample output included).
RMAN> VALIDATE BACKUPSET 22;

The following example illustrates how you can check individual data blocks within a datafile for
corruption.
RMAN> VALIDATE DATAFILE 1 BLOCK 10;

validate files with the BACKUP VALIDATE command:

Start RMAN and connect to a target database and recovery catalog (if used).
Run the BACKUP VALIDATE command.
you can validate that all database files and archived logs can be backed up by running a command
as shown in the following example. This command checks for physical corruptions only.
BACKUP VALIDATE
DATABASE
ARCHIVELOG ALL;

To check for logical corruptions in addition to physical corruptions, run the following variation of
the preceding command:
BACKUP VALIDATE
CHECK LOGICAL
DATABASE
ARCHIVELOG ALL;