041225

使用RMAN恢复非归档模式的数据库
rman target /
RMAN> STARTUP MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

使用RMAN进行归档模式下的恢复
rman target /
RMAN> STARTUP MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

使用RMAN恢复文件到新的位置
使用 SET NEWNAME 命令恢复文件到新的位置
SET NEWNAME FOR DATAFILE 1 to 
   ‘/<newdir>/system01.dbf’;

使用 SWITCH 命令记录更改在控制文件
SWITCH DATAFILE ALL;

Restoring Datafiles to a New Location
If you have experienced media failure such as the loss of a disk drive, you may need to
restore the datafiles to a new location.
Example
1. Connect to RMAN.
 rman target
2. Mount the database.
 RMAN> STARTUP MOUNT
3. Use RMAN to restore the datafile to the new location and record the change in the control file.
 run{
 set newname for datafile 1 to ?<newdir>/system01.dbf?...
 restore database;
 switch datafile all;
 recover database;
 alter database open; }

恢复表空间
Using RMAN to Recover a Tablespace
If you have determined that you need to restore and recover the users tablespace, issue the RMAN commands as follows:
 run{
 sql ‘alter tablespace users offline immediate’
 restore tablespace users;
 recover tablespace users;
 sql ‘alter tablespace users online’
 }

There are three types of incomplete recovery:
Time-based recovery
Cancel-based recovery
Change-based recovery

RECOVER Command Overview
1.Recover a database until cancel:
RECOVER DATABASE until cancel
2.Recover a database until time:
RECOVER DATABASE
until time '2002-07-24:14:22:03'
3.Recover using backup control file: 
RECOVER DATABASE
until time '2002-07-24:14:22:03'
using backup controlfile

使用using backup controlfile子句，那么一定要使用until语句

Incomplete Recovery Using UNTIL TIME
Shut down the database and begin recovery. Because the approximate time of the failure is known and the database structure has not changed since 11:44 a.m., you can use the UNTIL TIME method:
1. If the database is open, shut it down by using either the NORMAL, IMMEDIATE, or TRANSACTIONAL options.
2. Restore all datafiles from backup (the most recent if possible). You may need to restore archived logs. If there is enough space available, restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> or SET LOGSOURCE <LOCATION> to change the location.
3. Mount the database.

Incomplete Recovery Using UNTIL TIME (continued)
4. Recover the database:
 SQL> recover database until time '2002-03-09:11:44:00'
 ORA-00279: change 148448 …03/09/02 17:04:20 needed for thread ORA-00289: suggestion : /disk1/archive/arch_6 .rdo
 ORA-00280: change 148448 for thread 1 is in sequence #6 Log applied....
 Media recovery complete.
5. To synchronize datafiles with control files and redo logs, open the database by using
 the RESETLOGS option:
 SQL> alter database open resetlogs;
 SQL> archive log list
 ...
 Oldest online log sequence 0
 Next log sequence to archive 1
 Current log sequence 1
   6. Before performing the whole closed database backup, query the EMPLOYEES table to  make sure it exists.
When recovery is successful and the backup has completed, notify users that the database is
available for use, and any data entered after the recovery time (11:44 a.m.) will need to be
reentered.

Incomplete Recovery Using UNTIL CANCEL
You are concerned about block corruption in the EMPLOYEES table resulting from disk error. Because redo logs are contained on the same disk, you decide to check the status of redo logs and archived logs:
SQL> SELECT * FROM v$logfile;
GROUP#  STATUS            MEMBER                                                                         
------  ----------------  ---------------------------------
     2                    /disk1/data/log2a.rdo
   1                    /disk1/data/log1a.rdo
SQL> SELECT * FROM v$log;
G# ... SEQ#  BYTES  MEMBERS  ARC STATUS   ... FIRST_TIME
-- ... ----  ------ -------  --- -------- ... --------------
 1 ... 49    153600 1        NO  CURRENT  ... 02-03-09:11:55
 2 ... 48    153600 1        NO  INACTIVE ... 02-03-09:11:34

Incomplete Recovery Using UNTIL CANCEL (continued)
After searching through the /disk1/data directory, you notice that redo log log2a.rdo cannot be located and has not been archived. Therefore, you cannot recover past this point.
Querying V$LOG_HISTORY confirms the absence of archived log seq 48 (log2a.rdo):
SQL> SELECT * FROM v$log_history;
RECID STAMP  ...  FIRST_CHANGE FIRST_TIME
----- --------- ...  ------------ ----------
  1 318531466 ...  88330            02-02-28:12:43
 47 319512880 ...  309067           02-03-09:11:26
Because this is an OLTP system, the output from V$LOG shows that an extra 10 minutes of work will be lost if the database is recovered before applying log2a.rdo. Users are not happy about losing work, but can recover that work.
You can recover the database as follows:
1. Shut down the database.
2. Restore all datafiles from the most recent backup.
3. You already have a valid backup, so mount the database.

Incomplete Recovery Using UNTIL CANCEL (continued)
Recover the database until log seq 48:
 SQL> recover database until cancel
 ORA-00279:change 148448...03/02/02 12:45:20 needed for thread
 ORA-00289: suggestion : /disk1/archive/arch_34.rdo
 ORA-00280: change 148448 for thread 1 is in sequence #34
 Log applied.
 ...
 ORA-00279:change 309012...03/09/02 11:33:56 needed for thread
 ORA-00289: suggestion : /disk1/archive/arch_48.rdo
 ORA-00280: change 309012 for thread 1 is in sequence #48
 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
 cancel
 Media recovery cancelled.
Open the database by using the RESETLOGS option.
Check that the EMPLOYEES table exists.
When recovery is complete, make a backup. Notify users that the database is available for use, and any data entered after the recovery time (11:34 a.m.) will need to be reentered.