当前位置:  数据库>oracle

DataGuard Standby备份报错RMAN-06820 ORA-17629解决

    来源: 互联网  发布时间:2017-06-20

    本文导语: Oracle Dataguard是官方重要HA架构的组成部分。通过只读的Standby数据库,可以在确保高可用的基础上,将一部分报表、备份负载从主库上分离出来,提高主库性能。 根据Oracle最佳实践,主库Primary是可以不进行直接的备份,核心备份...

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 

--------------------------------------分割线 --------------------------------------


    
 
 

您可能感兴趣的文章:

 
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。












  • 相关文章推荐
  • ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
  • Oracle Dataguard备库失败与主库响应测试
  • Linux下Oracle10_Dataguard配置与应用
  • Oracle 11g Dataguard参数详解


  • 站内导航:


    特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

    ©2012-2021,,E-mail:www_#163.com(请将#改为@)

    浙ICP备11055608号-3