ICode9
精准搜索请尝试： 精确搜索
首页
编程语言>
数据库
系统相关
互联网
其他分享
Python
Java
JavaScript
android
PHP
首页 > 数据库> 文章详细

【12c】12c RMAN新特性之通过网络远程恢复数据库（RESTORE/Recover from Service）

2021-04-13 15:01:13  阅读：197  来源： 互联网

标签：RESTORE 12c Service database standby app oradata oracle u01



【12c】12c RMAN新特性之通过网络远程恢复数据库（RESTORE/Recover from Service）

 

通过网络远程恢复数据库（Restore/Recover from Service）

在Oracle 12c中，可以在主数据库和备用数据库之间用一个服务名重新获得或恢复数据文件、控制文件、参数文件（SPFILE）、表空间或整个数据库。这对于同步主数据库和备用数据库极为有用。

当主数据库和备用数据库之间存在相当大的差异时，不再需要复杂的前滚流程来填补它们之间的差异。RMAN能够通过网络执行备用恢复以进行增量备份，并且可以将它们应用到物理备用数据库。可以用服务名直接将所需数据文件从备用点拷贝至主站，这是为了防止主数据库上数据文件、表空间的丢失，或是没有真正从备份集恢复数据文件。

具体的几种用法：

数据库级别：restore database from service <服务别名>

表空间： restore tablespace from service <服务别名>

控制文件：restore controlfile to '指定的位置' from service <服务别名>

SPFILE: restore spfile from service <服务别名>

以下命令演示了如何用此新功能执行一个前滚来对备用数据库和主数据库进行同步。在物理备用数据库上：

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进行了配置，即在备份数据库端将其指向主数据库。

在以下命令中，演示了通过从备用数据库获取数据文件来恢复主数据库上丢失的数据文件。在主数据库上：

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/

 

 



相信大家在Dataguard环境中遇到过主库丢失归档日志，而备库也没有及时接收，导致备库出现了GAP的现象。因为日志的中断，备库无法再去应用之后的日志，就无法起到容灾的效果。

遇到这种故障，往往主库如果数据很大的时候，大家都不会去选择重新搭建来恢复备库，而会去选择更轻的增量恢复来解决问题。

即使如此，一旦主库数据量过大，每日变化量也极多，进行一次增量恢复其实也需要大量的时间以及备份集所需要的空间。甚至，在GAP期间，如果主库新增了数据文件，那么也会增加任务量。

在12cR1开始，RMAN提供了一个from service的子句让备库可以通过网络来执行recover和restore命令。


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.


那在哪些情况下可以使用这个新特性呢

  • 当备库出现GAP，而主库丢失归档需要做增量备份的时候

  • 当备库丢失数据文件、控制文件以及表空间的需要restore的时候

这个特性其实大大缩减了备库在一些丢失归档需要做增量备份的情况下的工作量，将需要在主备库来回切换的操作简化为只需要在备库进行操作就可以完成。

关于如何运用这一特性，用些简单的例子来试验下。

备库增量恢复演示

模拟一个拥有GAP的备库的环境：



SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#     CON_ID
---------- ------------- -------------- ----------
 1      1231       1234      1
 2       762        765      1
SQL> show parameter fal
NAME                     TYPE           VALUE
------------------------------------ ---------------------- ------------------------------
fal_client               string         slave_db
fal_server               string         primary_db

 



查询可知主库tnsname连接串名为primary_db

step 1 
查询备库当前SCN

 


RMAN> select current_scn from v$database;
CURRENT_SCN
-----------
37537287

 


这里提一下，12c 开始，RMAN可以直接执行很多命令，而不需要去使用sql 'sql'的句式去执行。

然后起至nomount状态

 


RMAN> startup force nomount
Oracle instance started
Total System Global Area    2147483648 bytes
Fixed Size                     8794848 bytes
Variable Size                486542624 bytes
Database Buffers            1644167168 bytes
Redo Buffers                   7979008 bytes

 


step 2

备库通过from service子句进行增量恢复

 



RMAN> restore standby controlfile from service primary_db;
Starting restore at 2018-06-01 12:26:40
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service primary_db
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output file name=/data/data1/control01.ctl
Finished restore at 2018-06-01 12:26:43
RMAN> alter database mount;

 


为防止在GAP期间有新增的数据文件 

可以在主库查询断档之后主库新增的数据文件



SQL> select file# from v$datafile where creation_change# > =37537287;
 FILE#
----------
    47

 




通过from service恢复命令将新增的数据文件通过网络在备库恢复。

RMAN>run
{
SET NEWNAME FOR DATABASE TO '/data/data1/AXTEST/datafile/%f_%U';
RESTORE DATAFILE 47 FROM SERVICE primary_db;
}
executing command: SET NEWNAME
Starting restore at 2018-06-01 12:35:12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=785 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service primary_db
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00047 to /data/data1/AXTEST/datafile/47_data_D-ZZ_TS-TEST1_FNO-47
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 2018-06-01 12:35:28

 

因为主备库数据文件路径不一致，需要使用catalog与copy将数据名更新一致。

 



RMAN> catalog start with '/data/data1';

RMAN> switch database to copy;


step 3 
至此，可以进行增量恢复了 
在from service句式中还是可以使用常规备份时候使用的参数

  • SECTION SIZE （在传输时使用并发备份集传输）

  • USING COMPRESSED BACKUPSET （在传输时使用压缩，减轻网络压力）

 


RMAN> recover database from service primary_db noredo SECTION SIZE 1G USING COMPRESSED BACKUPSET;
....
destination for restore of datafile 00037: /data/data1/AXTEST/688A86E561085C8CE053BB3C0A0A7969/datafile/o1_mf_undo_2_88t4ahp9_.dbf
channel ORA_DISK_1: restoring section 1 of 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished recover at 2018-06-01 13:45:00
#接下来就是正常的起库开启实时日志恢复了

 


通过这种方式可以很快的去解决一些备库需要做增量恢复或者数据文件丢失的故障。

当然，需要使用from service句式时有些必要的条件：

  • 两个数据库之间tns必须保持可以连接的状态

  • 两个数据库密码文件必须保持一致

  • 两个数据库的 COMPATIBLE参数必须为12.0




12c RMAN新特性restore/recover from service远程恢复


12c中提供了基于网络的RMAN Restore和recover功能：

 

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.

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.

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 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

 

可以通过restore .. from service指定的对象类型：

  • database

  • datafile

  • tablespace

  • 控制文件

  • SPFILE

 

restore datafile from service

当在主库Primary丢失/或损坏FILE#=6的user01.dbf数据文件时，可以直接使用restore datafile from service来从standby(其实并不要求一定是DataGuard,只需要是合适的备用库即可)上获得数据文件，例如：

 

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/<password>@standby as sysdba” RECOVER DATABASE FROM SERVICE primary;

recover database from service

 

 

此外上述增量备份还可以是基于压缩备份的：

 

SET COMPRESSION ALGORITHM ‘BASIC’;

SET COMPRESSION ALGORITHM ‘LOW’;

SET COMPRESSION ALGORITHM ‘MEDIUM’;

SET COMPRESSION ALGORITHM ‘HIGH’;

 

CONNECT TARGET “sys/<password>@standby as sysdba”

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)

In this Document

 Goal
 Solution
 References


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;

 

NOTE:  If using broker, you will need to stop MRP through DGMGRL.  I.e.:

DGMGRL> edit database '<Standby db_unique_name>' set STATE='APPLY-OFF' ;

3. Let us identify the datafiles on standby database which are out of sync with respect to primary.


Primary:

SQL> select HXFIL File_num,substr(HXFNM,1,40),fhscn from x$kcvfh;

  FILE_NUM SUBSTR(HXFNM,1,40)                       FHSCN
---------- ---------------------------------------- ----------------
         1 /u01/app/oracle/oradata/prim/system01.db 1984501
         3 /u01/app/oracle/oradata/prim/sysaux01.db 1984501
         4 /u01/app/oracle/oradata/prim/undotbs01.d 1984501
         5 /u01/app/oracle/oradata/prim/pdbseed/sys 1733076
         6 /u01/app/oracle/oradata/prim/users01.dbf 1984501
         7 /u01/app/oracle/oradata/prim/pdbseed/sys 1733076
         8 /u01/app/oracle/oradata/prim/pdb1/system 1984501
         9 /u01/app/oracle/oradata/prim/pdb1/sysaux 1984501
        10 /u01/app/oracle/oradata/prim/pdb1/pdb1_u 1984501
        16 /u01/app/oracle/oradata/prim/pdb3/system 1984501
        17 /u01/app/oracle/oradata/prim/pdb3/sysaux 1984501
        18 /u01/app/oracle/oradata/prim/pdb3/pdb1_u 1984501
        19 /u01/app/oracle/oradata/prim/pdb3/test.d 1984501

13 rows selected.

STANDBy:

SQL>  select HXFIL File_num,substr(HXFNM,1,40),fhscn from x$kcvfh;

  FILE_NUM SUBSTR(HXFNM,1,40)                       FHSCN
---------- ---------------------------------------- ----------------
         1 /u01/app/oracle/oradata/clone/system01.d 1980995
         3 /u01/app/oracle/oradata/clone/sysaux01.d 1980998
         4 /u01/app/oracle/oradata/clone/undotbs01. 1981008
         5 /u01/app/oracle/oradata/clone/pdbseed/sy 1733076
         6 /u01/app/oracle/oradata/clone/users01.db 1981012
         7 /u01/app/oracle/oradata/clone/pdbseed/sy 1733076
         8 /u01/app/oracle/oradata/clone/pdb1/syste 1981015
         9 /u01/app/oracle/oradata/clone/pdb1/sysau 1981021
        10 /u01/app/oracle/oradata/clone/pdb1/pdb1_ 1981028
        16 /u01/app/oracle/oradata/clone/pdb3/syste 1981030
        17 /u01/app/oracle/oradata/clone/pdb3/sysau 1981036
        18 /u01/app/oracle/oradata/clone/pdb3/pdb1_ 1981043
        19 /u01/app/oracle/oradata/clone/pdb3/test. 1981044

13 rows selected. 

On  checking SCN in datafile headers on primary (prim) and standby (clone), we note that whereas SCN

of datafiles 5,7 match on primary and standby, for rest of the  datafiles (1,3,4,6,8,9,10,16,17) standby is lagging behind  primary.

 

4. Note the current SCN of the physical standby database. This is required to determine, in a later step, if new data files were added to the primary database.

Query the V$DATABASE view to obtain the current SCN using the following command:

SELECT CURRENT_SCN FROM V$DATABASE;

5. The RECOVER … FROM SERVICE command refreshes the standby data files and rolls them forward to the same point-in-time as the primary.

[oracle@localhost ~]$ rman target/

Recovery Manager: Release 12.1.0.1.0 - Production on Mon Mar 9 18:22:52 2015

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PRIM (DBID=4165840403, not open)

RMAN> recover database from service prim noredo using compressed backupset;

  Log:


Starting recover at 09-MAR-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
skipping datafile 5; already restored to SCN 1733076
skipping datafile 7; already restored to SCN 1733076
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00001: /u01/app/oracle/oradata/clone/system01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00003: /u01/app/oracle/oradata/clone/sysaux01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00004: /u01/app/oracle/oradata/clone/undotbs01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00006: /u01/app/oracle/oradata/clone/users01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00008: /u01/app/oracle/oradata/clone/pdb1/system01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00009: /u01/app/oracle/oradata/clone/pdb1/sysaux01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00010: /u01/app/oracle/oradata/clone/pdb1/pdb1_users01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00016: /u01/app/oracle/oradata/clone/pdb3/system01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00017: /u01/app/oracle/oradata/clone/pdb3/sysaux01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00018: /u01/app/oracle/oradata/clone/pdb3/pdb1_users01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service prim
destination for restore of datafile 00019: /u01/app/oracle/oradata/clone/pdb3/test.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

Finished recover at 09-MAR-15


6. Lets check the SCNs of the datafiles at primary and standby now.

Primary
--------
SQL> select HXFIL File_num,substr(HXFNM,1,40),fhscn from x$kcvfh;

  FILE_NUM SUBSTR(HXFNM,1,40)                       FHSCN
---------- ---------------------------------------- ----------------
         1 /u01/app/oracle/oradata/prim/system01.db 1985174
         3 /u01/app/oracle/oradata/prim/sysaux01.db 1985183
         4 /u01/app/oracle/oradata/prim/undotbs01.d 1985194
         5 /u01/app/oracle/oradata/prim/pdbseed/sys 1733076
         6 /u01/app/oracle/oradata/prim/users01.dbf 1985203
         7 /u01/app/oracle/oradata/prim/pdbseed/sys 1733076
         8 /u01/app/oracle/oradata/prim/pdb1/system 1985206
         9 /u01/app/oracle/oradata/prim/pdb1/sysaux 1985212
        10 /u01/app/oracle/oradata/prim/pdb1/pdb1_u 1985218
        16 /u01/app/oracle/oradata/prim/pdb3/system 1985221
        17 /u01/app/oracle/oradata/prim/pdb3/sysaux 1985343
        18 /u01/app/oracle/oradata/prim/pdb3/pdb1_u 1985350
        19 /u01/app/oracle/oradata/prim/pdb3/test.d 1985354

Standby
--------
RMAN> select HXFIL File_num,substr(HXFNM,1,40),fhscn from x$kcvfh;

  FILE_NUM SUBSTR(HXFNM,1,40)                       FHSCN
---------- ---------------------------------------- ----------------
         1 /u01/app/oracle/oradata/clone/system01.d 1985174
         3 /u01/app/oracle/oradata/clone/sysaux01.d 1985183
         4 /u01/app/oracle/oradata/clone/undotbs01. 1985194
         5 /u01/app/oracle/oradata/clone/pdbseed/sy 1733076
         6 /u01/app/oracle/oradata/clone/users01.db 1985203
         7 /u01/app/oracle/oradata/clone/pdbseed/sy 1733076
         8 /u01/app/oracle/oradata/clone/pdb1/syste 1985206
         9 /u01/app/oracle/oradata/clone/pdb1/sysau 1985212
        10 /u01/app/oracle/oradata/clone/pdb1/pdb1_ 1985218
        16 /u01/app/oracle/oradata/clone/pdb3/syste 1985221
        17 /u01/app/oracle/oradata/clone/pdb3/sysau 1985343
        18 /u01/app/oracle/oradata/clone/pdb3/pdb1_ 1985350
        19 /u01/app/oracle/oradata/clone/pdb3/test. 1985354

13 rows selected

 

From above,we can see primary and standby SCNs matching now.


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, we must refresh the standby control file to update the SCN#.

7. Use the following commands to shut down the standby database and then start it in NOMOUNT mode.


    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;


8. Restore the standby control file by using the control file on the primary database using service prim.

The following command restores the control file on the physical standby database by using the primary database control file.

RESTORE STANDBY CONTROLFILE FROM SERVICE <primary_tns_service>;

RMAN> restore standby controlfile from service prim;

Starting restore at 09-MAR-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service prim
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/u01/app/oracle/oradata/clone/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/clone/control02.ctl
Finished restore at 09-MAR-15

 

After this step, the names of files in the standby control file are the names that were used in the primary database.

NOTE:  Depending on the configuration, the path and/or names of the standby datafiles after the standby controlfile refresh may be correct and thus steps #9 and #10 can be skipped.  

 

Mount the standby database using the following command:

RMAN> alter database mount;

Statement processed
released channel: ORA_DISK_1


RMAN> report schema;

Starting implicit crosscheck backup at 09-MAR-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
Crosschecked 9 objects
Finished implicit crosscheck backup at 09-MAR-15

Starting implicit crosscheck copy at 09-MAR-15
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 09-MAR-15

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/fast_recovery_area/CLONE/archivelog/2015_03_05/o1_mf_1_17_11q13dm8_.arc
File Name: /u01/app/oracle/fast_recovery_area/CLONE/archivelog/2015_03_05/o1_mf_1_16_10q13dm8_.arc
File Name: /u01/app/oracle/fast_recovery_area/CLONE/archivelog/2015_03_05/o1_mf_1_2_bhk1ctcz_.arc
File Name: /u01/app/oracle/fast_recovery_area/CLONE/archivelog/2015_03_05/o1_mf_1_1_bhk17cw8_.arc

RMAN-06139: WARNING: control file is not current for REPORT SCHEMA
Report of database schema for database with db_unique_name CLONE

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    780      SYSTEM               ***     /u01/app/oracle/oradata/prim/system01.dbf
3    730      SYSAUX               ***     /u01/app/oracle/oradata/prim/sysaux01.dbf
4    90       UNDOTBS1             ***     /u01/app/oracle/oradata/prim/undotbs01.dbf
5    250      PDB$SEED:SYSTEM      ***     /u01/app/oracle/oradata/prim/pdbseed/system01.dbf
6    5        USERS                ***     /u01/app/oracle/oradata/prim/users01.dbf
7    590      PDB$SEED:SYSAUX      ***     /u01/app/oracle/oradata/prim/pdbseed/sysaux01.dbf
8    260      PDB1:SYSTEM          ***     /u01/app/oracle/oradata/prim/pdb1/system01.dbf
9    620      PDB1:SYSAUX          ***     /u01/app/oracle/oradata/prim/pdb1/sysaux01.dbf
10   5        PDB1:USERS           ***     /u01/app/oracle/oradata/prim/pdb1/pdb1_users01.dbf
16   260      PDB3:SYSTEM          ***     /u01/app/oracle/oradata/prim/pdb3/system01.dbf
17   620      PDB3:SYSAUX          ***     /u01/app/oracle/oradata/prim/pdb3/sysaux01.dbf
18   5        PDB3:USERS           ***     /u01/app/oracle/oradata/prim/pdb3/pdb1_users01.dbf
19   50       PDB3:TEST            ***     /u01/app/oracle/oradata/prim/pdb3/test.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    60       TEMP                 32767       /u01/app/oracle/oradata/prim/temp01.dbf
2    20       PDB$SEED:TEMP        32767       /u01/app/oracle/oradata/prim/pdbseed/pdbseed_temp01.dbf
3    373      PDB1:TEMP            32767       /u01/app/oracle/oradata/prim/pdb1/temp01.dbf
4    71       PDB3:TEMP            32767       /u01/app/oracle/oradata/prim/pdb3/temp01.dbf


9. Update the names of the data files and the temp files in the standby control file.

 

   Use the CATALOG command and the SWITCH command to update all the data file names.

        RMAN> catalog start with '<path where the actual standby datafile existed>';

        In this case

        RMAN> Catalog start with '/u01/app/oracle/oradata/clone/';

searching for all files that match the pattern /u01/app/oracle/oradata/clone

List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/oradata/clone/pdb1/pdb1_users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb1/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb1/system01.dbf
File Name: /u01/app/oracle/oradata/clone/pdbseed/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdbseed/system01.dbf
File Name: /u01/app/oracle/oradata/clone/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/system01.dbf
File Name: /u01/app/oracle/oradata/clone/undotbs01.dbf
File Name: /u01/app/oracle/oradata/clone/users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/pdb1_users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/system01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/test.dbf

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/oradata/clone/pdb1/pdb1_users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb1/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb1/system01.dbf
File Name: /u01/app/oracle/oradata/clone/pdbseed/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdbseed/system01.dbf
File Name: /u01/app/oracle/oradata/clone/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/system01.dbf
File Name: /u01/app/oracle/oradata/clone/undotbs01.dbf
File Name: /u01/app/oracle/oradata/clone/users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/pdb1_users01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/sysaux01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/system01.dbf
File Name: /u01/app/oracle/oradata/clone/pdb3/test.dbf

10. Switch to cataloged copy.

RMAN> SWITCH DATABASE TO COPY;

datafile 1 switched to datafile copy "/u01/app/oracle/oradata/clone/system01.dbf"
datafile 3 switched to datafile copy "/u01/app/oracle/oradata/clone/sysaux01.dbf"
datafile 4 switched to datafile copy "/u01/app/oracle/oradata/clone/undotbs01.dbf"
datafile 5 switched to datafile copy "/u01/app/oracle/oradata/clone/pdbseed/system01.dbf"
datafile 6 switched to datafile copy "/u01/app/oracle/oradata/clone/users01.dbf"
datafile 7 switched to datafile copy "/u01/app/oracle/oradata/clone/pdbseed/sysaux01.dbf"
datafile 8 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb1/system01.dbf"
datafile 9 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb1/sysaux01.dbf"
datafile 10 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb1/pdb1_users01.dbf"
datafile 16 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb3/system01.dbf"
datafile 17 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb3/sysaux01.dbf"
datafile 18 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb3/pdb1_users01.dbf"
datafile 19 switched to datafile copy "/u01/app/oracle/oradata/clone/pdb3/test.dbf"


Here, /u01/app/oracle/oradata/clone is the location of the data files on the physical standby database.
All data files must be stored in this location.

11. Use the current SCN returned in Step 4 to determine if new data files were added to the primary database since the standby database was last refreshed. If yes, these data files need to be restored on the standby from the primary database.

The following example assumes that the CURRENT_SCN returned in Step 6 is 1984232 and lists the data files that were created on the primary after the timestamp represented by this SCN:

SELECT file# FROM V$DATAFILE WHERE creation_change# >= 1984232;

If no files are returned in Step 11, then go to Step 13. If one or more files are returned in Step 11, then restore these data files from the primary database as in step 12.

12. If you are not connected to a recovery catalog, then use the following commands to restore data files that were added to the primary after the standby was last refreshed ( assuming datafile 21  added to the primary):

RUN
{
SET NEWNAME FOR DATABASE TO '/u01/app/oracle/oradata/clone';
RESTORE DATAFILE 21 FROM SERVICE prim;
}

If you are connected to a recovery catalog, then use the following command to restore data files that were added to the primary after the standby was last refreshed (assuming data file 21 added to the primary):

RESTORE DATAFILE 21 FROM SERVICE prim;



13. Update the names of the online redo logs and standby redo logs in the standby control file using one of the following methods:

 - Use the ALTER DATABASE CLEAR command to clear the log files in all redo log groups of the standby database. RMAN then recreates all the standby redo logs and the online redo log files.

 Note:

Clearing log files is recommended only if the standby database does not have access to the online redo log files and standby redo log
 files of the primary database( for ex: standby and primary at same server or using same ASM disk group). If the standby database has access to the redo log files of the primary database and the redo log file
 names of the primary database are OMF names, then the ALTER DATABASE command will delete log files on the primary database.

 - Use the ALTER DATABASE RENAME FILE command to rename the redo log files.
   Use a separate command to rename each log file.

   To rename log files, the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL. 
   Renaming log files is recommended when the number of online redo logs files and standby redo log files is the same
   in the primary database and the physical standby database.

   (Oracle Active Data Guard only) Perform the following steps to open the physical standby database:



On the primary database, switch the archived redo log files using the following command:

       

ALTER SYSTEM ARCHIVE LOG CURRENT;

 
On the physical standby database, run the following commands:

        RECOVER DATABASE;
        ALTER DATABASE OPEN READ ONLY;

     Start the managed recovery processes on the physical standby database by using the following command:


     ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


REFERENCES

NOTE:1646232.1 - ORA-19573 when trying to restore to standby with incremental backup From Primary or During any RMAN restore operation


标签：RESTORE,12c,Service,database,standby,app,oradata,oracle,u01
来源： https://blog.51cto.com/lhrbest/2703355

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

关于我们 | 联系我们 | 留言反馈

专注分享技术，共同学习，共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有