Active Data Guard初探(一) (r10笔记第76天)

对于Active Data Guard,我是这样想的,可能会有很多不对的地方,互相讨论,一起补充吧。 如果有一天我成了Oracle的产品架构师,时光倒退10年,那个时候还是9i,10g的年代,现在摆在我面前的一个艰巨的任务那就是Data Guard的可用性,易用性的问题,刚刚从xx部门得到了一份数据,可以看到目前的Data Guard尽管提供了Physical Standby和Logical Standby,但是显然客户对于的Physical的接受程度要远高于Logical,毕竟能够保证数据的一致性,物理一致性的可靠性是毋容置疑。 恩,这样不错,不过似乎我看到了更多的抱怨,数据库在open阶段是无法应用归档,而应用归档的同时却无法提供对外的查询服务,绝大多数的系统都会以数据的完整性为准,同时放弃了提供对外查询的需求。这是常识,我们设计数据库就是这样的意图,让数据库做专业的事情,不能两者兼顾,这个我之前已经强调很多次了。 但是看着报告,似乎让我有了一些想法,这个常识是我们创造出来的,能不能做出改变呢。如果数据库能够在open状态,那自然会开始数据文件和实例的映射,这样我的数据库服务是始终可用的,不会在最后一刻才发现竟然是某个地方出现了问题导致数据库无法正常open,这一点很重要,而且同时能够分担主库原有的查询任务,这样看上去似乎蛮不错的,那么数据恢复的事情怎么办呢。如果能够做成,简直就是革命性的突破啊,想想这个可能会给客户的数据需求带来无限的可能,想想都有成就感。 我们来简单做一个假设,现在我们要做这么一件事情,我们改考虑哪些事情。 首先数据库备库提供服务,只能是open状态,但是open_mode只能为read only,如果为read write,我们的备库就是Logical Standby了,同步机制就逊色许多,所以我还是希望通过redo的数据来保持数据库的物理一致性状态。这个时候为了最大化满足需求,应该是读为主,然后日志应用为辅(open阶段),而不是反过来,一遍应用日志一遍提供数据查询服务(mount阶段),这样的话,我为了区别于普通的read only状态,我得定义一个新的状态,标识这种新的特性,那就给状态标识为read only with apply吧、 状态我们标识出来了,我们该怎么进一步来补充和实现。如此看来,这个过程不是简单改几个参数,改几行代码就行的通的,我已经做好了全面设计,影响范围评估的准备。是的,我是把它当做一个全新的项目来做的。 但是问题来了,数据库在open read only阶段,SCN是不会增长的,也就意味着这个备库是完全冻住的状态,DBWR的功能实在有限,数据读取它也帮不上什么忙,而对于数据的写入才是它的本质工作,要知道我们需要做的是数据的恢复工作,这个工作还是很艰巨,而且内部涉及的东西实在很多,牵一发而动全身。我想到一个情况,那就是在open阶段(read write)的时候,如果是非系统表空间,数据文件还是可以做数据恢复的,有很多种方式可以这样做,比如增量备份的方式,根据最后的状态,比如根据redo的数据变化,根据整个过程。所以我们得保证备库不能只是read only,还得有read write的味道,而对于read write的控制就尤为重要了,我们需要保证的是不能通过DBWR来刷脏数据到数据文件中,而这个入口只对指定的操作是开放的,比如非系统表空间的增量数据同步,这个得有一个统一的方式,那么我就可以指定通过日志,恩,这样还不错,我可以在命令中也加以标示,比如这样扩展: recover managed standby database disconnect from session using current logfile;这样,using current logfile就会标示出我们是希望通过redo的数据变化过程来同步的。 而这个有些特别的read write的入口打开之后,似乎我还能做更多的事情,备库不是可以开启闪回数据库的特性嘛,原本的闪回数据库只能读,现在允许特定状态下的写入,但是因为有闪回日志,我们可以很容易回退,总之那个初始的还原点是不会变的,如此一来,好像空间一下子变大了,存在无限的可能。那这种情况和开始的预想好像有一些差别了。但是似乎无心插柳柳成荫,我还顺带扩展,保证初始的还原点不变,让备库不光可读,还可以写(当然是临时写入),我给它起个更酷的名字,就叫snapshot Standby吧。 对了,概念上似乎已经说服自己了,我们是不是得设计的具体一些,要不忙活一圈发现完全实现不了,那岂不成了笑柄,我们来继续解析一下,容我好好想想。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

测试人员必看:传统测试向工程效能转型的最佳实践

内容来源:2018 年 5 月 20 日,eBay中国研发中心技术主管茹炳晟在“2018全球技术周暨第四届南京(全球)软件大会”进行《Quality Engin...

4920
来自专栏网络

资深女程序员告诉你:微服务架构如何实践?80%以上男程序员点赞

上篇文章给大家介绍了什么是微服务架构,本文将会讲到如何实践微服务。 不知道微服务架构的,可以看我上一篇文章 微服务听上去好像不错,具体怎么落地啊?这需要回答下面...

4067
来自专栏ThoughtWorks

你的微服务敢独立交付么?| 洞见

最近经常在项目或是社区里听到大家谈论微服务架构,但谈论的焦点更多集中在微服务拆分,分布式架构,微服务门槛,DevOps配套设施等话题上。

932
来自专栏ImportSource

我所知道的那点微服务

忽然一夜春风来,人间处处微服务。这真是一个相当火的概念啊。笔者第一次知道微服务这个概念是在15年4月份,应该是。 铺垫 有一日翻到martin fowler的博...

36210
来自专栏Spark学习技巧

第5篇:数据库系统的实现

前言 前面的文章中,主要都是在围绕关系数据库理论进行研究,没有涉及到数据库系统的具体实现。 虽说数据库系统的具体实现因业务环境,RDBMS等因素而异,但总体开发...

3167
来自专栏程序你好

如何从传统单体架构转向微服务

1504
来自专栏看看搬搬

物联网的消息传递

为一个物联网用例部署消息代理模块,对于broker接口的可延展性而言会带来新的挑战。我们现在谈论的物联网涉及到数千个连接,消费者和目的,这让我们必须思考如何更仔...

2966
来自专栏phodal

【图说】全栈工程师的 18 项基本技能,你会多少?

30分钟了解《Growth:Web开发思想》 本文总结了正在撰写的《Growth:Web开发思想》里提出的一系列实践,为18个步骤。 任务切分 即将目标切换成...

2427
来自专栏ThoughtWorks

登录工程:现代Web应用的典型身份验证需求|洞见

朋友就职于某大型互联网公司。前不久,在闲聊间我问他日常工作的内容,他说他所在部门只负责一件事,即用户与登录。 ? 而他的具体工作则是为各个业务子网站提供友好的登...

3415
来自专栏程序你好

如何从传统单体架构转向微服务

当今,把单体架构的应用拆成微型服务是很时髦的。让我想起了2000年世纪初的那些日子,那时SOA正在流行,大多数公司,供应商和系统集成商,正忙着挥动SOA魔杖,希...

6748

扫码关注云+社区

领取腾讯云代金券