Rman Full library restored to different host, different instance name, different directory

First, configure the target host IP, hostname and connectivity to the source-side host

1. Configure target host IP

To configure IP using the graphical interface:

Administration----Network---Modify IP (specify static IP)

Deactivate network card---Activate network card (restart NIC configuration to take effect)
or use root User: Service network restart restart NIC

2. Configure Host Name

1. Root user execution: hostname hostnamevalue
2. Vi/etc/sysconfig/network

Modified: hostname=edsir4p1.us.oracle.com

1. Modify IP-to-hostname mappings in the/etc/hosts file

127.0.0.1 localhost.localdomain localhost

192.168.33.138 edsir4p1.us.oracle.com EDSIR4P1

192.168.33.137 edsir1p8.us.oracle.com EDSIR1P8

3, testing to the source-side of the connectivity of the host

8. Ping edsir1p8.us.oracle.com

Or

Ping 192.168.33.137

"Diffuse web (http://www.manxinet.com)"

Ii. Plan the Save path of the backup set on the target machine

Because the save path to the backup set recorded in the control file is the path of the recorded backup set on the source (EDSIR1P8) host, if the SCP is not consistent with the save path of the original backup set, the metadata information for all the backup sets recorded in the control file will be invalidated and must be performed: Catalog Start with '/backupset_path '

Let the control file automatically identify the backup set's metadata information (path, backup slice name, etc.).

Now set the storage path of the backup set on the target side is consistent with the source, thus avoiding the need to control the file to automatically identify the backup set metadata process, to avoid the backup set identification incomplete (missing backup slice)

The target-side backup set planning path is as follows:

Full backup:

Database:/u01/app/oracle/oradata/backupset/prod4/full/database

Controlfile:/u01/app/oracle/oradata/backupset/prod4/full/controlfile

Arch:/u01/app/oracle/oradata/backupset/prod4/full/arch

Controfile Backup:

Controlfile:/u01/app/oracle/oradata/backupset/prod4/controlfile

Arch Backup:

Arch:/u01/app/oracle/oradata/backupset/prod4/arch

Automatic backup control files and SPFile:

Controlfile+spfile:

/u01/app/oracle/oradata/autobackup/prod4

Third, the specification after the recovery database data file save path

The newly restored instance is named: CPROD4

Save path to data file after full vault recovery:

Datafile:/u01/app/oracle/oradata/cprod4/datafile

Redo:/u01/app/oracle/oradata/cprod4/onlinelog

Tempfile:/u01/app/oracle/oradata/cprod4/tempfile

Controlfile:/u01/app/oracle/oradata/cprod4/controlfile

Arch:/u01/app/oracle/oradata/cprod4/arch

"Diffuse web (http://www.manxinet.com)"

Iv. Full Library Recovery

1, in the source-side database to do the full library backup and archive backup

(Clear all Backup set Delete backup before actual test, but this operation is strictly prohibited on production)

A. Full library backup, execute script on EDSIR1P8: rman_prod4_full_01.sh

B. Archive backup, execute script on EDSIR1P8: rman_prod4_arch_01.sh

C. After the backup is complete, check to see if a new archive log was generated during the backup.

Note: If a new archive log is generated during the backup and has been written to the control file's

V$archived_log view, but there is no backup when backing up the archive, and then the current control file is backed up when the control file is automatically backed up, that is, the archive date that is not backed up is recorded in the backup control file Log, so that the subsequent determination to recover the SCN number as of the error, the corresponding archive logs cannot be found (the archive log generated during the backup is not backed away)

Therefore, in the subsequent determination of the recovery of the SCN number must first determine whether the backup set has a corresponding SCN number of the archive log, not only through the V$archived_log view to simply determine the recovery up to SCN

2, SCP or other methods to import to the target host

A. Transferring data files

Go to the/u01/app/oracle/oradata/backupset/prod4/full/database directory of the source-side EDSIR1P8

SCP * 192.168.33.138:/u01/app/oracle/oradata/backupset/prod4/full/database

B. Transfer of a fully-prepared archive:

Enter the/u01/app/oracle/oradata/backupset/prod4/full/arch of the source end EDSIR1P8

SCP * 192.168.33.138:/u01/app/oracle/oradata/backupset/prod4/full/arch

C. Subsequent transfers of all backup sets: Control files for full backups, archive logs, control files for individual backups, control files for automatic backups

Note: the "*" at SCP indicates that all files under the current path are transferred to the target side

3. Recovery of SPFile files

A. Booting to the Nomount state using Rman's own parameter file

(i) switch the environment variable on 138 to switch to the correct oracle_home can be used under the bin directory Rman

. Oraenv

Oracle_sid=prod1

(ii) Set ORACLE_SID to restore the SID corresponding to the SPFile file: Spfilesid.ora

Export ORACLE_SID=CPROD4

(iii) Start Rman to Nomount State

Rman Target/

RMAN > Startup Nomount

B. Recovering SPFile

(i) Restore SPFile file

RMAN > Restore SPFile from

'/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05 '; The following error is reported during execution:

Error One:

Reason: The source-side database opened the share mode connection, modified the SPFile six parameters, now using SPFile detection spfile saved system parameters found on the target side, so Report the above error.

prod4_1526 is the access connection for shared mode. and registered on the Local_listener, but there is no corresponding listener and TNS alias on target 138, need to create

Solution:

Copy the following listener from 137 to the 138 Listener.ora file

sid_list_prod4_1526 =

(Sid_list =

(Sid_desc =

(Global_dbname = PROD4.us.oracle.com)

(Oracle_home =/u01/app/oracle/product/11.2.0/dbhome_1)

(Sid_name = CPROD4)

)

)

prod4_1526 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = edsir4p1.us.oracle.com) (PORT = 1526))

)

adr_base_prod4_1526 =/u01/app/oracle

Copy the following TNS alias content from 137 to the 138 Tnsnames.ora file

prod4_1526 =

(DESCRIPTION =

(Address_list =

(ADDRESS = (PROTOCOL = TCP) (HOST = edsir4p1.us.oracle.com) (PORT = 1526))

)

(Connect_data =

(SERVER = SHARED)

(service_name = PROD4.us.oracle.com)

)

)

Error Two:

Try again to open the database to the Nomount state:

SQL > Startup Nomouont

will report the above error

Reason

The database auditing feature on source 137 requires the creation of the audit directory, but no corresponding audit directory on 138

Solution:

View Parameters on 137: Show parameter Audit

Audit_file_dest String/u01/app/oracle/admin/prod4/adump

Create this directory on 138: Mkdir-p/u01/app/oracle/admin/prod4/adump

Or:

On the target side 138, if the database can boot to the Nomount state, you can view the parameters on the 138 end

Audit_file_dest, and then create the directory

C. Re-opening the database to the Nomount state using the recovered SPFile

Shutdown immediate

Startup Nomount

4. Recovery of Controlfile files

A. Modify the path of the Controlfile file first

Because Controlfile is stored on the +data disk group on 137, there is no ASM instance on 138, so the restore controlfile cannot succeed.

Execute the following command:

Alter system set control_files= '/u01/app/oracle/oradata/cprod4/controlfile/control 01.ctl ' Scope=spfile;

Restart the database and reload the SPFile:

Shutdown immediate

Startup Nomount

Recovery of B.controlfile

Restore Controlfile from

'/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05 ';

1. Modify database to Mount State

RMAN > ALTER DATABASE mount;

5. Database recovery

A. Determining the maximum number of SCN that can be recovered

(i) Query the end SCN value of the last archive from the V$archived_log view

Select name,resetlogs_change#,resetlogs_id,first_change#,next_change# from V$archived_log;

Is the newly generated archive log after recovery, not the archive log information that was recorded in the previous control file before recovery.

The last SCN value for the archive recorded in the original control file is: 2460383

(ii) in the backup set, verify that the backup slice that really exists to the SCN value

List backup of Archivelog all;

In the corresponding path

/u01/app/oracle/oradata/backupset/prod4/arch/arch_prod4_905667093_729_1. Bak confirm that the backup slice is actually stored (note that the backup slice is correctly transmitted during SCP confirmation)

Also observe whether the associated archive log backups are contiguous on the list of backup sets displayed.

(iii) Confirm the value of the Incarnation in the event that the backup slice confirms that it is true, to confirm that the archive log for the batch of RESETLOG_SCN is appended to the archive for 2460383 in the recover process.

Query 2460383 archive from V$archived_log view the corresponding resetlogs_change# column values are: 2167043

From Rman: Rman > List incarnation

1 1 PROD4 1612213667 current 2167043 02-mar-16

The result shows that the current incarnation corresponds to the reset SCN value of 2167043

Incarnation. Reset SCN =V$ARCHIVED_LOG.MAXSCN. resetlogs_change#

Meet the above conditions: in the process of recover will go to find and maximum SCN corresponding to the same resetlogs_change# value of the batch archive log, until the maximum SCN number to append the archive log.
If the above conditions are not met: in the process of recover will not go to find and the maximum SCN number of the archive log

The resetlogs_change# column values correspond to the same batch of archives. At this time, if it is simple to build a test environment regardless of the amount of lost data, you can find the appropriate SCN value in the V$archived_log view until you can v$datafile_header all the file headers in the checkpoint_change# view, which You can resetlogs open the database

If you consider minimizing the loss of data, you need to set the current incarnation value so that the condition is met:

Incarnation. Reset SCN =V$ARCHIVED_LOG.MAXSCN. resetlogs_change#

This allows all archives to be appended to the recover process until the archive log corresponding to the maximum SCN value is appended. This is also the solution to minimize the loss of data when recovering from a full library. This allows the settings to revert to the state of least data loss. (Only data in redo is lost)

B. Turn off the database flashback feature

The database Flashback function is enabled on source side 137:

Because the Flashback log storage path at the beginning of the database flashback is on: +flashback disk Group

And the redo to be regenerated when Resetlogs is turned on after the database flashback is placed by default in the same path as the flashback log, so the +flashback disk group is checked in advance and the data is verified when you execute the RESTORE database Vault Flash Back

There is no ASM instance on the 138 end and there is no +flashback disk group, so there will be an error in subsequent execution of the restore database, so you need to turn off the DB Flashback function on 138 and restart the database reload SPFile and Controlfile

Perform the following actions:

138 Turn off the database flashback:

ALTER DATABASE flashback off;

Confirm that the shutdown was successful:

Select Name, flashback_on from V$database;

To close the database:

Shutdown immediate

Reload SPFile and Controlfile

Startup Mount

Because the database flashback causes the following error:

C. Modifying the archive path

Because the archive path on 137 is a +arch disk group

There are no ASM instances on 138 and there are no +arch disk groups, so there will be an error in the recover process, as follows:

The error message shows that there are no archive logs with a starting SCN of 2443916 and 2427335.

The elimination process is as follows:

RMAN > List Backup of Archivelog all

Check it out. So archive the backup set, locate the backup slice that contains the starting SCN, and first verify that there are two archived backup slices and metadata information in the Rman catalog.

Determine if there is a backup slice of the archive log through the low SCN and Next SCN values

Then verify that the file exists under the corresponding path

If there is an error stating that the SCP is not present: a re-SCP is required

If it is not found in the display results of the list backup of Archivelog all, the possible reason is that it is not registered with Rman and needs to re-register the path of the archive backup set to Rman:

Catalog start with '/u01/app/oracle/oradata/backupset/prod4/arch '

Catalog start with '/u01/app/oracle/oradata/backupset/prod4/full/arch '

If there is a corresponding backup slice in the display result of the list backup of Archivelog all, and the backup slice file does exist under the specified path. The possible reason is that the archive path on source 137 is not created on 138, that is, there is no archive log storage path on the source side on 138.

Because in the process of executing recover, the Append log is executed as follows:

@ Release the archive log backup set to the archive log storage path recorded in the control file first

137 is the +arch disk group, so on 138 will be looking to release the presence +arch disk group

@ Release all archived backup sets to archive log storage path, release to archive log file

The archive log file under this path is read during @recover

In summary: The archive log must be created on the target side and the same path as the source, or the archive log storage path should be re-specified

Because the 137-side archive log path is a +arch disk group

There is no ASM instance on 138, the archive path must be re-specified

Perform the following actions:

To view the archive path recorded in the control file:

Show Parameter Archive

To modify the archive path:

Alter system set log_archive_dest_1= ' Location=/u01/app/oracle/oradata/cprod4/arch '

Consistency Close Database

Shutdown immediate

Reload SPFile and Controlfile

Startup Mount

B. Executing a recovery script

(i) first check out all data file information recorded in the control file

Select name from V$datafile;

(ii) Modify the restore's data file to store a new path, i.e. revert to a different directory

Set newname for datafile ' +data/prod4/datafile/system.286.905335925 ' to '/u01/app/oracle/oradata/prod4_t/datafile/system ';

(iii) Execution of the restore database;

Release the data file backup set to the corresponding new storage directory and rename it to the new specified file name

(iv) modifying pointers to new data files in control files

Switch datafile all;

(v) Append archive log recover database

Recover database;

The script is roughly the following:

Run {

Set until SCN 2460383;

Set newname for datafile ' +data/prod4/datafile/system.286.905335925 ' to '/u01/ap P/ORACLE/ORADATA/CPROD4/DATAFILE/SYSTEM.DBF ';

Restore database;

Switch datafile all;

Recover database;

}

Specific script reference: Cprod4_setnewname_recover.txt

Note: To tail-f recover_log.log log files During script execution, trace the recovery process

"Diffuse web (http://www.manxinet.com)"

6. Rebuild Controlfile file to modify Redo recovery path

Recover can not open the database Resetlogs way after completion, because there is no redo file, no redo, any access to the database session will be killed by Oracle.

This step executes the Resetlogs mode to open the database error as follows:

Reason

Source-side 137 redo storage path in + Flashback disk Group

Sql> Select member from V$logfile;

MEMBER

---------------------

+flashback/prod4/onlinelog/group_4.366.905339795

+flashback/prod4/onlinelog/group_1.368.905339781

+flashback/prod4/onlinelog/group_2.374.905339785

+flashback/prod4/onlinelog/group_3.369.905339787

There is no ASM instance on target 138 and there is no +flashback disk group, so the redo file cannot be successfully created when you open the database in Resetlogs mode.

Workaround: You can establish a redo directory with the same path on the source side 137, or rebuild the control file to reassign the Redo storage path

Note: You can only create three log groups by default when you open a database in resetlogs mode, and you can have only one member per group.

Solution:

Rebuilding Controlfile:

Perform the following actions:

@mount State backup control file to trace

ALTER DATABASE backup Controlfile to trace as

'/u01/app/oracle/oradata/cprod4/controlfile/recreatectl.ctl ';

@gedit Edit Control files

Gedit/u01/app/oracle/oradata/cprod4/controlfile/recreatectl.ctl

Re-specify the redo's storage path and rebuild the Controlfile in resetlogs mode.

Modified Content Reference script: RecreateCtl.txt

@ Execute Script

SQL > @/u01/app/oracle/oradata/cprod4/controlfile/recreatectl.ctl

@ Consistency Close Database

Shutdown immediate

@ Reload Control File

Startup Mount

7. Opening the database to open state

ALTER DATABASE open resetlogs;

Modify the log group, add log groups and members according to business requirements

A. Adding a log group

ALTER DATABASE add logfile Group 4

'/u01/app/oracle/oradata/cprod4/onlinelog/redo04a.log ' size 50m;

B. Log group Add members

ALTER DATABASE add LogFile Member

'/u01/app/oracle/oradata/cprod4/onlinelog/redo04b.log ' to group 4;

The final log group and member settings are as follows:

Note: After adding the log group to switch the next log group, the unused state to the normal state.

alter system switch logfile;

Also reconfirm that the status of the Log group member member is normal.

Vi. adding temporary tablespace, temporary data file

A. Querying the system default temporary tablespace

SELECT * from database_properties where property_name= ' default_temp_tablespace ';

B. Querying temporary data files

Select Name,status from V$tempfile;

C. Adding temporary data files to the system default temporary table space

Alter Tablespace temp Add tempfile

'/u01/app/oracle/oradata/cprod4/tempfile/temp01.dbf ' size 300m;

D. Add a temporary data file according to your business needs, and the final settings are as follows:

"Diffuse web (http://www.manxinet.com)"

Vii. verifying successful recovery to the specified SCN

Querying the V$datafile_header view to confirm the true SCN of the data file header

Select Name, checkpoint_change# from V$datafile_header;

Confirm that the SCN of the data file header is successfully restored to the specified scn:2460383

Eight, complete the whole library recovery (or test environment to build) the entire process

This article by the diffuse XI starts in "the Diffuse Net (http://www.manxinet.com)"--Reprint please indicate "the diffuse net"

Rman Full library restored to different host, different instance name, different directory