我的情况是：

在备库备份归档日志的时候，非常慢，命令发出去后，等了10分钟左右才返回RMAN-06820错误。原因是，我的主库是禁止备库主动连接的，所以这里会等待这么久。

RMAN-06820: WARNING: failed to archive current log at primary database
Connect identifier for DB_UNIQUE_NAME lhrlisdb not configured
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=7426 device type=DISK
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=237006 RECID=3406 STAMP=1046697950
input archived log thread=2 sequence=177484 RECID=3405 STAMP=1046696217

在DG备库备份数据库并恢复到一个主机上，报错RMAN-06820

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 =
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 = =============================> RMAN is using the service name "" 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 =

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@ 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），
学习最实用的数据库技术。 


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