合 12c RMAN新特性之通过网络远程恢复数据库(RESTORE Recover from Service)
Tags: Oracle备份恢复rman12c 新特性recover from servicerestore from service通过网络远程恢复数据库
通过网络远程恢复数据库(Restore/Recover from Service)
在Oracle 12c中,可以在主数据库和备用数据库之间用一个服务名重新获得或恢复数据文件、控制文件、参数文件(SPFILE)、表空间或整个数据库。这对于同步主数据库和备用数据库极为有用。
当主数据库和备用数据库之间存在相当大的差异时,不再需要复杂的前滚流程来填补它们之间的差异。RMAN能够通过网络执行备用恢复以进行增量备份,并且可以将它们应用到物理备用数据库。可以用服务名直接将所需数据文件从备用点拷贝至主站,这是为了防止主数据库上数据文件、表空间的丢失,或是没有真正从备份集恢复数据文件。
具体的几种用法:
1 2 3 4 5 6 7 | 数据库级别:restore database from service <服务别名> 表空间: restore tablespace from service <服务别名> 控制文件:restore controlfile to '指定的位置' from service <服务别名> SPFILE: restore spfile from service <服务别名> |
以下命令演示了如何用此新功能执行一个前滚来对备用数据库和主数据库进行同步。在物理备用数据库上:
1 2 3 | rman target "username/password@standby_db_tns as SYSBACKUP" RMAN>RECOVER DATABASE FROM SERVICE primary_db_tns USING COMPRESSED BACKUPSET; |
以上案例使用备用数据库上定义的primary_db_tns连接字符串连接到主数据库,然后执行了一个增量备份,再将这些增量备份传输至备用目的地,接着将应用这些文件到备用数据库来进行同步。然而,需要确保已经对primary_db_tns进行了配置,即在备份数据库端将其指向主数据库。
在以下命令中,演示了通过从备用数据库获取数据文件来恢复主数据库上丢失的数据文件。在主数据库上:
1 2 3 | rman target "username/password@primary_db_tns as SYSBACKUP" RMAN>RESTORE DATAFILE '+DG_DISKGROUP/DBANME/DATAFILE/filename' FROM SERVICE standby_db_tns; |
& 说明:
有关RECOVER TABLE的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152712/
有关RECOVER TABLE的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152715/
有关RECOVER TABLE的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152717/
12c RMAN新特性restore/recover from service远程恢复
12c中提供了基于网络的RMAN Restore和recover功能:
About Restoring Files Over the Network
RMAN restores database files, over the network, from a physical standby database by using the FROM SERVICE clause of the RESTOREcommand. The FROM SERVICE clause provides the service name of the physical standby database from which the files must be restored. During the restore operation, RMAN creates backup sets, on the physical standby database, of the files that need to be restored and then transfers these backup sets to the target database over the network.
Use the SECTION SIZE clause of the RESTORE command to perform a multisection restore operation. To encrypt the backup sets created on the physical standby database, use the SET ENCRYPTION command before the RESTORE command to specify the encryption algorithm used.
To transfer files from the physical standby database as compressed backup sets, use the USING COMPRESSED BACKUPSET clause in the RESTOREcommand. By default, RMAN compresses backup sets using the algorithm that is set in the RMAN configuration. You can override the default and set a different algorithm by using the SET COMPRESSION ALGORITHM command before the RESTORE statement.
About Recovering Files Over the Network
RMAN can perform recovery by fetching an incremental backup, over the network, from a primary database and then applying this incremental backup to the physical standby database. RMAN is connected as TARGET to the physical standby database. The recovery process is optimized by restoring only the used data blocks in a data file. Use the FROM SERVICE clause to specify the service name of the primary database from which the incremental backup must be fetched.
To use multisection backup sets during the recovery process, specify the SECTION SIZE clause in the RECOVER command. To transfer the required files from the primary database as encrypted backup sets, use the SET ENCRYPTION command before the RESTORE command to specify the encryption algorithm used to create the backup sets.
To compress backup sets that are used to recover files over the network, use the USING COMPRESSED BACKUPSET. RMAN compresses backup sets when it creates them on the primary database and then transfers these backup sets to the target
可以通过restore .. from service指定的对象类型:
- database
- datafile
- tablespace
- 控制文件
- SPFILE
当在主库Primary丢失/或损坏FILE#=6的user01.dbf数据文件时,可以直接使用restore datafile from service来从standby(其实并不要求一定是DataGuard,只需要是合适的备用库即可)上获得数据文件,例如:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 | select * from v$version; BANNER CON_ID ------------------------------------------------------------------------------------------ ---------- Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 0 PL/SQL Release 12.1.0.2.0 - Production 0 CORE 12.1.0.2.0 Production 0 TNS for Linux: Version 12.1.0.2.0 - Production 0 NLSRTL Version 12.1.0.2.0 - Production askmaclean.com RMAN> select name from v$datafile where file#=6; NAME -------------------------------------------------------------------------------- /s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf RMAN> alter database datafile 6 offline; Statement processed RMAN> restore datafile 6 from service pdstby; Starting restore at 04-OCT-14 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=51 device type=DISK channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service pdstby channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00006 to /s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished restore at 04-OCT-14 RMAN> recover datafile 6 from service pdstby; Starting recover at 04-OCT-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: using network backup set from service pdstby destination for restore of datafile 00006: /s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 10/04/2014 02:57:09 ORA-19845: error in backupDatafile while communicating with remote database server ORA-17628: Oracle error 19648 returned by remote Oracle server ORA-19648: datafile : incremental-start SCN equals checkpoint SCN ORA-19660: some files in the backup set could not be verified ORA-19661: datafile 6 could not be verified ORA-19845: error in backupDatafile while communicating with remote database server ORA-17628: Oracle error 19648 returned by remote Oracle server ORA-19648: datafile : incremental-start SCN equals checkpoint SCN 之后recover 并online datafile 6即可 |
具体的几种用法:
- 数据库级别: restore database from service <服务别名>
- 表空间: restore tablespace from service <服务别名>
- 控制文件: restore controlfile to ‘指定的位置’ from service <服务别名>
- SPFILE: restore spfile from service <服务别名>
通过recover .. from service命令可以通过网络将service指定的数据库的增量备份拉过来在本地做recover从而让本地数据库跟上远程数据库的SCN。
CONNECT TARGET “sys/
此外上述增量备份还可以是基于压缩备份的:
SET COMPRESSION ALGORITHM ‘BASIC’;
SET COMPRESSION ALGORITHM ‘LOW’;
SET COMPRESSION ALGORITHM ‘MEDIUM’;
SET COMPRESSION ALGORITHM ‘HIGH’;
CONNECT TARGET “sys/
SET COMPRESSION ALGORITHM ‘BASIC’;
RECOVER DATABASE FROM SERVICE primary
USING COMPRESSED BACKUPSET;
Rolling Forward a Physical Standby Using Recover From Service Command in 12c (文档 ID 1987763.1)
APPLIES TO:
Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Information in this document applies to any platform.
GOAL
Rolling Forward a Physical Standby Database Using the RECOVER FROM SERVICE Command
A standby database is a transactionally-consistent copy of the production database. It enables production Oracle database to survive disasters and data corruption. If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch a standby database to the production role, minimizing the downtime associated with the outage. Moreover, performance of production database can be improved by offloading resource-intensive backup and reporting operations to standby systems. As you can see, it’s always desirable to have standby database synchronized with the primary database.
Prior to 12c, in order to roll forward the standby database using incremental backups you would need to:
- Create a control file for the standby database on the primary database.
- Take an incremental backup on the primary starting from the SCN# of the standby database.
- Copy the incremental backup to the standby host and catalog it with RMAN.
- Mount the standby database with newly created standby control file.
- Cancel managed recovery of the standby database and apply incremental backup to the standby database.
- Start managed recovery of standby database.
In 12c, this procedure has been dramatically simplified. Now you can use the RECOVER … FROM SERVICE command to synchronize the physical standby database with the primary database. This command does the following:
- Creates an incremental backup containing the changes to the primary database. All changes to data files on the primary database, beginning with the SCN in the standby data file header, are included in the incremental backup.
- Transfers the incremental backup over the network to the physical standby database.
- Applies the incremental backup to the physical standby database.
This results in rolling forward the standby data files to the same point-in-time as the primary. However, the standby control file still contains old SCN values which are lower than the SCN values in the standby data files. Therefore, to complete the synchronization of the physical standby database, the standby control file needs to be refreshed to update the SCN#.
SOLUTION
Steps to Refresh a Physical Standby Database with Changes Made to the Primary Database
Environment:
Primary Database:
DB_UNIQUE_NAME: prim ( net service name 'PRIM')
Standby Database:
DB_UNIQUE_NAME:clone( net service name 'CLONE')
Use the following steps to refresh the physical standby database with changes made to the primary database:
Prerequisites:
- Oracle Net connectivity is established between the physical standby database and the primary database.
- You can do this by adding an entry corresponding to the primary database in the tnsnames.ora file of the physical standby database.
- The password files on the primary database and the physical standby database are the same.
- The COMPATIBLE parameter in the initialization parameter file of the primary database and physical standby database is set to 12.0.
- Start RMAN and connect as target to the physical standby database.
Check the existing size of the Primary database and compare with the standby existing size as we need at-least the difference in size (free space) since standby is behind ,if the datafile on primary has autoextended then standby file would be same in size compared to prod,so when you do the incremental rollforward it would apply the blocks and add any new one to match the size of standby file.
1. Place the physical standby database in MOUNT mode.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
2. Stop the managed recovery processes on the physical standby database.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;