DataGuard环境下备库RMAN-05021问题有效性解决方案

 

Dataguard环境作为Oracle官方重要的HA功能组件,在实践领域有非常多的应用场景和成功案例。同任何技术一样,在配置过程中,会出现一些问题需要解决。本文主要介绍在修改Physical Standby备份Rman参数中出现的问题和解决策略。

 

1、问题描述

 

笔者环境为11.2.0.4Dataguard环境,两台服务器配置为双单节点的Physical Standby。在配置备库的RMAN信息中,出现如下问题:

 

 

RMAN> connect target sys/oracle

 

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

 

RMAN> show all;

 

RMAN configuration parameters for database with db_unique_name URESTB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

(篇幅原因,有省略……

 

RMAN> configure retention policy to recovery window of 15 days;

 

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 12/31/2015 08:55:16

RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file

 

 

从提示信息情况看,在Standby端的RMAN配置项目是不能进行修改的。从MOS资料上看,这个问题的根源在于Standby端的控制文件control file是一个只读文件。在control file中,Oracle将数据文件、日志(归档和在线)、备份信息都保存在其中。对于Standby端,Control File是一个只读的文件内容,通过常规的修改配置手段,是不能够修改配置内容的。

 

2、官方两种处理策略

 

MOS ID 1519386.1中,提出了两种潜在的处理方法。第一种处理策略是在进行备份的时候,将配置内容直接写在备份还原操作语句中。

 

 

RMAN> list backup summary;

 

 

List of Backups

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

Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

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

61      B  A  A DISK        21-DEC-15       1       1       NO         TAG20151221T153209

62      B  F  A DISK        21-DEC-15       1       1       NO         TAG20151221T153322

63      B  F  A DISK        21-DEC-15       1       1       NO         TAG20151221T153347

64      B  A  A DISK        31-DEC-15       1       1       NO         TAG20151231T091532

65      B  F  A DISK        31-DEC-15       1       1       NO         TAG20151231T091548

66      B  A  A DISK        31-DEC-15       1       1       NO         TAG20151231T091606

67      B  F  A DISK        31-DEC-15       1       1       NO         TAG20151231T091607

 

 

按照当前的一份冗余策略,就会删除掉1221日的记录。

 

 

RMAN> delete obsolete;        

 

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

using channel ORA_DISK_1

Deleting the following obsolete backups and copies:

Type                 Key    Completion Time    Filename/Handle

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

Backup Set           61     21-DEC-15        

  Backup Piece       62     21-DEC-15         

 

/u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_annnn_TAG20151221T153209_c7hbry5x_.bkp

Backup Set           62     21-DEC-15        

  Backup Piece       63     21-DEC-15         

 

/u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_nnndf_TAG20151221T153322_c7hbt2l2_.bkp

Backup Set           63     21-DEC-15        

  Backup Piece       64     21-DEC-15         

 

/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_12_21/o1_mf_s_899017209_c7hbtvxo_.bkp

 

Do you really want to delete the above objects (enter YES or NO)? no

 

 

直接指定obsolete窗口在RMAN命令窗口。

 

 

RMAN> delete obsolete recovery window of 5 days;

 

using channel ORA_DISK_1

no obsolete backups found

 

 

第二种方法是从Primary中拷贝处一份全新的standby control file,之前修改好RMAN参数,之后转移到Standby中。作为新的Standby进行处理加载。

 

这个方案,笔者进行了详细测试,最后没有成功。主要原因是修改内容太多,操作步骤过于复杂。

 

ü  对于切换过来的Standby Control File,所有的数据文件、在线日志都需要重新进行定位重新命名;

ü  在调整文件名过程中,还要终止文件自动管理功能;

ü  备库上所有的归档日志、备份信息和同步时间点信息,都会丢失;

 

基于此,笔者并不推荐使用这种方法。

 

3、切换Switchover解决问题

 

经过思考,笔者提出了一种假说。如果Control FileStandby端是不允许进行修改,但是在Primary端允许修改的话。可否进行一次有准备的Switchover动作,让Standby端临时性变为可以修改的Control File。修改之后再Switchover就可以了。

 

实验过程如下,首先在主库上进行角色切换动作。

 

 

SQL> select open_mode, database_role from v$database;

 

OPEN_MODE            DATABASE_ROLE

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

READ WRITE           PRIMARY

 

SQL> alter database commit to switchover to standby with session shutdown;

 

Database altered.

 

SQL> quit

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

With the Partitioning, OLAP, Data Mining and Real Application Testing options

[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ ps -ef | grep pmon

oracle   30720 30659  0 10:40 pts/0    00:00:00 grep pmon

 

 

主库切换之后,自动停机。下面进行备库操作。

 

 

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ sqlplus /nolog

 

SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:38:32 2016

 

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

SQL> conn / as sysdba

Connected.

SQL> select open_mode, database_role from v$database;

 

OPEN_MODE            DATABASE_ROLE

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

READ ONLY WITH APPLY PHYSICAL STANDBY

 

 

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

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

TO PRIMARY

 

 

SQL> alter database commit to switchover to primary with session shutdown;

 

Database altered.

 

SQL> select open_mode, database_role from v$database;

 

OPEN_MODE            DATABASE_ROLE

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

MOUNTED              PRIMARY

 

SQL> alter database open;

Database altered.

 

 

原来的主库(先备库)启动,进行Redo Apply过程。

 

 

[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ sqlplus /nolog

 

SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:42:37 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 2471931904 bytes

Fixed Size                  2255752 bytes

Variable Size             738198648 bytes

Database Buffers         1711276032 bytes

Redo Buffers               20201472 bytes

Database mounted.

SQL> alter database recover managed standby database using current logfile disconnect;

Database altered.

 

--日志传输正常。

SQL> select STATUS from v$archive_dest_status;

 

STATUS

---------

VALID

VALID

INACTIVE

 

 

修改原备库RMAN项目。

 

 

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

 

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 10:48:47 2016

 

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> show all;

 

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION ON;

 

RMAN> configure retention policy to recovery window of 15 days;

 

new RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

new RMAN configuration parameters are successfully stored

 

RMAN> show all;

 

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

 

 

 

下面就可以使用相同的方法将原来的PrimaryStandby关系切换回来。由于篇幅所限,不进行详细说明。操作后,修改的参数生效。

 

 

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

 

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 11:11:18 2016

 

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> show all;

 

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

 

 

3、结论

 

综合上面的三种方法,理论上都能够解决我们面临的实际问题。但是在实践环境,特别是投产系统中,我们要从系统停机窗口、备份方案可用性和操作复杂性等多个角度进行综合评估,作出最好的判断。

 


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-1976242/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-1976242/

基于rman时间点的恢复-前滚后滚 概要: 数据库版本:11.2.0.4 系统:centos7.5 设置控制文件自动份: RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name ORCL are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # def.. 阅读详情

相关推荐

RMAN-05021

报错:RMAN-05021:this configuration cannot be changed for a BACKUP or STANDBY control file。-----------脚本中设置份保留策略。将 RMAN 保留策略设置为冗余 1。每次全份后都会删除之前的所有份。主要时rman份策略默认是1。使用通道 ORA_DISK_1。删除以下已废弃的份和副本。

qq_35435160的博客 800

[20151022]dataguard与修改RMAN的配置

[20151022]为什么dataguard上面无法修改RMAN的配置.txt --昨天有人问这个问题,链接如下: http://www.itpub.net/thread-1940567-1-1.html --我自己也测试看看: 1.测试环境: SCOTT@test> @ver1 PORT_STRING...

weixin_33681778的博客 142

Oracle 不完全恢复遇到的ORA-600错误

一个resetlogs后恢复表的场景: 场景描述: 数据正常运行,由于表B丢失,此时进行一次不完全恢复,不完全恢复至scn1067392,然后进行open resetlogs打开,此时开启了一个新的化身线,在刚打开后,又误删除了表A,此时想要恢复表A,将表A再次恢复至scn1067392,将表A进行恢复。 进行一次全: [oracle@server1 ~]$ rman target / RMAN> backup as compressed backupset database; 查看数据库当前化

dbhang的博客 1187

控制文件恢复与

控制文件恢复与份详解及案例 通常,数据库的控制文件不止一个,10g默认为3个都在文件目录/oradata/orcl;11g默认2个,其中一个在FRA中。 也可以手动添加更多的控制文件互为镜像,进程对其写的操作都一样,会写入所有控制文件,因为互为镜像的控制文件完全一致。但是进程对读控制文件,则只读取第一个(control_files参数)。所有,当第一个控制文件出错,读写都会出错。其他控制文

LinusFay 2063

ORACLE中采用rman份异机恢复数据库详细过程

场景: 有一个生产的用户下面所有的表都不见了,怀疑人为被删除了,现在需要用份去恢复下,找出原来的表,线上是oracle dataguard环境,有全份文件,准去测试恢复一下。 1,从生...

714

修改Standby DB的rman配置

提示:RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file。如果想继续修改可执行上面的命令添加,或用以下命令删除,() 内的值为CONF# 号。此时standbydb中没有相关配置信息。可以看到信息已添加到stangbydb中。一、直接在standbydb上修改:保留2次有效份。二、sqlplus登录Standbydb。

楚枫默寒的博客 264

RMAN份报错

 此文档为亲自手动整理有错误请大家提出(邮箱:327568824@qq.com) 1.1.1RMAN份报错 1.1.1.1 问题及现象 channelORA_DISK_1: starting piece 1 at 05-MAY-15 RMAN-00571:=======================================================

不再疯要傻 1571

使用rman份和恢复standby数据库--基本配置(一)

使用rman份和恢复standby数据库1、在主中tnsnames.ora增加以下内容---rman catalogORCL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP...

congshanlan2358的博客 464

Oracle坏块处理

有时Oracle数据文件的损坏只是一小部分块:文件仍可用,但特定块被损坏。这种情况下,文件将保持联机,终端用户可能不知道存在的问题,直到读取到坏块时才会发现。如果一个会话命中一个坏块,它将返回错误给用户进程,同时将一条消息...

cldh1492的博客 2027

Oracle 份与恢复--数据文件--控制文件恢复

一、使用rman 的backup database 份了数据文件、控制文件和spfile文件,份位置在闪回区 [oracle@oracle11 ~]$ rman target / Recovery Manager: Release 11.2.0.4.0 - Production on Sun Mar 21 23:01:15 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. con.

freelove_2005的专栏 1657

数据库删掉数据文件后无法开机

数据库删掉了一个数据文件,RMAN没有RMAN> list backup of datafile 5; using target database control file instead of recovery catalog specification does not match any backup in the repository 解决启动方案: SQL> alter d

在路上 1207

3.rman 几个常用恢复命令实验记录

本文主要记录RMAN 以下几个常用命令的作用和恢复程度、及其适用场景。同时顺便测试哪些场景下必须使用resetlogs打开2、操作前知识科普3、实验过程测试场景:控制文件丢失 数据文件、归档文件、online redo log 无丢失测试结论:1)使用recover database 恢复会自动使用归档日志和online redo log 进行一致性恢复。

weixin_42005129的博客 1632

rman参数配置错误导致控制文件无法

告警日志提示的错误信息: Linux-x86_64 Error: 21: Is a directory Fri Dec 11 08:54:36 2015 Errors in file /...

cucany584825的博客 735

Oracle技术之设置EXCLUDE后STANDBY数据库只读表空间的恢复

在STANDBY数据库利用RMAN恢复主上EXCLUDE的只读表空间,碰到了问题数据库恢复完成,但是恢复被主EXCLUDE的只读表空间时,发现无法进行恢复:RMAN> restore tablespace clubstat2_bak;Starting restore at 14-FEB-11allocated channel: ORA_DISK_1channel ...

weixin_34367257的博客 211

oracle恢复区大小多大,闪回恢复区大小不够报ORA-19809、ORA-19804错误

RMAN> backup database;Starting backup at 01-July-19using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=39 device type=DISKchannel ORA_...

weixin_42656416的博客 590
上一篇: 为Linux版本Oracle 11gR2配置HugePage
下一篇: Postgresql Linux版本安装——RPM包安装
ciqu9915
博客等级 码龄10年 11粉丝 0原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值