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

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

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

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

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登录和获取。