【12c】12c RMAN新特性之通過網路遠端恢復資料庫（RESTORE/Recover from Service）
【12c】12c RMAN新特性之通過網路遠端恢復資料庫（RESTORE/Recover from Service）
通過網路遠端恢復資料庫（ Restore/Recover from Service ）
在 Oracle 12c 中，可以在主資料庫和備用資料庫之間用一個服務名重新獲得或恢復資料檔案、控制檔案、引數檔案（ SPFILE ）、表空間或整個資料庫。這對於同步主資料庫和備用資料庫極為有用。
當主資料庫和備用資料庫之間存在相當大的差異時，不再需要複雜的前滾流程來填補它們之間的差異。 RMAN 能夠通過網路執行備用恢復以進行增量備份，並且可以將它們應用到物理備用資料庫。可以用服務名直接將所需資料檔案從備用點拷貝至主站，這是為了防止主資料庫上資料檔案、表空間的丟失，或是沒有真正從備份集恢復資料檔案。
具體的幾種用法：
資料庫級別： restoredatabase from service < 服務別名 >
表空間： restoretablespace from service < 服務別名 >
控制檔案： restorecontrolfile to ' 指定的位置 ' fromservice < 服務別名 >
SPFILE: restore spfile from service < 服務別名 >
以下命令演示瞭如何用此新功能執行一個前滾來對備用資料庫和主資料庫進行同步。在物理備用資料庫上：
rman target "username/password@standby_db_tnsas SYSBACKUP"
RMAN>RECOVER DATABASE FROM SERVICEprimary_db_tns USING COMPRESSED BACKUPSET;
以上案例使用備用資料庫上定義的 primary_db_tns 連線字串連線到主資料庫，然後執行了一個增量備份，再將這些增量備份傳輸至備用目的地，接著將應用這些檔案到備用資料庫來進行同步。然而，需要確保已經對 primary_db_tns 進行了配置，即在備份資料庫端將其指向主資料庫。
在以下命令中，演示了通過從備用資料庫獲取資料檔案來恢復主資料庫上丟失的資料檔案。在主資料庫上：
rman target "username/password@primary_db_tnsas 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 RESTORE command. 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 RESTORE command. 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指定的物件型別：
database
datafile
tablespace
控制檔案
SPFILE
當在主庫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即可
從Oracle 12c開始，可以使用RMAN命令RECOVER STANDBY DATABASE通過網路重新整理備用資料庫。
RECOVER STANDBY DATABASE命令重新啟動備用例項，從主資料庫重新整理控制檔案，並自動重新命名資料檔案，臨時檔案和聯機日誌。它還原已新增到主資料庫的新資料檔案，並將備用資料庫恢復到當前時間。
使用RECOVER STANDBY DATABASE命令重新整理備用資料庫時，可以指定FROM SERVICE子句或NOREDO子句。 FROM SERVICE子句指定主服務的名稱。 NOREDO子句指用於重新整理備份，在恢復期間不能應用歸檔的重做日誌檔案，這允許備用資料庫前滾到特定時間或SCN。
在嘗試與主資料庫同步之前，必須在備用資料庫上手動停止MRP。以下是使用RECOVER STANDBY DATABASE命令的示例。它顯示了PFILE子句的可選用法，以指定備用資料庫的引數檔案（在spfile不可用時使用）。
RECOVER STANDBY DATABASE FROM SERVICE service_name PFILE=pfile_location;
RMAN通過建立增量備份來轉發物理備用資料庫，該增量備份包含對主資料庫的更改，通過網路將增量備份傳輸到物理備用資料庫，然後將增量備份應用於物理備用資料庫。主資料庫上的資料檔案的所有更改（從備用資料檔案頭中的SCN開始）都包含在增量備份中。
可以使用RECOVER ... FROM SERVICE命令將物理備用資料庫上的資料檔案與主資料庫上的資料檔案同步。此命令重新整理備用資料檔案並將它們前滾到與主資料庫相同的時間點。但是，備用控制檔案仍包含舊SCN值，這些值低於備用資料檔案中的SCN值。因此，要完成物理備用資料庫的同步，必須重新整理備用控制檔案，然後更新重新整理的備用控制檔案中的資料檔名，聯機重做日誌檔名和備用重做日誌檔名。
1）確保滿足以下先決條件：
在物理備用資料庫和主資料庫之間建立Oracle Net連線。
可以通過在物理備用資料庫的tnsnames.ora檔案中新增與主資料庫相對應的條目來完成此操作。
主資料庫和物理備用資料庫上的密碼檔案是相同的。
主資料庫和物理備用資料庫的初始化引數檔案中的COMPATIBLE引數設定為12.0。
2）啟動RMAN並將其作為目標連線到物理備用資料庫。建議連線到恢復目錄。
以下命令作為TARGET連線到物理備用資料庫，並作為CATALOG連線到恢復目錄。使用已被授予SYSBACKUP許可權的hr使用者建立與物理備用資料庫的連線。物理備用資料庫的網路服務名稱是pdbcndba_s，恢復目錄的網路服務名稱是catpdbcndba_s。
CONNECT TARGET "hr@pdbcndba_s AS SYSBACKUP";
CONNECT CATALOG rman@catpdbcndba_s;
3）使用帶有FROM SERVICE子句的RECOVER STANDBY DATABASE命令前滾物理備用資料庫。
FROM SERVICE子句指定必須使用物理備用資料庫前滾的主資料庫的服務名稱。前滾操作後重新啟動備用資料庫。
以下示例使用服務名稱為pdbcndba_p的主資料庫前滾物理備用資料庫。
RECOVER STANDBY DATABASE FROM SERVICE pdbcndba_p;
4）（僅適用於Active Data Guard）執行以下步驟以恢復重做資料並以只讀模式開啟物理備用資料庫：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE UNTIL CONSISTENT;
ALTER DATABASE OPEN READ ONLY;
5）在物理備庫啟動MRP
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
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.
![【12c】12c RMAN新特性之通過網路遠端恢復資料庫（RESTORE/Recover from Service）]()
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#.
![【12c】12c RMAN新特性之通過網路遠端恢復資料庫（RESTORE/Recover from Service）]()
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;
![【12c】12c RMAN新特性之通過網路遠端恢復資料庫（RESTORE/Recover from Service）]()
REFERENCES
NOTE:1646232.1 - ORA-19573 when trying to restore to standby with incremental backup From Primary or During any RMAN restore operation
About Me
|
........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub（ http://blog.itpub.net/26736162 ）、部落格園（ http://www.cnblogs.com/lhrbest ）和個人weixin公眾號（ xiaomaimiaolhr ）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ........................................................................................................................ ● QQ群號： 230161599 （滿） 、618766405 ● weixin 群：可加我 weixin ，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ） ，註明新增緣由 ● 於 2018-04-01 06:00 ~ 2018-04-31 24:00 在魔都完成 ● 最新修改時間：2018-07-01 06:00 ~ 2018-07-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店 ： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書 ： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班 ： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁 ： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 weixin 客戶端 掃描下面的二維碼來關注小麥苗的 weixin 公眾號（ xiaomaimiaolhr ）及QQ群（DBA寶典）、新增小麥苗 weixin ， 學習最實用的資料庫技術。
........................................................................................................................ |
|
|
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2152717/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【12c】12c RMAN新特性之recover table（表級別恢復）
- 12c RMAN新特性之Recover Table
- Oracle 12C新特性-RMAN恢復表Oracle
- [20190718]12c rman新特性 表恢復.txt
- Oracle 12c系列(八)｜RMAN (FROM SERVICE)Oracle
- 【12c】12c RMAN新特性之UNTIL AVAILABLE REDO--自動恢復到REDO終點的步驟簡化AI
- 12C PDB使用RMAN的4種完全恢復場景
- 通過duplicat恢復資料庫資料庫
- 【12c 庫異機恢復】實驗
- Oracle 12C新特性-資料泵新引數(LOGTIME)Oracle
- 12c新特性，線上move資料檔案
- Oracle 19c透過recover standby database from service修復GAP案例OracleDatabase
- Oracle 12C新特性-資料泵新引數(VIEWS_AS_TABLES)OracleView
- 利用Omni Recover恢復IOS資料iOS
- Oracle 12C新特性-History命令Oracle
- Oracle 12C新特性In-MemoryOracle
- Oracle 12c 兩個新特性Oracle
- 【RMAN】Oracle11g透過rman升級到12cOracle
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- [20181023]12c網路資料壓縮.txt
- Oracle 12c 備份與恢復Oracle
- Oracle 12c新特性--ASMFD（ASM Filter Driver）特性OracleASMFilter
- Oracle 12c系列(九) | 通過unplug與plug方式升級pdb資料庫Oracle資料庫
- 資料庫恢復過程資料庫
- MySQL 通過 binlog 恢復資料MySql
- RMAN備份恢復典型案例——資料庫卡頓資料庫
- 【資料庫資料恢復】透過資料頁恢復Sql Server資料庫資料的過程資料庫資料恢復SQLServer
- Oracle 12c資料庫安裝Oracle資料庫
- lockdown profile 12c之後的許可權控制新特性
- Oracle 12c 新特性之臨時Undo--temp_undo_enabledOracle
- Omni Recover for Mac(iPhone資料恢復軟體)MaciPhone資料恢復
- iPhone資料恢復軟體：Omni Recover for MaciPhone資料恢復Mac
- Oracle 12c新特性---Rapid Home Provisioning (RHP)OracleAPI
- Oracle 12c RMAN全攻略Oracle
- oracle 12c rman備份pdbOracle
- RMAN恢復之RMAN-06555處理
- 伺服器資料恢復—透過拼接資料庫碎片恢復SqlServer資料庫資料的資料恢復案例伺服器資料恢復資料庫SQLServer
- Oracle 12c 使用RMAN搭建物理備庫(RAC to RAC)Oracle