DataGuard:Switch Protection Mode

DataGuard:Switch Protection Mode

 

演示从maximize performance 转换到maximize protection 模式

 

 

1. 增加standby standby logfile,并检查primary log_archive_dest_x 设置

   standby 库增加standby logfile

        alter database recover managed standby database cancel;

         alter database add standby logfile group 4 ('C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\STANDBY_REDO04.LOG') SIZE 50M

         alter database add standby logfile group 5 ('C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\STANDBY_REDO05.LOG') SIZE 50M

         alter database add standby logfile group 6 ('C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\STANDBY_REDO06.LOG') SIZE 50M

         alter database add standby logfile group 7 ('C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\STANDBY_REDO07.LOG') SIZE 50M

         alter database recover managed standby database  disconnect from session;

 

2.primary 库操作

 

          shutdown immediate;

          startup mount;

          alter database set standby to maximize protection;

          alter database open;

 

 

3.验证及测试

 

primary 库执行

   SQL> select protection_mode,protection_level from v$database;

 

PROTECTION_MODE      PROTECTION_LEVEL

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

MAXIMUM PROTECTION   MAXIMUM PROTECTION

 

确认主库为MAXIMUM PROTECTION 模式

继续测试

SQL>  alter table test.a modify col1 varchar2(4000);

Table altered.

SQL>  insert into test.a values('Switch Protection Mode');

1 row created.

SQL> COMMIT;

注意,此时standby 并没有实时反映出来,因为我们没有启用实时应用,他要等到primarylogfile switch ,触发archived log传输到standbystandbyrfs进程把传过来的归档文件取下来,standby机器上的arch再把文件归档到standby log的归档目的地,最后,mrp进程再基于该archived log文件的基础上做revover。如下

SQL>  alter database recover managed standby database cancel;

 

Database altered.

 

SQL> alter database open read only;

 

Database altered.

 

SQL>  select * from test.a;

 

COL1

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

My Data Guard!!!

看到primary insert的纪录并没有过来

primary中触发一次logfile switch

SQL> alter system switch logfile;

standby 库执行

SQL>  alter database recover managed standby database cancel;

Database altered.

SQL>  alter database open read only;

Database altered.

SQL>  select * from test.a;

COL1

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

My Data Guard!!!

Switch Protection Mode

 

可以看到应用在standby上体现出来了

 

(如果standby realtime apply redo方式,则primary commit后立刻可以在standby中应用,不需要做logfile switch,语句为

  alter database recover managed standby database using current logfile disconnect from session;)

 

:

Switch protection mode 过程中可能遇到的故障

standby 发生故障后的ORA-01154错误:

maximize protection 保护模式下,直接shutdown immediate会抱错, ORA-01154: database busy. Open, close, mount, and dismount not allowed now,报这个错误很正常,因为我们处在maximize protection模式,并且只有一个standby 数据库环境下,这个standby挂了,就无法实现maximize protection 保护了。

模拟ORA-01154错误

standby shutdown abort操作

SQL> shutdown abort

模拟故障,

接着看看primary

SQL> select protection_mode,protection_level from v$database;

 

PROTECTION_MODE      PROTECTION_LEVEL

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

MAXIMUM PROTECTION   RESYNCHRONIZATION

 

处于需要 RESYNCHRONIZATION的状态,并且后台的alert 日志也会出现如下错误

LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)

LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'db2'

LNSb started with pid=21, OS id=3284

Error 12154 received logging on to the standby

Wed Jan 07 16:53:39 2009

LGWR: Error 12154 attaching to RFS for reconnect

LNSb started with pid=21, OS id=4788

Error 12154 received logging on to the standby

 

经过数分钟后,primary库因无法继续运行在maximize protection而自动关闭.

 

可能出现的错误ORA-16072ORA-03113

 

ORA-16072: a minimum of one standby database destination is required

error 16072 detected in background process

ORA-16072: a minimum of one standby database destination is required

 

shutdown immediate后重新startup,错误如下

 

 Database mounted.

ORA-03113: end-of-file on communication channel

 

此时察看后台alert 日志及跟踪文件,发现错误

 

Destination LOG_ARCHIVE_DEST_2 is using asynchronous network I/O

Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR

Standby database verification failed:16072

ORA-16072: a minimum of one standby database destination is required

error 16072 detected in background process

ORA-16072: a minimum of one standby database destination is required

 

处理方法:

 startuo mount;

 alter sysetem set log_archive_dest_2='service=db2 lgwr sync affirm valid_for=(online_logfiles,primary_role) db_unique_name=db2'

 alter database open;

  SQL> select protection_mode,protection_level from v$database;

 

PROTECTION_MODE      PROTECTION_LEVEL

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

MAXIMUM PROTECTION   MAXIMUM PROTECTION

修改log_archive_dest_2参数为lgwr sync affirm,其原因是因为处于maximize protectionmaximize avaliabition 保护模式的时候,redo的传送是通过lgwr进程,并以synchronous方式写入standby,且需要确认(affirm ) 至少有一台standby数据库接收到redo数据,而默认情况的maximize performance 采用arch,synchronous方式传送redo,且不需要收到确认(affirm ) 信息即可完成primary的事务。

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

转载于:http://blog.itpub.net/10159839/viewspace-598219/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值