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登录和获取。
--------------------------------------推荐阅读 --------------------------------------
RMAN备份时遭遇ORA-19571
RMAN 配置归档日志删除策略
Oracle基础教程之通过RMAN复制数据库
RMAN备份策略制定参考内容
RMAN备份学习笔记
Oracle数据库备份加密 RMAN加密
RMAN备份时遇到ORA-19588
--------------------------------------分割线 --------------------------------------
：