当前位置:操作系统 > Unix/Linux >>

一次data gurad故障模拟实验

一次data gurad故障模拟实验
 
最近新建里一套MAA,现模拟测试primary 的RAC故障,将2节点的RAC的public 网线拔掉,阻断与外网的连接,应用程序软件连接不到数据库.
 
Standby DB上做操作:
SQL > alter database  recover  managed  standby database cancel;
Database  altered.
SQL > alter database  recover  managed  standby  database finish;
Database  altered.
SQL > alter  database  commit  to switchover to primary  with  session  shutdown;
Database  altered.
SQL > ALTER  DATABASE OPEN;
Database  altered.
SQL> SELECT SWITCHOVER_STATUS,OPEN_MODE,DATABASE_ROLE,PROTECTION_MODE FROM V$DATABASE;
SWITCHOVER_STATUS    OPEN_MODE    DATABASE_ROLE    PROTECTION_MODE
-------------------- -------------------- ---------------- --------------------
RESOLVABLE GAP      READ WRITE    PRIMARY    MAXIMUM PERFORMANCE
可以看到standby 上的状态为自动处理间隔中。
 
通过对RECOVER  MANAGED  STANDBY  DATABASE  命令使用额外限定符FINISH,指示备用数据库使用所有可用的重做数据,可以完成这些操作。
 
一旦FINISH完成,无论原来的保护模式是什么,主库的保护模式均降为“最高性能”模式,这样做是使得新的主数据在没有备用数据库时可以打开。
 
此时,可以看到原来的standby变成了PRIMARY角色,为读写状态,启动应用程序软件数据开始入库。
 
 
 
Primay DB上操作:
此时,需要登录到主数据库上,关闭RAC的DB,防止有其他的应用软件登录到RAC上工作,然后连接刚才被拔掉的public网线(当然如果存在其他故障能恢复的恢复,不能的就只能重做了)。
 
由于RAC做Standby的时候只能有一个节点启动,故先启动节点一,对数据进行恢复。
 
 
在单点asm(standby)上查找故障点:
 
SQL  > select to_char(standby_became_primary_scn) failover_scn  from v$database;base;
 
 
FAILOVER_SCN
----------------------------------------
12159305102
 
 
 
SQL> col current_scn for 99999999999999;
 
SQL> select current_scn from v$database;
 
 
 
CURRENT_SCN
 
---------------
 
12159461145
 
 
 
原Primary
 
SQL> col current_scn for 99999999999999;
 
SQL> select current_scn from v$database;
 
CURRENT_SCN
 
---------------
 
12159330716
 
 
 
可以看到12159330716小于目前primay 的SCN却但与故障点的SCN,所以需要还原主库到故障点之前。由于我没有启用闪回功能,所以只能利用RMAN进行处理。
 
 
 
[oracle@node1 ~]$ rman target /
 
恢复管理器: Release 11.2.0.3.0 - Production on 星期三 10月 23 17:17:19 2013
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
已连接到目标数据库 (未启动)
 
RMAN> startup mount
 
RMAN> restore database  until  scn 12159305102;
 
RMAN> recover database  until  scn 12159305102;
 
 
SQL> alter database recover managed standby database using current logfile disconnect;
 
数据库已更改。
 
查看altert日志,虽然MRP恢复工作,但却报
 
ORA-19906: 在恢复过程中更改了恢复目标原型
 SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-10458: standby database requires recovery
ORA-01152: 文件 1 没有从过旧的备份中还原
ORA-01110: 数据文件 1: '+DATA/bdspoc/datafile/system.256.790856085'
 
 
 
 经过排除分析比较,得出应该是恢复出错。
 
从新restore数据库,重建控制文件。删除failover以后的所有归档日志,这点很重要,当恢复的时候从单点ASM-standby上取得所需standby log。
 
 
RMAN>starup nomount;
 
RMAN> list backup of controlfile;
RMAN> restore controlfile from '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/c-2907827626-20131021-01' from autobackup;
RMAN> alter database mount;
 run{
allocate channel t1 device type disk;
allocate channel t2 device type disk;
allocate channel t3 device type disk;
allocate channel t4 device type disk;
restore database;
 }
 
 
SQL> select status from v$instance;
 
STATUS
------------
MOUNTED
 
SQL> alter database recover managed standby database using current logfile disconnect from session;
 
Database altered.
 
 
 
恢复一定的数据然后再OPEN。
 
SQL>alter database  recover  managed  standby database cancel;
Database altered.
 
SQL> alter database open;
 
Database altered.
 
SQL> alter database recover managed standby database using current logfile disconnect from session;
 
Database altered.
 
查看alert日志,发现已经正常运转
 
 
 
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
查看standby上没有重做间隔,不放心可以做些DML,DDL操作进行测试。
CopyRight © 2022 站长资源库 编程知识问答 zzzyk.com All Rights Reserved
部分文章来自网络,