对于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吧。
对了，概念上似乎已经说服自己了，我们是不是得设计的具体一些，要不忙活一圈发现完全实现不了，那岂不成了笑柄，我们来继续解析一下，容我好好想想。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2127958/，如需转载，请注明出处，否则将追究法律责任。