Data Guard高级玩法:通过闪回恢复failover备库

    今天看到有一个网友提了一个问题,描述很简短
    测试DG时,主库不能宕机,如何测试failover?
    其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。
而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以进行读写操作的,如果把它再切回备库,数据一致性怎么保证,怎么能保证是从上次的断电开始恢复。如果可以做,那真是一大福利。
    我们来看看Oracle提供的方式方法,两大法宝,switchover和Failover
    Switchover切换的核心脚本如下,
    在备库执行,取消日志应用
    recover managed standby database cancel;
    在主库执行,切换角色
    Alter database commit to switchover to physical standby with session shutdown;
    而Failover的核心脚本则为:
    在备库执行
    alter database recover managed standby database finish force;
    alter database commit to switchover to primary;
如此来看,要实现上面的部分还是有一些难度。
今天反反复复测试了不下十多次,重建了很多次环境,总算在晚饭过后把这个问题顺利调试好了,虽然思路上是可行的,但是有一个地方总是卡在了下面的错误上。
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/U01/app/oracle/oradata/newtest2/system01.dbf'
明白了原委,解决起来全然不费功夫。
我们先讲讲思路,还是闪回,但是闪回的玩法有一些差别,和reinstate的方式有一些区别。假设是一主一备的环境,备库开启了闪回数据库功能。

我们不动原来的主库,把备库Failover为主库。

然后这个时候Failover的主库可读可写,当然最后还是要切换回备库接收归档,可以使用闪回,同时还需要切换角色,这个地方需要好好琢磨一番改怎么处理。

假设我们的数据库主库为newtest2,备库为snewtest2
在备库snewtest2上开启闪回,在备库上MRP可以实时接受数据变化。
SQL> alter database open;
Database altered.

SQL> SQL> alter database flashback on;
Database altered.

得到一个参考的SCN
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
    1765837
查看闪回数据库特性是打开的。
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
YES

然后我们在备库上开始failover
DGMGRL> DGMGRL> failover to snewtest2;
Performing failover NOW, please wait...
Failover succeeded, new primary is "snewtest2"
DGMGRL>
操作很快完成,我们查看备库此时的状态和角色
SQL> select open_mode,database_role    from v$database;
OPEN_MODE                                DATABASE_ROLE
---------------------------------------- --------------------------------
READ WRITE                               PRIMARY
当然这个步骤可以做一些读写操作之类的。
然后我们开始计划切回备库。
SQL> shutdown immediate

SQL> startup mount

然后开启闪回数据库,恢复到指定的SCN,这个时候要注意,此时还是主库。
SQL> flashback database to scn 1765837;           
Flashback complete.
我们需要切换为备库,这个时候切换的命令就是关键,不是使用switchover的方式。
SQL> alter database convert to physical standby;
Database altered.
当然这个时候数据库在nomount阶段,我们需要重启备库。
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted

SQL> shutdown immediate
SQL> startup mount

重新配置一下DG Broker即可,可以设置dg_broker_start=false,停掉dmon,然后删掉$ORACLE_HOME/dbs下的dr*newtest2.dat的配置文件,重新配置DG Broker即可。
配置起来都是老套路。
简单配置后,DG Broker的检查就正常了。
DGMGRL> DGMGRL> show configuration;
Configuration - dg_newtest2
  Protection Mode: MaxPerformance
  Databases:
    newtest2  - Primary database
    snewtest2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL>
对应的数据库日志中可以看到后台已经开始应用日志了。
RFS[2]: Assigned to RFS process 44981
RFS[2]: Selected log 5 for thread 1 sequence 48 dbid 795252212 branch 921251959
Tue Aug 30 21:32:01 2016
Archived Log entry 5 added for thread 1 sequence 48 ID 0x2f7352f8 dest 1:
Tue Aug 30 21:32:01 2016
Media Recovery Log /U01/app/oracle/fast_recovery_area/SNEWTEST2/archivelog/2016_08_30/o1_mf_1_48_cwc2pk57_.arc
Media Recovery Waiting for thread 1 sequence 49 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 49 Reading mem 0
  Mem# 0: /U01/app/oracle/fast_recovery_area/SNEWTEST2/onlinelog/o1_mf_4_cwc0lmr7_.log
    当实现这个看起来有些特殊的需求的时候,我真心内心充满了喜悦,也着实惊叹Oracle的闪回给备库带来了如此多的改进。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

简单分析percona-zabbix-templates - 2016-09-01 04:09:15

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。     我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------

Oracle之不可见索引 - 2016-08-27 17:08:09

Oracle 之不可见索引 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  Oracle 不可见索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新
【故障处理】序列 cache 值过小导致 CPU 利用率过高 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① enq: SQ - contention 等待事件的解决 ② 一般等待事件的解决办法 ③  DFS lock handle 等待事件 ④ 与序列有关的等待事件   Tips: ① 本文在 ITpub ( http://blog.itpub.
这两天做性能测试碰见一个问题,比较有意思。 一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2,  查看V$SQL,发现有两条记录,分别对应了0和1两个child cursor:  再查看这两个child cursor对应的执行计划:  child cursor:0 -----------------------------------------------------------------------------------------------------| I

OCP如何查看历史成绩(2) - 2016-08-25 14:08:08

OCP如何查看历史成绩( 2 ) 之前写过一篇文章 OCP如何查看历史成绩: http://blog.itpub.net/26736162/viewspace-1624996/  , 但是现在界面好像有所变动,而且有的连接也找不见了,今天有朋友问如何查询历史的成绩,晚上小麦苗就抽了点时间来找找,顺便记录下来。最近心情不好,不想写技术文章了。       首先登陆网址: https://education.oracle.com/ https://education.oracle.com/pls/eval-e
下午的时候收到这么一条报警。 ZABBIX- 监控系统 : ------------------------------------ 报警内容 : Too many parallel sessions on xxxxx_ xx机房 _xxxxx ------------------------------------ 报警级别 : PROBLEM ------------------------------------ 监控项目 : parallel_session_cnt : 66 -----------

【MySQL】Tokudb安装测试初探 - 2016-08-24 14:08:02

一 前言    TokuDB 是一个高性能、支持MVCC的MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是数据压缩功能出色,对高写压力的支持,由美国TokuTek公司(http://www.tokutek.com/) 研发,该公司于2015年4月份被Percona收购,理所当然地提供了TokuDB版本的Percona Server。本文使用Peronca server 5.6.30 版本进行测试安装。 二 安装前的准备     请参考官方文档 Percona Server YUM源