LOSS OF DATAFILES FOR WHICH BACKUP IS NOT AVAILABLE
Note: Database is in ARCHIVELOG mode
Case (a) – Current Control File Exists
IF A DATAFILE IS LOST DUE TO MEDIA FAILURE WHICH WAS CREATED/ADDED, AFTER THE TIME OF LAST BACKUP, THE DATAFILE CAN BE RECREATED IF WE HAVE
the Backup control file has an entry for the new file added.
(this is done by issuing any of the following commands….)
SVRMGR> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
SVRMGR> ALTER DATABASE BACKUP CONTROLFILE TO 'FILENAME';
AND
Restore ONLY the datafiles (those that have been lost or damaged) from the last hot or cold backup. The current online redo logs and control file(s) must be intact.
SVRMGR> STARTUP MOUNT;
SVRMGR> ALTER DATABASE CREATE DATAFILE '/dsk01/ORACLE/reco/lost.dbf';
Note:
The datafile can be created with a different filename to the original. This option might be chosen if the original file was lost due to disk failure and the failed disk was still unavailable; the new file would then be created on a different device.
For example,
SVRMGR> alter database create datafile
2>
'/dev1/oracle/dbs/testtbs.dbf'3>
as4>
'/dev2/oracle/dbs/testtbs.dbf';Statement processed.
The above command creates a new datafile on the dev2 device. The file is created using information, stored in the control file, from the original file. The command implicitly renames the filename in the control file.
SVRMGR> RECOVER DATAFILE '/dsk01/ORACLE/reco/lost.dbf';
(Apply Archived Redo log files)
SVRMGR> ALTER DATABASE OPEN;
Case (b) – Current Control File DOES NOT Exist
A valid (either hot or cold) backup of the datafiles exists, except for the datafile created since the backup was taken. The controlfile is a backup from before the creation of the new datafile. The database is in archivelog mode
Restore the datafiles (those that have been lost or damaged) from the last hot or cold backup. Also restore the old copy of the controlfile. The current online redo logs must be intact.
SVRMGR> RECOVER DATABASE USING BACKUP CONTROLFILE;
ORA-00279: change 211116 generated at 03/08/00 11:53:54 needed for thread 1
ORA-00289: suggestion : /sp105db04/ORACLE/rman/arch/arch36.log
ORA-00280: change 211116 for thread 1 is in sequence #36
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to controlfile by media recovery
ORA-01110: data file 6: '/sp105db04/ORACLE/rman/users02.dbf'
SVRMGR> select name from v$datafile where file#=6;
NAME
--------------------------------------------------------------------------------
/opt/oracle/product8/dbs/UNNAMED00006
1 row selected.
SVRMGR>
alter database create datafile'/opt/oracle/product8/dbs/UNNAMED00006'
as
'/sp105db04/ORACLE/rman/users02.dbf';
Statement processed.
SVRMGR> RECOVER DATABASE USING BACKUP CONTROLFILE;
Apply archived logs as requested. Eventually, Oracle will request the archived log corresponding to the current online log. It does this because the (backup) controlfile has no knowledge of the current log sequence. If an attempt is made to apply the suggested log, the recovery session will exit with the following message:
ORA-00308: cannot open archived log '/sp105db04/ORACLE/rman/arch/arch41.log'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
SVRMGR> SELECT MEMBER FROM V$LOGFILE;
MEMBER
1 /sp105db04/ORACLE/rman/redo01.log
2 /sp105db04/ORACLE/rman/redo02.log
3 /sp105db04/ORACLE/rman/redo03.log
3 rows selected.
At this stage, simply restart the recovery session and apply the current online log. The best way to do this is to try applying the online redo logs one by one until Oracle completes media recovery:
SVRMGR> recover database using backup controlfile;
ORA-00279: change 211213 generated at 03/08/00 12:07:56 needed for thread 1
ORA-00289: suggestion : /sp105db04/ORACLE/rman/arch/arch41.log
ORA-00280: change 211213 for thread 1 is in sequence #41
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/sp105db04/ORACLE/rman/redo01.log
Log applied.
Media recovery complete.
SVRMGR> alter database open resetlogs;