Care is needed for rman restores because they will normally overwrite existing datafiles; before taking any action it is imperative to understand why a restore is needed and how to proceed.
In our opinion it is better to explain basic rman concepts with understandable examples.
Example 1: a restoration is needed because a datafile is lost.
1. In order to restore a database or a data file some kind of backup must have been taken; in our exaple, let's suppose that our database consists of three datafiles and that a backup is taken on Mar 10th 2005 in the afternoon.
 ">
The stand of the datafiles can differ because in general it is not guaranteed that the very last changes in the database have actually been written to disk. This is why the timestamps 15:09 and 15:15 have been used in the picture.
2. During the week archive log backups are taken daily, for example to tape using the command:
run {
allocate channel t1 type 'sbt_tape';
backup archivelog all delete input;
release channel t1;
}
3. A week later a disk crashes and the database file number 3 is lost:
In this example, it must be understood that only the DBFile3 has to be restored, without overwriting the datafiles that have not been affected by the crash, or a weeek's work would be lost.
The tablespace containing the damaged file should be put offline with the SQLPLUS command:
SQLPLUS / AS SYSDBA
ALTER TABLESPACE this_tbs OFFLINE IMMEDIATE;
rman target / catalog rman@MYCATALOG
rman> run {
allocate channel t1 type 'sbt_tape';
restore tablespace this_tbs;
release channel t1;
}
If we are sure that only the datafile 3 has been damaged and not the rest of the tablespace this_tbs, we could use instead:
rman> run {
allocate channel t1 type 'sbt_tape';
restore datafile 3;
release channel t1;
}
It is now obvious that we have a mish-mash of contents, with tablespace up-to-date and a tablespace my_tbs with contents as of one week before. In this situation, Oracle will refuse to bring the tablespace online, probably with the error message 'datafile 'DBFIle3' needs to be recovered'.
How is it possible to bring the tablespace my_tbs at the same stand as for the other tablespaces? It is possible because we have the archive logs backups, that contain all the changes to the database made between Mar 10th and Mar 17th.
The command needed is:
run {
allocate channel t1 type 'sbt_tape';
recover database;
release channel t1;
}
During the execution of this command, rman will restore the archived redo logs and apply them to the damaged tablespace. At the end of the process the tablespace can be brought online and the database is back to normal.
|
|
