在DG備庫備份資料庫並恢復到一個主機上，報錯RMAN-06820

lhrbest發表於2020-07-27

資料庫

12C dataguard備庫備份archivelog出現報錯

Problem Description

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

SQL> select * from product_component_version ;

PRODUCT VERSION STATUS

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

NLSRTL 12.1.0.2.0 Production

Oracle Database 12c Enterprise Edition 12.1.0.2.0 64bit Production

PL/SQL 12.1.0.2.0 Production

TNS for Linux: 12.1.0.2.0 Production

備庫的狀態

SQL> select OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE from v$database;

OPEN_MODE PROTECTION_MODE DATABASE_ROLE

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

READ ONLY WITH APPLY MAXIMUM PERFORMANCE PHYSICAL STANDBY

SQL> select THREAD# ,SEQUENCE#,APPLIED from v$archived_log where APPLIED='NO' ;

no rows selected

在standby(備庫)備份archivelog時會報RMAN-06820，ORA-17629，ORA-17627的錯,但是最後歸檔還是備份成功了。

[oracle@localhost ~]$rman target /

RMAN> backup archivelog all;

Starting backup at 02-OCT-15

using target database control file instead of recovery catalog

RMAN-06820: WARNING: failed to archive current log at primary database

ORACLE error from target database:

ORA-17629: Cannot connect to the remote database server

ORA-17627: ORA-00942: table or view does not exist

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1156 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=2 sequence=132 RECID=135 STAMP=891367439

input archived log thread=1 sequence=172 RECID=134 STAMP=891367438

......

piece handle=/opt/oracle/oradata/MXCNSTB/backupset/2015_10_02/o1_mf_annnn_TAG20151002T144942_c0wbbdw1_.bkp tag=TAG20151002T144942 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

Finished backup at 02-OCT-15

解決方法：

在備庫上以sys使用者登入

rman target sys/password

可以參考以下文件：

RMAN-06820 ORA-17629 ORA-17627 ORA-01034 ORA-27101 During Backup of a Standby Database ( Doc ID 2042148.1 )

RMAN-06820 ORA-17629 During Backup at Standby Site ( Doc ID 1616074.1 )

RMAN-06820 ORA-17629 ORA-12154 During Backup of a Standby Database ( Doc ID 2025142.1 )

Dataguard Standby備份報錯RMAN-06820 ORA-17629解決

Oracle Dataguard 是官方重要HA 架構的組成部分。通過只讀的Standby 資料庫，可以在確保高可用的基礎上，將一部分報表、備份負載從主庫上分離出來，提高主庫效能。

根據Oracle 最佳實踐，主庫Primary 是可以不進行直接的備份，核心備份操作可以放在Standby 端進行操作，這樣不僅可以節省備份資源，還可以有效的將備份的效能消耗轉移到Standby 端進行。

本文記錄了筆者在Physical Standby 端進行RMAN 備份的時候，遇到錯誤資訊的問題解決。記錄下來，留待需要的朋友待查。

1 、環境說明

筆者使用Oracle 11gR2 進行測試，具體版本為11.2.0.4 。Data Guard Primary 和Standby 採用的版本完全相同。

SQL> select * from v$version;

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE 11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

在Standby 端，是採用Active Data Guard 只讀應用狀態。

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ ONLY WITH APPLY PHYSICAL STANDBY

2 、問題故障

在standby 端，使用RMAN 進行備份動作。進行全庫備份和歸檔日誌備份，備份之後嘗試刪除掉已經備份的日誌檔案。

[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalog

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 18 13:44:54 2015

RMAN> connect target /

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

進行RMAN 備份。

RMAN> backup database plus archivelog delete input;

Starting backup at 18-OCT-15

RMAN-06820: WARNING: failed to archive current log at primary database

ORACLE error from target database:

ORA-17629: Cannot connect to the remote database server

ORA-17627: ORA-00942: table or view does not exist

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=204 device type=DISK

specification does not match any archived log in the repository

backup cancelled because there are no files to backup

Finished backup at 18-OCT-15

Starting backup at 18-OCT-15

（篇幅原因，有省略 …… ）

handle=/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893423697_c26dj5nb_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 18-OCT-15

在備份過程中出現錯誤，錯誤提示上好像是要訪問Primary 端資料庫，之後由於許可權問題沒有能夠訪問。其他備份動作看似正常，備份集合顯示正確。

RMAN> list backup;

List of Backup Sets

===================

BS Key Size Device Type Elapsed Time Completion Time

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

6 27.46M DISK 00:00:00 18-OCT-15

BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20151018T133946

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_10_18/o1_mf_annnn_TAG20151018T133946_c26d52kd_.bkp

List of Archived Logs in backup set 6

Thrd Seq Low SCN Low Time Next SCN Next Time

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

1 22 1290925 18-OCT-15 1298642 18-OCT-15

1 23 1298642 18-OCT-15 1298901 18-OCT-15

1 24 1298901 18-OCT-15 1299107 18-OCT-15

1 25 1299107 18-OCT-15 1299528 18-OCT-15

1 26 1299528 18-OCT-15 1301585 18-OCT-15

1 27 1301585 18-OCT-15 1301853 18-OCT-15

1 28 1301853 18-OCT-15 1302226 18-OCT-15

1 29 1302226 18-OCT-15 1303310 18-OCT-15

1 30 1303310 18-OCT-15 1303858 18-OCT-15

1 31 1303858 18-OCT-15 1308314 18-OCT-15

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

11 Full 1.11G DISK 00:00:08 18-OCT-15

BP Key: 12 Status: AVAILABLE Compressed: NO Tag: TAG20151018T134526

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_10_18/o1_mf_nnndf_TAG20151018T134526_c26dhpdf_.bkp

List of Datafiles in backup set 11

File LV Type Ckp SCN Ckp Time Name

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

1 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_system_c2613wz5_.dbf

2 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_sysaux_c2613x03_.dbf

3 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_undotbs1_c2613x07_.dbf

4 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_users_c2613x0d_.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

12 Full 9.36M DISK 00:00:00 18-OCT-15

BP Key: 13 Status: AVAILABLE Compressed: NO Tag: TAG20151018T134541

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893423697_c26dj5nb_.bkp

SPFILE Included: Modification time: 18-OCT-15

SPFILE db_unique_name: VLIFESB

Standby Control File Included: Ckp SCN: 1310511 Ckp time: 18-OCT-15

3 、問題分析解決

這個問題很不合理，看似應該是Oracle Bug 之類的情況。查詢MOS ，發現了對應的Bug 資訊：RMAN-06820 ORA-17629 During Backup at Standby Site ( 文件 ID 1616074.1) 。

根據文章資訊，該問題Oracle 一個未釋出的bug ，編號為Bug 8740124 。當Oracle 嘗試訪問主庫過程中，需要連帶將全部的standby log 獲取到。當連線失敗的時候，就會發生報錯。

要解決該問題，Oracle 提供了一個變通的辦法，就是不要使用target / 匿名方式登入，而是使用sysdba 使用者的使用者名稱和密碼資訊進行直接連線。

實驗如下：

[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalog

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 18 13:49:56 2015

RMAN> connect target sys/oracle@vlifesb

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

RMAN> backup database plus archivelog delete input;

Starting backup at 18-OCT-15

current log archived at primary database

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=204 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

（篇幅原因，有省略 …… ）

handle=/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893425827_c26dssbt_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 18-OCT-15

沒有出現報錯資訊，問題解決。

4 、結論

筆者思考一下，這個變通策略還是利用了主庫和備庫在sysdba 使用者的密碼相同這個策略。在備份的時候，將顯示記錄的sysdba 使用者密碼輸入進去，用於進行遠端Primary 登入和獲取。

RMAN-06820 ORA-17629 During Backup at Standby Site (Doc ID 1616074.1)

In this Document

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.4 and later
Information in this document applies to any platform.

SYMPTOMS

RMAN archivelog backup at the standby site is throws the following errors at the start of the job:

Starting backup at 15-JAN-2014 13:44:46

RMAN-06820: WARNING: failed to archive current log at primary database

ORACLE error from target database:

ORA-17629: Cannot connect to the remote database server

ORA-17627: ORA-01017: invalid username/password; logon denied 

ORA-17629: Cannot connect to the remote database server

But the rest of the backup actually complete successfully:

skipping archived log of thread 1 with sequence 607; already backed up

skipping archived log of thread 1 with sequence 614; already backed up

channel t1: starting archived log backup set

channel t1: specifying archived log(s) in backup set

input archived log thread=1 sequence=678 RECID=290 STAMP=836919086

input archived log thread=1 sequence=679 RECID=291 STAMP=836919369

input archived log thread=1 sequence=680 RECID=292 STAMP=836919706

input archived log thread=1 sequence=681 RECID=293 STAMP=836919873

channel t1: starting piece 1 at 15-JAN-2014 13:44:52

channel t1: finished piece 1 at 15-JAN-2014 13:46:17

piece handle=LOG_THMDB_20140115_171228_1_1 tag=LOG_TWMDB comment=API Version 2.0,MMS Version 5.4.1.0

channel t1: backup set complete, elapsed time: 00:01:25

Finished backup at 15-JAN-2014 13:46:17

CHANGES

Database was upgraded to 11.2.0.4

CAUSE

Change in 11.2.0.4 onward

Per 'unpublished' Bug 8740124, as of 11.2.0.4, we now include the current standby redo log as part of an RMAN archivelog backup at the standby site. This is achieved by forcing a log switch at the primary site.

However, the connection to the primary failed when attempting to do so.

This is due to this bug:
Bug 17580082 - ACTIVE STANDBY - RMAN-06820: WARNING: FAILED TO ARCHIVE CURRENT LOG AT PRIMARY
Status: 32 - Not a Bug. To Filer

SOLUTION

Workaround

Do not use operating system authentication to login with RMAN. Use a username and password.

That is, do not use just the "/" (operating system authentication) connect to the standby database:

$ rman target /

Connecting as 'rman target /'

# it gets the sys user but not the password and so, it does NOT mean it is being explicitly
# specified to connect as sysdba.

Instead put in the username and password for the SYSDBA user:

$ rman target sys/password@stby

Connecting as 'rman target sysdba_user/password@stby'

Note: The password, within the password file, for the primary and standby should be identical.

# This is an explicit connection as sysdba

Note from Bug: 17580082

As for having ability to connect from standby to primary, there are few options
.
(Option 1) is to connect as SYSDBA, like: 'rman target sysdba_user/password@stby'
(Option 2) is to setup wallets using which authentication can be done (more details can be obtained from SECURITY team here),
(Option 3) use CONNECT command inside the command file supplied to RMAN. For example: RMAN> connect target sysdba_user/password@stby
.

Currently only SYSDBA is allowed to connect for switch or resync operation.

Enhancement Request/Bug 18070699 allows for the use of other user/password apart from sys password to connect to remote database for RMAN operation.

Bug 18070699: ALLOW NON-SYS USERNAME GRANTED SYSDBA TO RESYNC DB_UNIQUE_NAME ALL

Patches are available for this issue by searching bug 21476308 for patch name or number.

REFERENCES

BUG:17580082 - ACTIVE STANDBY - RMAN-6820: WARNING: FAILED TO ARCHIVE CURRENT LOG AT PRIMARY
NOTE:8740124.8 - Bug 8740124 - Current standby redo log group should be included in the database backup by RMAN
NOTE:1301769.1 - ORA-17629 : RMAN Resync Catalog from db_unique_name all fails

RMAN-06820 ORA-17629 ORA-12154 During Backup of a Standby Database (Doc ID 2025142.1)

In this Document

APPLIES TO:

Enterprise Manager for Oracle Database - Version 11.2.0.4 and later
Information in this document applies to any platform.

SYMPTOMS

While taking the backup from standby db, the below error is returned:

RMAN> connect target sys/passwd@tns_standby

RMAN-06009: using target database control file instead of recovery catalogRMAN-08030: allocated channel: ch1

RMAN-08500: channel ch1: SID=70 device type=SBT_TAPE

RMAN-08526: channel ch1: CommVault Systems for Oracle: Version 9.0.0(BUILD84)

RMAN-03090: Starting backup at 25-JUN-15

RMAN-06820: WARNING: failed to archive current log at primary database

RMAN-06003: ORACLE error from target database: 

ORA-17629: Cannot connect to the remote database server

ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified

ORA-17629: Cannot connect to the remote database server

CHANGES

Sqlnet configuration has been modified. For example, entries in the tnsnames.ora file were removed in the standby server.

CAUSE

Sqlnet configuration modifications preventing RMAN from connecting to the primary database to switch online logs. This is new functionality in 11.2.0.4 and beyond.

In this example, a removal of TNS entry in the standby used by RMAN is missing.

SOLUTION

1. Generate RMAN trace as below:

$ rman target sys/passwd@tns_standby debug trace=/tmp/rmanDebug_new.trc log=/tmp/rmanLog_new.txt

RMA
N> Run the backup script

The debug output will show something like:

Rman trace file:

============

DBGMISC: EXITED krmkgconf [09:51:57.558] elapsed time [00:00:00:00.016]

DBGMISC: remote_resync=0, for_dbuname=chlbbkof2; source_cs=; dest_cs=null [09:51:57.558] (krmkgetconnids)

DBGSQL: TARGET> begin :lprimary_db_cs := sys.dbms_backup_restore.get_connect_identifier (dbuname=> :primary_dbuname); end; 

DBGSQL: sqlcode = 0

DBGSQL: B :lprimary_db_cs = <service name 2>

DBGSQL: B :primary_dbuname = 

  DBGRCVMAN: getConfig: configurations exists for this site

DBGSQL: ENTERED krmkosqlerr

DBGSQL: TARGET> declare null_retVal varchar2(1); begin null_retVal := sys.dbms_backup_restore.remoteSQLExecute( source_dbuname=> :primary_dbuname, source_cs => :lprimary_db_cs, stmt => 'alter system archive log current'); end; 

DBGSQL: sqlcode = 17629

DBGSQL: B :primary_dbuname = chlbbkof2

DBGSQL: B :lprimary_db_cs = <service_name2> =============================> RMAN is using the service name "<service_name2>" to connect to the primary database to perform the log switch.

DBGSQL: error: ORA-17629: Cannot connect to the remote database server (krmkosqlerr)

DBGSQL: ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified (krmkosqlerr)

DBGSQL: ORA-17629: Cannot connect to the remote database server (krmkosqlerr)

DBGSQL: ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE", line 7812 (krmkosqlerr)

DBGSQL: ORA-06512: at line 1 (krmkosqlerr)

DBGSQL: (krmkosqlerr)

DBGSQL: EXITED krmkosqlerr

RMAN-06820: WARNING: failed to archive current log at primary database

DBGMISC: ENTERED krmkursr [09:56:05.681]

2. Search for the string " lprimary_db_cs" in the trace file:

DBGSQL: B :lprimary_db_cs = <service_name2>

3. Add the corresponding entry in the tnsnames.ora file of standby database which should be able to ping to primary as below:

service_name2 =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = chbkofdb2.primary_host.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME =service_name2)
    )
)

4. If entry exists, test the connection. From standby server, execute:

$  sqlplus 'sys/password@<service name found in #2> as sysdba' 

NOTE: Below procedure describes how RMAN determines the primary database connect string identifier to perform primary log switch when archive backup is started on standby.

1. First, it checks primary's DB_UNIQUE_NAME with below query:

SQL> select PRIMARY_DB_UNIQUE_NAME from V$DATABASE;

PRIMARY_DB_UNIQUE_NAME
------------------------------
PRIMARY

2. Then, it checks RMAN configuration to see if any CONNECT IDENTIFIER is defined for that particular DB_UNIQUE_NAME:

RMAN> show all;

RMAN configuration parameters for database with db_unique_name STANDBY1 are:
...
CONFIGURE DB_UNIQUE_NAME 'PRIMARY' CONNECT IDENTIFIER 'TestConnection';
...

In this example, since CONNECT IDENTIFIER is defined for DB_UNIQUE_NAME 'PRIMARY', RMAN will use the same i.e. 'TestConnection'

3. If, CONNECT IDENTIFIER is NOT defined in RMAN configuration for this particular DB_UNIQUE_NAME, RMAN will next check if any remote log archive destination is configured for this DB_UNIQUE_NAME:

SQL> select DEST_ID,DESTINATION from V$ARCHIVE_DEST where DB_UNIQUE_NAME='PRIMARY' and TARGET='REMOTE';

DEST_ID DESTINATION
---------- --------------------
2 PRIMARYCONNECT

In this example, RMAN will use connect identifier PRIMARYCONNECT for primary connection (This is valid when there is NO RMAN configuration to specify CONNECT IDENTIFIER for DB_UNIQUE_NAME 'PRIMARY')

REFERENCES

NOTE:1419923.1 - Howto make a consistent RMAN backup in an Standby database in Active DataGuard mode
NOTE:1616074.1 - RMAN-06820 ORA-17629 During Backup at Standby Site

About Me

........................................................................................................................

● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除

● 本文在個人微 信公眾號（
DB寶）上有同步更新

● QQ群號：
230161599
、618766405，微信群私聊

● 個人QQ號（646634621），微 訊號（db_bao），註明新增緣由

● 於 2020年7月 在西安完成

● 最新修改時間：2020年7月

● 版權所有，歡迎分享本文，轉載請保留出處

........................................................................................................................

●
小麥苗的微店：
https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

● 小麥苗出版的資料庫類叢書：
http://blog.itpub.net/26736162/viewspace-2142121/

●
小麥苗OCP、OCM、高可用、DBA學習班：
http://blog.itpub.net/26736162/viewspace-2148098/

● 資料庫筆試面試題庫及解答：
http://blog.itpub.net/26736162/viewspace-2134706/ 

........................................................................................................................
請掃描下面的二維碼來關注小麥苗的微 信公眾號（
DB寶）及QQ群（230161599、618766405）、新增小麥苗微 信（db_bao），
學習最實用的資料庫技術。 


........................................................................................................................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2707187/，如需轉載，請註明出處，否則將追究法律責任。

【備份恢復】上：還原和恢復資料庫（即將一個庫還原到另外一個庫）
2016-10-17
資料庫
【備份恢復】從備份恢復資料庫
2015-01-20
資料庫
ORACLE DG從庫 Rman備份恢復
2020-10-10
Oracle
rman備份資料庫後到另一臺機器上恢復的例子
2012-03-17
資料庫
資料庫備份與異機恢復——熱備份方式
2013-11-18
資料庫
【備份恢復】下：還原和恢復資料庫（即將一個庫還原到另外一個庫）
2016-10-17
資料庫
備份與恢復：polardb資料庫備份與恢復
2020-11-13
資料庫
主庫模型調整需要做一個全庫備份，備份與恢復指令碼
2011-08-20
模型指令碼
【備份恢復】noarchive模式下使用增量備份恢復資料庫
2016-10-17
Hive模式資料庫
【備份恢復】在 ARCHIVELOG 模式下執行資料庫還原和恢復操作（源庫備份源庫恢復）
2016-10-17
Hive模式資料庫
RMAN備份恢復——RAC環境資料庫的備份（一）
2007-05-03
資料庫
RMAN備份恢復——備份到帶庫的效能
2007-05-11
RAC資料庫的RMAN備份異機恢復到單節點資料庫
2017-08-28
資料庫
達夢資料庫備份恢復
2020-01-13
資料庫
postgresql備份與恢復資料庫
2020-12-15
SQL資料庫
mongo資料庫備份與恢復
2017-04-01
Go資料庫
資料庫的備份與恢復
2010-08-25
資料庫
Informix資料庫備份與恢復
2006-05-15
ORM資料庫
備份和恢復postgreSQL資料庫
2013-05-03
SQL資料庫
資料庫備份與恢復----第一課
2007-05-16
資料庫
rman資料庫全庫備份與恢復
2013-12-19
資料庫
Oracle DG從庫 Rman備份恢復測試
2018-01-22
Oracle
一個備份集同時恢出dataguard的主庫&備庫
2014-01-13
Oracle12c多租戶資料庫備份與恢復 - 僅備份一個PDB資料庫
2014-03-07
Oracle資料庫
RMAN備份恢復——備份到帶庫的效能（二）
2007-05-16
資料庫資料的恢復和備份
2015-08-30
資料庫
RMAN備份恢復整個庫
2015-03-21
PostgreSql資料庫的備份和恢復
2021-04-17
SQL資料庫
Mongo 資料庫備份和恢復命令
2023-12-24
Go資料庫
直接透過備份恢復資料庫
2015-01-28
資料庫
mysql的資料庫備份與恢復
2013-01-04
MySql資料庫
oracle資料庫的備份與恢復
2008-04-01
Oracle資料庫
備份和恢復SQL Server資料庫
2009-05-13
SQLServer資料庫
資料庫備份與恢復技術
2024-03-22
資料庫
資料庫異機冷備恢復
2012-09-11
資料庫
RAC一個節點恢復另一個節點在帶庫上的備份
2009-07-27
ClickHouse資料庫單機安裝及備份恢復
2022-11-24
資料庫
RMAN備份恢復——RAC環境資料庫的備份(zt)
2007-06-18
資料庫

在DG備庫備份資料庫並恢復到一個主機上，報錯RMAN-06820

Dataguard Standby備份報錯RMAN-06820 ORA-17629解決

APPLIES TO:

SYMPTOMS

CHANGES

CAUSE

SOLUTION

REFERENCES

APPLIES TO:

SYMPTOMS

CHANGES

CAUSE

SOLUTION

REFERENCES

相關文章