1、物理standby failover 切换
故障转移时在一些糟糕的事情发生时执行的计划外事件,需要将生产库移动到DR站点。有意思的是,这时候人们通常忙来忙去,试图弄明白发生了什么,需要做些什么才能使数据库恢复过来。客户打来电话询问系统核实才能恢复,高级管理人员在走廊徘徊,追究是谁范了错误。对于DBA来说,没有什么事情比时空的备用站点更可怕,并且在需要备用站点前,我们也不知道它是否奏效。如果故障转移失败,DBA们将会失去奖金,甚至职业生涯因此中断。
所以我们在系统建立初期,就要有周密的后援计划。一旦出现问题,做到手不忙,心不慌。大显身手的时候到了。但此前需要有一番详尽实验做支撑,亲自动手很重要!
Step 1冲刷任何没有从主数据库发送到备用数据库的的重做
如果主数据库不能被Mounted,那可能就要将没有发送的归档和当前的日志从主库发送到备用数据库。如果这个操作时成功的,零数据丢失将是可能的,即使它没有在最大保护模式中。
确信redo
apply是活动的在目标备用数据库上。
Mount,不要要打开主数据库。如果主数据库不能被mounted,跳至step
2.
执行如下SQL语句在primary
database:
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
Target_db_name为目标备份库的DB_UNIQUE_NAME,它将会受到冲刷过来的重做。该语句只在11G
R2中被支持。
如果该语句完成却没有错误,跳至step
5.如果执行过程出错,或者它没有有停下,因为你不能等待很长时间直到这个语句执行完,继续 step 2.
Step 2核实备份库中最近从主数据库发送过来的归档日志文件。
查询V$ARCHIVED_log视图在目标备份库中,获取每个线程实例归档过来的最大序列号。
例如:
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) over(partition by thread#) as last from v$archived_log;
THREADLAST
---------- ----------
1
517
2
412
如果可能,拷贝每个主数据库归档重做日志到备份库,如果那些日志不在备份库上。并且注册它。它必须被做在每个重做线程上。
例如:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '<from your list>';
Step 3认定和处理任何的归档重做日志间隔(archived
redo log gaps)
查询V$archive_gap视图在目标备份库上,决定这是否有任何的重做间隔。
For example:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD#LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
190
92
可以看到存在重做间隔,需要线程1归档来的90、91、92号日志,如果可能,拷贝这些缺失的归档重做文件到目标重做数据库上。然后在每个线程节点上注册他们。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Step 4重复步骤3直到重做间隔被解决
步骤3中仅仅是最高的间隔。在解决间隔后,你必须重复这个查询直到间隔没有。
如果间隔没有被解决,一些数据的丢失将会丢失在故障转移期间。
Step 5停止Redo Apply
执行如下SQL语句在目标备份库上:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Step 6完成所有重做数据的应用
执行如下SQL语句在目标备份库上:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果该语句执行没有错误,行进到Step
7.
如果错误发生,一些接受到的重做数据没有被应用。尝试解决这些错误的原因并且重新确定这些错误状态在行进至下一步之前。
如果错误状况不能解决,故障切换也能进行(伴随一些数据丢失),执行下列SQL语句在standby
databse:
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
此时是进行强制的切换,跳至步骤9,当这个激活状态被完成了。
Step 7确定目标备份库已经准备变成了一个主数据
执行如下语句确认数据库状态:
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TOPRIMARY
1 row selected
如果这个值是TOPRIMARY或者SESSIONS
ACTIVE表明主数据库是可以切换成Standby role的。如果是其他的值将不可以执行切换,
Step 8切换物理备份库到主数据库角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
Step 9打开新的主数据库
SQL> ALTER DATABASE OPEN;
Step 10备份新的主数据库
Oracle推荐对新的主数据库做一个全库备份。
Step 11在物理standby
database上重启Redo Apply
For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;
Step 12在可选择的情况下,重建失败的主数据库。
在故障切换后,源主数据库可能转换成一个物理standby数据库或者从新的主数据库的备份重建。
一旦源主数据库以Standby
Role在运行,一次切换又可以把它重建回Primary role。
2、FAILOVER切换实录
SQL> alter system flush redo to 'HAINAN';
alter system flush redo to 'HAINAN'
*
ERROR at line 1:
ORA-16442: ALTER SYSTEM FLUSH REDO TO STANDBY succeeded, but some redo has not
been applied.
以上的步骤要花费N久的时间等待。
查看主备库上的alert日志:
主库上有大量的如下日志:
Fri Jul 12 11:23:22 2013
ARC4: Archiving disabled
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
备库上有如下的大量日志:
Fri Jul 12 11:23:30 2013
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.
由此可见,应该是主库对备库的每个归档进行校验,要花费大量时间的。所以在系统建立初期,就要考虑的两条重要信息是公司需要实现的恢复点目标(recovery
point objective,RPO)和恢复时间目标(recovery time objective,RTO)。
虽然看到了succeeded字样,但还是按照有错误处理,官网搜索了ORA-16442下,竟然没有结果,新特新还是有缺点的,往下走。
SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) over(partition by thread#) as last from v$archived_log;
THREADLAST
---------- ----------
2
415
1
519
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
no rows selected
主库上查询,得到同样的结果,说明日志均被应用,由于我应用了standby log,并且开启了real
time 应用,实际中丢失数据的概率大大被降低了,这也是oracle推荐的用法。
SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) over(partition by thread#) as last from v$archived_log;
THREADLAST
---------- ----------
2
415
1
519
备库上继续执行如下操作:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
no rows selected
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
NOT ALLOWED
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
*
ERROR at line 1:
ORA-01109: database not open
SQL> select status from V$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
*
ERROR at line 1:
ORA-16109: failed to apply log data from previous primary
SQL> select status from V$instance;
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
FAILED DESTINATION
SELECT SWITCHOVER_STATUS,OPEN_MODE,DATABASE_ROLE,PROTECTION_MODE FROM V$DATABASE;BASE;
SWITCHOVER_STATUSOPEN_MODE
DATABASE_ROLE PROTECTION_MODE
-------------------- -------------------- ---------------- --------------------
FAILED DESTINATIONREAD WRITE
PRIMARY MAXIMUM PERFORMANCE
查看最初的是NOT ALLOWED,切换后变成了FAILED
DESTINATION,但数据库可以write并且是primary的了。
重启数据库:
SQL> startup force
ORACLE instance started.
Total System Global Area943669248 bytes
Fixed Size2234000 bytes
Variable Size264243568 bytes
Database Buffers671088640 bytes
Redo Buffers6103040 bytes
Database mounted.
Database opened.
SQL> select status from v$instance;
STATUS
------------
OPEN
查看alert日志:
Fri Jul 12 14:05:14 2013
PING[ARC5]: Heartbeat failed to connect to standby 'beijing'. Error is 16009.
PING[ARC5]: Heartbeat failed to connect to standby 'beijing'. Error is 16009.
PING[ARC5]: Heartbeat failed to connect to standby 'beijing'. Error is 16009.
Fri Jul 12 14:06:14 2013
PING[ARC5]: Heartbeat failed to connect to standby 'beijing'. Error is 16009.
PING[ARC5]: Heartbeat failed to connect to standby 'beijing'. Error is 16009.
出现大量的ORA-16009错误,它不断的去尝试连接beijing这个standby
database,由于我做的是failover,此时standby是关闭的。
SQL> show parameter log_archive_dest_2
NAMETYPE
VALUE
----------------------------------------------- ------------------------------
log_archive_dest_2string
SERVICE=beijing ASYNC VALID_FO
R=(ONLINE_LOGFILES,PRIMARY_ROL
E)
DB_UNIQUE_NAME=beijing
SQL> alter system set log_archive_dest_2='' scope=spfile;
System altered.
SQL> startup force
SQL> show parameter log_archive_dest_2
NAMETYPE
VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2string
取消远程归档路径,错误消除。
分享到:
相关推荐
自己在centos linux 上做的 oracle physical standby配置 ,已测试通过
Oracle DataGuard物理Standby Database配置的详细步骤
给公司的搭建的《Linux 平台 Physical Standby 搭建ADG》文档。
如何在Oracle 10g On Windows下创建standby database.doc
Oracle standby database的建立与维护.pdf
Oracle8i Standby Database Concepts and Administration Release 2 (8.1.6)
Oracle Standby Database技术的原理及实现.pdf
Oracle数据库中Standby Database的搭建和使用.pdf
关于oracle中如何创建standby database的学习资料!
SQL> alter database recover managed standby database using current logfile disconnect from session; SQL> select open_mode,switchover_status,database_role,name from v$database; MOUNTED NOT ALLOWED ...
Oracle_Standby_Database
1.主从两机的操作系统和相同pack 2.在主从库上建立数据库,选择只安装Software 3.在主库上,通过dbca建立数据库,除了字符集选择 zhs16gbk外,全部使用缺省方式 4.在从库上,手工创建和主库相同目录
为Linux中的Oracle 11g rac搭建单实例的物理备库的操作步骤
【DATAGUARD】 将11g物理备库转换为Snapshot Standby【DATAGUARD】 将11g物理备库转换为Snapshot Standby【DATAGUARD】 将11g物理备库转换为Snapshot Standby
Oracle DataGuard standby database training ppt
在master节点下 # 切换用户 su - gpadmin # 停止master pg_ctl stop -s -m fast -D $MASTER_DATA_DIRECTORY 或者 pg_ctl stop -s -m fast -D /data/master/gpseg-1 ...查看standby节点状态(master节点执行) gpstate -f
通过本文档可以完成ADG的管理工具配置,ADG配置过程可参照... bei - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
standby database 手工恢复 自动脚本
ORA-10458: standby database requires recovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1: ‘XXXXXXXXXXXXXXXXXX\XXXXX1.DBF’ 一个项目做了Oracle主从数据库同步,通过Dataguard...