【DATAGUARD】物理dg的failover切换(六)
【DATAGUARD】物理dg的failover切换(六)
创新互联2013年至今，是专业互联网技术服务公司，拥有项目成都网站建设、做网站网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元雨山做网站,已为上家服务,为雨山各地企业和个人服务,联系电话:18982081108
1.1 BLOG文档结构图
1.2 前言部分
1.2.1 导读
各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：
①物理dg的failover切换演练过程
②物理dg管理和维护的一些sql
③ 利用duplicate搭建物理dg
④
注意：本篇BLOG中代码部分需要特别关注的地方我都用黄色背景和红色字体来表示，比如下边的例子中，thread 1的最大归档日志号为33，thread 2的最大归档日志号为43是需要特别关注的地方。
List of Archived Logs in backup set 11
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 32 1621589 2015-05-29 11:09:52 1625242 2015-05-29 11:15:48
1 33 1625242 2015-05-29 11:15:48 1625293 2015-05-29 11:15:58
2 42 1613951 2015-05-29 10:41:18 1625245 2015-05-29 11:15:49
2 43 1625245 2015-05-29 11:15:49 1625253 2015-05-29 11:15:53
本文如有错误或不完善的地方请大家多多指正，ITPUB留言或QQ皆可，您的批评指正是我写作的最大动力。
1.2.2 实验环境介绍
|
项目 |
主库 |
dg库 |
|
db类型 |
单实例 |
单实例 |
|
db version |
11.2.0.3 |
11.2.0.3 |
|
db存储 |
FS type |
FS type |
|
ORACLE_SID |
oradg11g |
oradgphy |
|
db_name |
oradg11g |
oradg11g |
|
主机IP地址： |
192.168.59.130 |
192.168.59.130 |
|
OS版本及kernel版本 |
RHEL6.5 64位，2.6.32-504.16.2.el6.x86_64 |
RHEL6.5 64位，2.6.32-504.16.2.el6.x86_64 |
|
OS hostname |
rhel6_lhr |
rhel6_lhr |
1.2.3 相关参考文章链接
【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库（一）：http://blog.itpub.net/26736162/viewspace-1448197/
【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库（二 ): http://blog.itpub.net/26736162/viewspace-1448207/
【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库（三 ): http://blog.itpub.net/26736162/viewspace-1481972/
【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库 (四)--添加一个物理dg节点 ：http://blog.itpub.net/26736162/viewspace-1484878/
【DATAGUARD】物理dg的switchover切换（五）：http://blog.itpub.net/26736162/viewspace-1753111/
1.2.4 本文简介
接上一篇文章【DATAGUARD】物理dg的switchover切换（五）：http://blog.itpub.net/26736162/viewspace-1753111/，本章中介绍failover的切换。
1.3 相关知识点扫盲
1．角色
Oracle 数据库中含有两种角色。
用户角色：定义了一组权限的集合，该角色可以分配给用户，也可以分配给其他角色。
数据库角色：在备库中数据库扮演什么样的角色，primary还是standby。
v$database.DATABASE_ROLE标识了数据库的运行角色。
处于备库环境中，数据库有两种类型：phsical standby、logical standby。
2．角色管理服务
一个数据库运行在如下互相排斥的角色中。
Primary role：一个数据库运行在primary role，那么log transport services传递重做日志到备库。
Standby role：一个数据库运行在standby role，那么log apply services应用归档日志到备库。
角色管理服务允许用户动态地在主、备库中进行角色切换。
用户可以使用角色管理服务，进行主、备库的计划中的角色切换，这个叫switchover，或者是非计划中的角色切换，叫failover。
3．Switchover&Failover
切换是在主数据库与其备数据库之间进行角色反转，切换确保不丢失数据。这是对于主系统计划维护的典型操作。在切换期间，主数据库转换到备角色，备数据库转换到主角色。转换发生不需要重建任何数据库。
（1）Switchover
用到的场景：计划中的角色转换或用户操作系统和硬件的维护等。
（2）Failover
故障转移是当主数据库不可用时执行的。故障转移只有在主数据库灾难故障的情况下执行，并且故障转移导致备数据库转换到主角色。用到的场景：非计划中的角色切换，一般在紧急情况下使用。根据保护模式的不同，可能会没有或者很少的数据损失。
（3）角色转换决策树
角色转换（switchover&failover）的最终目的是尽快地使主库在线，而同时尽量减少数据损失或者是实现无数据损失。尽量选择宕机时间最短，同时数据损失最小的策略。总之在失败切换前，应该先考虑修复主数据库或者进行无数据损失的角色转换。
即使使用无数据损失的备库方案，修复主库可能会比切换到备库更快点。如果修复了主库，那么就不需要修改客户端的连接。但是如果修复工作导致了任何的数据损失，那么可能需要重新创建所有的备用数据库。
通常情况下，最合适切换的备库为已经应用了最多的归档日志的备用数据库。
1.4 实验部分
1.4.1 实验目标
① 主库和物理dg的failover切换
② 还原为最初始的状态
1.4.2 实验过程
注：failover切换后原来的主库将不可用，必须重新搭建，所以该实验请慎重选择。
1.4.2.1 在主库端模拟数据库意外宕机
[oracle@rhel6_lhr oradg11g]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on 星期日 7月 26 21:26:20 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
21:26:20 SQL>
21:26:29 SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database;
NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORADG11G ARCHIVELOG READ WRITE PRIMARY TO STANDBY oradg11g
已用时间: 00: 00: 00.01
21:26:37 SQL> alter system switch logfile;
系统已更改。
已用时间: 00: 00: 00.01
21:27:31 SQL> create table test as select * from dba_objects;
表已创建。
已用时间: 00: 00: 00.50
21:27:38 SQL> insert into test select * from test;
已创建 75250 行。
已用时间: 00: 00: 00.51
21:27:56 SQL> insert into test select * from test;
已创建 150500 行。
已用时间: 00: 00: 02.62
21:28:00 SQL> commit;
提交完成。
已用时间: 00: 00: 00.00
21:28:06 SQL> insert into test select * from test;
已创建 301000 行。
已用时间: 00: 00: 12.41
21:28:21 SQL> commit;
提交完成。
已用时间: 00: 00: 00.00
21:28:27 SQL> insert into test select * from test;
已创建 602000 行。
已用时间: 00: 00: 22.63
21:29:08 SQL> commit;
提交完成。
已用时间: 00: 00: 01.29
21:29:12 SQL>shutdown abort;
ORACLE 例程已经关闭。
21:29:14 SQL>
备库查询：
20:45:30 SQL> select count(1) from test;
COUNT(1)
----------
1204000
已用时间: 00: 00: 00.05
21:29:42 SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;
未选定行
已用时间: 00: 00: 00.02
21:31:23 SQL>
如果没有发现明显的gap现象，说明此次的failover不会有数据损失情况。在standby端，要进行关闭apply和结束应用动作。
1.4.2.2 备库直接切换
21:31:23 SQL> alter database recover managed standby database cancel;
数据库已更改。
已用时间: 00: 00: 01.01
21:33:46 SQL>alter database recover managed standby database finish;
数据库已更改。
已用时间: 00: 00: 00.31
21:33:52 SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database;
NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORADG11G ARCHIVELOG READ ONLY PHYSICAL STANDBY TO PRIMARY oradgphy
已用时间: 00: 00: 00.01
21:34:16 SQL>alter database commit to switchover to primary with session shutdown;
数据库已更改。
已用时间: 00: 00: 00.07
21:36:16 SQL>
21:36:16 SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database;
NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORADG11G ARCHIVELOG MOUNTED PRIMARY NOT ALLOWED oradgphy
已用时间: 00: 00: 00.01
21:38:18 SQL>alter database open;
数据库已更改。
已用时间: 00: 00: 00.30
21:38:42 SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database;
NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORADG11G ARCHIVELOG READ WRITE PRIMARY RESOLVABLE GAP oradgphy
已用时间: 00: 00: 00.00
21:38:49 SQL>
切换成功。切换之后，我们观察这个过程的日志情况。
alert日志：
alter database recover managed standby database cancel
Sun Jul 26 21:33:45 2015
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/oradgphy/oradgphy/trace/oradgphy_pr00_45791.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 1874535
Sun Jul 26 21:33:46 2015
MRP0: Background Media Recovery process shutdown (oradgphy)
Managed Standby Recovery Canceled (oradgphy)
Completed: alter database recover managed standby database cancel
alter database recover managed standby database finish
Attempt to do a Terminal Recovery (oradgphy)
Media Recovery Start: Managed Standby Recovery (oradgphy)
started logmerger process
Sun Jul 26 21:33:52 2015
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '07/26/2015 21:33:52'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 183 redo required
Terminal Recovery:
Recovery of Online Redo Log: Thread 1 Group 4 Seq 183 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/oradgphy/standby_redo04.log
Identified End-Of-Redo (failover) for thread 1 sequence 183 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 1874536 time 07/26/2015 21:29:12
Media Recovery Complete (oradgphy)
Terminal Recovery: successful completion
Sun Jul 26 21:33:52 2015
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance oradgphy - Archival Error
ORA-16014: log 4 sequence# 183 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/oradgphy/standby_redo04.log'
Forcing ARSCN to IRSCN for TR 0:1874536
Attempt to set limbo arscn 0:1874536 irscn 0:1874536
Resetting standby activation ID 1413582769 (0x54418fb1)
Completed: alter database recover managed standby database finish
Sun Jul 26 21:36:16 2015
alter database commit to switchover to primary with session shutdown
ALTER DATABASE SWITCHOVER TO PRIMARY (oradgphy)
Maximum wait for role transition is 15 minutes.
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Sun Jul 26 21:36:16 2015
SMON: disabling cache recovery
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/oradgphy/oradgphy/trace/oradgphy_ora_45673.trc
Standby terminal recovery start SCN: 1874535
RESETLOGS after incomplete recovery UNTIL CHANGE 1874536
Online log /u01/app/oracle/oradata/oradgphy/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/oradgphy/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/oradgphy/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 1874534
Sun Jul 26 21:36:16 2015
Setting recovery target incarnation to 3
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
Switchover: Complete - Database mounted as primary
Completed: alter database commit to switchover to primary with session shutdown
Sun Jul 26 21:36:45 2015
idle dispatcher 'D000' terminated, pid = (17, 1)
Sun Jul 26 21:36:54 2015
ARC0: Becoming the 'no SRL' ARCH
Sun Jul 26 21:36:55 2015
ARC1: Becoming the 'no SRL' ARCH