基于scn备份解决dg归档丢失的方法论

作者介绍

黄堋

多年一线DBA经验,曾服务于电信、电网、医院等行业客户。擅长数据库优化、数据库升级迁移、数据库故障处理

当主备同步中断了,备库想快一点恢复,偏偏这个时候归档太多恢复不过来或者说需要的归档直接丢了,有些人可能会选择重新搭建备库。如果库小的话还是可以的,但是如果主库比较大可能耗费的时间会很久,而且容易出一些问题。单单是全库备份恢复这个时间就不会短,更何况中间还会涉及到很多东西。

那么我们今天就是来聊聊有没有什么更好的办法来处理这种情况。因为这种情况还是比较常见的,至少我遇到过好几次了。

正常情况我们在生产中配置DG会使用最大可用模式配合参数lgwr和async。这种配置在保证备库同步情况不影响主库的情况下最大限度的保证了主备的实时性。

这里我们回顾一下dg的三种同步模式;

1

最大保护模式

这种保护模式是为了确保主库故障时,不会发生数据丢失。要提供这种级别的保护,恢复所需的重做数据必须在事务提交之前,同时写到本地联机重做日志和至少一个备用数据库上的备重做日志。若如果主库无法写重做流到备库,主库将会关闭。

2

最大可用模式

提供了可能的最高级别的数据保护,而不用与主数据库的可用性相折中。

与最大保护模式的区分

与最大保护模式相同:在恢复所需的重做数据,必须在事务提交之前同时写到本地联机重做日志和至少一个备用数据库上的备重做日志。

与最大保护模式不相同:如果故障导致主数据库无法写重做流到异地备库重做日志时,主数据库不会关闭,在没有达到net_timeout之前主库会hang住,但是并不是shutdown。而后主数据库以最大性能模式运行直到故障消除,并且解决所有重做日志文件的中断。当所有中断解决之后,主数据库自动继续以最大可用性模式运行。

这种模式确保如果主数据库故障,但是只有当第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备用数据库时,不发生数据丢失。

3

最大性能模式

这种保护模式(默认)提供了可能的最高级别的数据保护,而不影响主数据库的性能。这是通过允许事务在恢复该事务所需重做日志在写到本地联机重做日志后,可以立即提交而实现的。

主数据库的重做数据流也写到至少一个备用数据库,但是那个重做流相对于创建重做数据的事务是异步导入的,就不用 LGWR SYNC了,而之前两种模式都要用LGWR SYNC。

当所用的网络连接有足够的带宽,这种模式提供了近似于最大可用性模式的数据保护级别,并且对数据库性能的影响最小。

最大保护和最大可用性模式需要备库重做日志文件配置在配置中至少一个备用数据库上

为了保证主库不受影响,至少到目前为止我接触的生产环境的dg都是最大性能模式。但是这种环境会出现一种情况。由于某种原因,当备库出了一些故障、网络不通或者其他情况,导致主备同步中断,主库的在线日志或者归档没办法正常传输到备库。这样主库产生一个又一个的归档,但是这些归档都没办法传到备库。当然我们在恢复了出现的问题之后会从断了的地方重新传到备库以完成同步。

不过这中间可能会有一些情况,比如:我们本地的归档空间有限,主备的同步一时半会恢复不了,如果一直留着归档,当归档空间满了就会影响主库正常运行。不得不删除一部分。也有可能主备恢复时间过长,产生了很多很多归档,将它们传到备库应用会消耗很多很多时间。

理解原理

当主备同步中断了,备库想快一点恢复,偏偏这个时候归档太多恢复不过来或者说需要的归档直接丢了。这个时候我们该怎么办?

其实我们这次的题目已经提出了解决方法,就是利用基于scn的备份去恢复我们的备库,从而绕开中间过多或者丢失的归档。

那么基于scn备份究竟是什么意思呢?

我们都知道我们传统的dg都是属于物理dg,下面是物理dg的简单解释:

物理备用数据库:以基于块对块的主数据库同样的磁盘数据库结构,物理备用数据库物理等同于主数据库。

特性:

  1. 数据库的每一个块的内容包括块的逻辑位置都和主库完全一致
  2. DG通过执行重做应用,维护物理备用数据库
  3. 物理STANDBY 打开flashbackdatabase后可以完全读写打开
  4. 物理备用数据库使用通过oracle恢复机制,从归档重做日志文件或直接从备系统上的备重做日志文件用用重做数据来恢复。
  5. 物理备用数据库可用于执行备份
  6. 物理备用数据库使用重做应用技术使用低级别的恢复机制应用更改,绕过了所有SQL基本代码层,因此应用海量重做数据最有效,性能大于逻辑备份。

大家看了物理备库的简单解释之后需要注意的是,其实主备保持一致是不是就是主备的每一个块内容都一样?数据库一般的块是8K,如果每个8K都一样,是不是就意味着两边数据库内容是一样的?

假如当前备库应用到了100号归档,这个时候主备的网络断了,主库一直生成归档生成到了150号,这期间一直没有传递归档到备库。当我们恢复了主备的网络,主库生成的101到150这50个归档都传送到了备库。

那么此时,备库应用完这50个归档是不是备库就和主库保持一致了,都是150号归档的时候块的内容?如果我们将101到150这一段时间块的改变找出来,在备库上面进行修改,这样是不是就等同于应用了这50个归档?

我们单独拿一个块来说,假如100号归档的时候数据库内这个块记录了一列的值为5,150号归档的时候数据库内这个块记录这一行的值为6。当我们将这个5改成6时,是否就意味着这个块完成了101-150号归档的所有改变?

反过来说,假如100号归档的时候数据库内这个块记录了一列的值为5,150号归档的时候数据库内这个块记录这一行的值还是为5那么我们就可以不修改他,他还是完成了101-150号归档的所有改变。

所以到这里我们应该明白了,找到这段时间块的改变,全部应用到备库,我们就不用去恢复那些过多的或者缺失的归档。

如何完成一次基于scn的恢复?

所以回到我们的方法,我们找到备库端数据文件中最低的scn,然后在主库去基于这个scn进行备份,这个时候rman回去扫描整个主库的块,如果块内的scn小于备库端数据文件中最低的scn,则证明这个块从备库应用到的时间点到现在是没有改变的,就忽略掉这个块。

如果块内的scn大于备库端数据文件中最低的scn证明在这个阶段这个快进行了修改,就记录下这个块的内容。等拿到备库端去恢复的时候就替换这个块的内容。

当然我们是有官方文档的支撑的,并不是我们凭空想象出来的处理方法,这里提供官方mos的id,供大家自行去查看:

Steps to perform for Rolling Forward aPhysical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)

我们需要注意的是这个方法适用的版本在10.2以后:

Oracle Database - Enterprise Edition - Version 10.2.0.1 to later

操作演示

1、查找备库数据文件最低的scn

select CHECKPOINT_CHANGE# fromv$datafile_header order by 1;

select CHECKPOINT_CHANGE# fromv$database order by 1;

2、执行增量备份

rman target /

run

{configure controlfile autobackup on;

sql 'alter system switch logfile';

BACKUP INCREMENTAL FROM SCN 15078013867424 DATABASE FORMAT '/IC_%d_%u/'tag 'FORSTANDBY';

}

3、恢复控制文件

restore standby controlfile ;

4、恢复数据库

recover database;

知识补充

其实这里有一个问题就是:

我们在进行基于scn增量备份的时候他需要去扫描全库,去判断这个块会不会需不需要进行备份,那么如果主库很大,那么做增量备份的也不会很快,当然会比全部备份快很多,他只需要扫描所有的块,需要记录的不一定会很多。那么有没有加速的办法呢?

如果想提前避免这种情况,我们需要开启块改变追踪,这样你的块在修改的时候会记录到块改变追踪文件里面。这个文件里面是用位图去记录你这个块是否改变等相关的信息。在我们进行增量备份的时候直接看这个文件即可,不用去扫描整个数据库。其实我们平时的增量备份也是这个原理。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-11-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

10g 一主多备的搭建技巧(r6笔记第13天)

在数据库环境中,一主一备是比较传统的使用方式,在灾难发生的时候,可以灵活的切换主备角色,依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤,一主...

2746
来自专栏北京马哥教育

Linux运维跳槽必备的40道面试精华题

过一次年,结婚、存款、父母养老,一系列向钱看的事都在碾压我们本来还挺简单的神经,但难过没有出路,唯有找到好的方法和事业方向,才能实现一步一个脚印的逆袭。

2083
来自专栏用户2442861的专栏

基于xmpp openfire smack开发之openfire介绍和部署[1]

http://blog.csdn.net/shimiso/article/details/8816558

472
来自专栏Netkiller

高级运维工程师面试题(更新中)

高级运维工程师 服务器硬件 RAID 磁盘阵列 简述 RAID? RAID 0 5 6 10 50 都适用于那些场景? 数据库适用那种 RAID? RAID 1...

4914
来自专栏散尽浮华

Linux下防御DDOS攻击的操作梳理

DDOS的全称是Distributed Denial of Service,即"分布式拒绝服务攻击",是指击者利用大量“肉鸡”对攻击目标发动大量的正常或非正常请...

4827
来自专栏大魏分享(微信公众号:david-share)

Openshift的高可用架构设计

第一部分:高可用设计 一、Openshift架构 ? Openshift架构如上图,其核心组件有: ●Multiple Masters ●External e...

5734
来自专栏数据和云

使用 Direct Initial Load 初始化 GoldenGate 同步数据

作者简介 ? 桑凯 现任职于云和恩墨,具有多年 Oracle 数据库企业级运维经验,擅长容灾项目解决方案设计,作为项目经理负责多个基于 Oracle DataG...

3065
来自专栏FreeBuf

内网漫游:通过RDP劫持向远程系统执行任意代码

远程桌面协议(RDP)被广泛应用于管理员的内部网络。该协议允许系统所有者以及管理员远程管理其Windows环境。然而,RDP在为我们带来方便的同时,也为虎视眈眈...

1012
来自专栏FreeBuf

Oracle中泄露“天机”的TNS

数据库的安全是长期存在的问题。在目前大量的数据泄露事件以及漏洞面前,大家看到的大都是SQl注入、越权操作、缓冲区溢出等这些具体漏洞。往往却忽视了造成这些问题的前...

1785
来自专栏杨建荣的学习笔记

关于switchover的流程和补充(r9笔记第4天)

对于Oracle Data Guard中的Switchover一般是计划内的操作,自己其实也处理了不少的故障,也算是轻门熟路。复杂的事情简单做,简单的事情重复做...

2495

扫码关注云+社区