Oracle Machine Recovery

Rman Machine Recovery considerations:
1. When the RMAN machine recovers, the db_name must be the same. If you want to change to another instance name, you can modify it with the NID command after the recovery is successful. The instance name information is recorded in the control file, so if the instance name is inconsistent at the time of recovery, the error will be returned.
2. If the recovered path is inconsistent with the source library, you will need to specify the new location with the set command at restore. and use switch datafile all to update the information to the control file. When doing duplicate, RMAN automatically converts the set based on the Log_file_name_convert and Db_file_name_convert in Pfile. When you manually restore, you can only use the SET command.

1. Prepare the following on the recovery machine:
"Backup file:
　　　　 /ora_rman_backup/20150618/{control files. bak; data files. bak; archive log. bak; parameter file. bak; password file. bak}
　　　　 Note: The Rman backup file is placed here because the backup is specified here when the Rman backup is made on the source db, and if the same directory is not established,
When you restore the following, you must specify the location of the Rman backup files.
"OracleDB has been installed, and the basic environment variables have been configured.
"CD $ORACLE _home/dbs
Orapwd File=orapw$oracle_sid password=oracle
"MkDir $ORACLE _base/oradata
MKDIR-PV $ORACLE _base/admin/$ORACLE _sid/{a,b,dp,u}dump

2. Restore the parameter file
Export Oracle_sid=udpay
Rman Target/
rman> restore SPFile to Pfile ' $ORACLE _home/dbs/initdave2.ora ' from '/ora_rman_backup/20150618/dave_spfile_16m6qtde_1_1_20110309 ';
Or
Directly using the Init$oracle_sid.ora file copied from the source DB is also available, as long as the copy to $oracle_home/dbs,
The above Oracle_sid configuration, also can.

3. Restore the control file
"Modify the parameter file:
*.control_files= '/oracle/oradata/orcl/control01.ctl ', '/oracle/oradata/orcl/control02.ctl ', '/oracle/oradata/ Orcl/control03.ctl '
"Recovery control File:
rman> startup Nomount;
rman> restore Controlfile from '/ora_rman_backup/20150618/ctl_20150618 ';

4. Start db to Mount
Rman> ALTER DATABASE Mount;

5. Restore Archivelog
Rman> crosscheck Archivelog All; "Meaning See"
Rman> crosscheck Backup of Archivelog all;
rman> Delete expired Archivelog all;
Rman> list Backup of Archivelog all;
rman> Restore Archivelog from sequence=642; Note: This 642 refers to restoring archivelog, starting with a 4620 backup from sequence.
BS keyword size device type elapsed time completed
------- ---------- ----------- ------------ ----------
1 149.20M DISK 00:00:01 2 February-July-16
BP keyword: 1 status: AVAILABLE compressed: NO tag: tag20160722t152937
Paragraph name:/tmp/archlog_dbinfo_1

List of archived logs in Backup set 1
Line program column low SCN time limit next SCN next
---- ------- ---------- ---------- ---------- ---------
1642126150727 1 September-July-16 126275396 2 February-July-16


6. Modify the new path for data file recovery "Error Reference, see the end of the article "
　　 # View the location of the Redolog recorded in the recovered control file.
# Select group#, member from V$logfile;
Note: These need to be placed in the run runtime block.
Rman> Run {
Allocate channel A1 type disk;
Allocate channel A2 type disk;
Set until sequence=4631 thread=1;
Set newname for datafile '/dev/udpay/lv_system01_1024m ' to '/oracle/oradata/udpay/1024m_system01.dbf ';
Set newname for datafile '/dev/udpay/lv_undo01_8192m ' to '/oracle/oradata/udpay/8192m_undotbs01.dbf ';
Set newname for datafile '/dev/udpay/lv_tools01_256m ' to '/oracle/oradata/udpay/256m_users01.dbf ';
Set newname for datafile '/dev/udpay/lv_users01_256m ' to '/oracle/oradata/udpay/256m_tools01.dbf ';
Set newname for datafile '/dev/udpay/lv_perf_256m ' to '/oracle/oradata/udpay/256m_perf.dbf ';
Set newname for datafile '/dev/udpay/lv_whtapp_data01 ' to '/oracle/oradata/udpay/whtapp_data01.dbf ';
Set newname for datafile '/dev/udpay/lv_whtapp_data02 ' to '/oracle/oradata/udpay/whtapp_data02.dbf ';
Set newname for datafile '/dev/udpay/lv_whtapp_data03 ' to '/oracle/oradata/udpay/whtapp_data03.dbf ';
Set newname for datafile '/dev/udpay/lv_whtapp_index01 ' to '/oracle/oradata/udpay/whtapp_index01.dbf ';
Set newname for datafile '/dev/udpay/lv_indx01_256m ' to '/oracle/oradata/udpay/indx01.dbf ';

Restore database; This is the recovery data file directly from the default Rman backup path.

#注: When using SQL to execute SQL commands in Rman, the SQL command needs to be enclosed in double quotation marks, and the single quotation marks are written two times when the double quotation marks are inside.
# inside the double quotes are single quotes, and both are double-written.
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo11_256m" to "/oracle/oradata/udpay/256m_redo11.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo12_256m" to "/oracle/oradata/udpay/256m_redo12.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo21_256m" to "/oracle/oradata/udpay/256m_redo21.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo22_256m" to "/oracle/oradata/udpay/256m_redo22.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo31_256m" to "/oracle/oradata/udpay/256m_redo31.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo32_256m" to "/oracle/oradata/udpay/256m_redo32.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo41_256m" to "/oracle/oradata/udpay/256m_redo41.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo42_256m" to "/oracle/oradata/udpay/256m_redo42.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo51_256m" to "/oracle/oradata/udpay/256m_redo51.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo52_256m" to "/oracle/oradata/udpay/256m_redo52.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo61_256m" to "/oracle/oradata/udpay/256m_redo61.log";
SQL "ALTER DATABASE rename file '/dev/udpay/lv_redo62_256m" to "/oracle/oradata/udpay/256m_redo62.log";

Switch datafile all;
Release channel A1;
Release channel A2;
}

8. Perform database consistency recovery in Rman
Rman Target/
rman> Recover database;
--------------------------------------------------------------------------------------------------------------- ---------------
The following error appears to be normal:
RMAN-00571: =========================================
RMAN-00569: =============== ERROR MESSAGE STACK follows = = =
RMAN-00571: =========================================
Rman-03002:failure of recover command at 06/24/2015 16:02:25
Rman-06054:media recovery requesting unknown Log:thread 1 SCN 277200603
--------------------------------------------------------------------------------------------------------------- ---------------

If it fails, go back to Sqlplus and try:
Sqlplus/nolog;
Sql> Conn/as SYSDBA
sql> ALTER DATABASE open resetlogs;


Supplement 1:
This is another error that occurs when you restore an Oracle database:
rman> ALTER DATABASE open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE, STACK follows ===============
RMAN-00571: ===========================================================
Rman-03002:alter DB Command (on 07/24/2016 16:36:40) failed
ORA-01152: File 1 has not been restored from an older backup
ORA-01110: Data file 1: '/HOME/ORACLE/ORA/ORADATA/DBINFO/SYSTEM01.DBF '

Above this error, online has said: Is the system01.dbf in the head of the SCN and control files recorded in the head of the data file SCN different.
Workaround:
Data file header start SCN than control file record database file head SCN to be new, then
Use logs (including archived logs + online redo logs) to forward the database recorded in the control file
The head SCN is consistent with the data file start SCN to ensure that the database is opened.
Because the database is recovered using the backup control file, you must open the database by alter the Resetlogs

Sqlplus/as SYSDBA
Sql> Startup Mount
sql> Recover database using Backup controlfile until cancel;
Note: This step, because the backup control file does not record the SCN of the online redo log file,
# Here you need to manually enter the redo file to cancel the recovery.
ORA-00279: Change 126276941 (generated on 07/22/2016 15:43:45) is required for thread 1
ORA-00289: Recommended:
/home/oracle/ora/product/11.2.0.3/dbhome_1/dbs/arch1_644_810751417.dbf
ORA-00280: Change 126276941 (for thread 1) in the sequence #644

Specify log: {<ret>=suggested | filename | AUTO | CANCEL}
　　 /tmp/redo01.log #这是手动输入备份的redolog文件.
ORA-00310: Archive log contains sequence 642; Request Sequence 644
ORA-00334: Archive log: '/tmp/redo01.log '
Note:
There are a total of 10 redolog, I have done this once, do not know whether it is necessary.
Another note:
I don't quite understand what this is all about, and I tried using the Archivelog file to recover.
But I found that the archive still does not contain sequence 644. Finally, I try to use the "ALTER DATABASE open resetlogs;"
Tips:
ALTER DATABASE open Resetlogs
*
An error occurred on line 1th:
The ora-01139:resetlogs option is only valid after incomplete database recovery
# Then, I use again:
ALTER DATABASE open;
# turned on. Magical events.

Supplement 2:
Execution: 6th step, the following error occurred:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE, STACK follows ===============
RMAN-00571: ===========================================================
Rman-03002:restore command (on 07/24/2016 15:47:27) failed
RMAN-06026: Some targets not found-terminate restore
RMAN-06023: Copy of data file 4 not found restore
RMAN-06023: Copy of data file 3 not found restore
RMAN-06023: Copy of data file 2 not found restore
RMAN-06023: Copy of data file 1 not found restore

This error: Online description This is Oracle10 after a new feature incarnation, resulting in an error.
Note: incarnation is: In order to resolve the restoration of resetlogs previous backup, and a feature;

　　　　

This diagram is my understanding of incarnation:
This means that the first one does not fully revert to the SCN (checkpoint) 700, after Resetlogs, incarnation+1, starts using the database
At this time, the SCN will continue to increase from 700, then found that some data are not, need to be restored, there is the first
Secondary incomplete recovery, followed by the use of DB, the third time, and found that still need to restore, but is to restore to
After the previous resetlogs, the SCN grew to 800 places, but it was clear to know now if directly
Restored to SCN800, was the second resetlogs after the SCN grew to 800 places, but now to revert to the first
After Resetlogs, the SCN grows 800 where it needs to go back to incarnation 1 in the scene. You can do it in a recovery.
i.e.: first reset database to incarnation 1; The incomplete recovery is in progress.

and back up. Rman recovery Error This topic:
Since the current version is Oracle11.2.0.3, there is certainly a incarnation problem, but in fact, I am doing a full recovery,
The Incarnation feature is not required, and you can modify the $ORACLE directly if you want to close it _home/dbs/init$oracle_sid.ora
File, the following two comments out, that is, directly in front of the "#" can be.
#*.db_recovery_file_dest= '/home/oracle/ora/flash_recovery_area '
#*.db_recovery_file_dest_size=4070572032
Why do you do this? "The following is my understanding, only for reference"
Because, when the Incarnation feature is recovered, when recovering the SCN point, the SCN may be the same as the SCN in the backup set, as
The first and second of the above contains SCN800, so it is looked up from the SCN of the current (on the second resetlogs)
Restores the specified SCN point, and here is no such data file. In order to not allow Oracle to adopt this mechanism, the recovery files can be
The location is commented out so that Oracle does not find the backup set file after the current resetlogs in the recovery file directory.

A second error:
Sql> Startup
#在Startup时, the following error occurred: [The following blog summarizes this error.]
# http://www.cnblogs.com/kerrycode/p/3656655.html

Ora-01102:cannot mount Database in EXCLUSIVE mode

There are three scenarios in which this error occurs:
A, Oracle's shared memory segment or semaphore is not released;
B, Oracle's background processes (such as Smon, Pmon, DBWN, etc.) are not closed;
C, the files used to lock the memory lk<sid> and SGADEF&LT;SID&GT;.DBF files have not been deleted. "Note: This file is best not to be deleted, but renamed"

Oracle Machine Recovery