世上没有永恒的主角,能够留住永恒的反是那些默默无闻的小角色,这一节出场的都是重量级选手,它们虽然不是主角,但他们比主角更重要(有时候)。
一、 READ ONLY/WRITE 模式打开物理STANDBY
前面提到关于物理standby可以有效分担primary数据库压力,提升资源利用,实际上说的就是这个。以read only或read write模式打开物理standby,你可以转移一些查询任何啦,备份啦之类的操作到standby数据库,以这种方式来分担一些primary的压力。下面我们来演示一下,如何切换standby数据库的打开模式,其实,非常简单。例如,以Read-only模式打开物理standby:
这里要分两种情况:
1) .standby 数据库处于shutdown状态
直接startup即可。
SQL> startup
ORACLE 例程已经启动。
......
2) .standby 数据库处于redo应用状态。
首先取消redo应用:
然后再打开数据库
提示:open的时候不需要附加read only子句,oracle会根据控制文件判断是否是物理standby,从而自动启动到read only模式,直接startup也是同理。
3) . 如果想从open状态再切换回redo应用状态,并不需要shutdown,直接启用redo应用即可,例如:
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
正如演示中我们所看到的,操作有一点点复杂,并且由于只读打开时就不能应用,虽然我们能够查询,但是查询的结果确是与primary不同步的,这点大大降低了物理standby做报表服务分担主库压力的可能性,对于这点呢,我们有两个解决方案:
1、 改用逻辑standby,由于逻辑standby是打开状态下的实时应用,因此数据同步应该是没啥问题了(只要 primary的数据类型和操作逻辑standby都能被支持),当然逻辑standby有逻辑standby 的问题,这个看完后面的逻辑standby相关章节,您就明白了。
2、 据称oracle11g全面改良了物理standby,最突出的特点就是在read only打开模式下,可以边接收边应用了(这下不用担心查询的数据不及时的问题了),您可以考虑升级您的数据库到最新版本,当然新版本也有新版本的问题,比如各种尚未暴露出来的bug,想想就担心是不是:)
所以你看,做技术其实并不困难,难的是做决择。这么引申过来看一看,老板们不容易啊,怪不得越大的领导脑袋上头发越少呢,为了保持我干净整洁浓密的发型,我我,我还是选择干技术吧~~~~
二、 对open resetlogs的primary数据库standby的恢复
当primary数据库被以resetlogs打开之后,dg提供了一些方案,能够让你快速的恢复物理standby ,当然这是有条件的,不可能所有的情况都可以快速恢复。 我们都知道alter database open resetlogs之后,数据库的scn被重置,也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时,redo应用会自动获取这部分redo数据。对于物理standby而言,只要数据库没有应用resetlogs之 后 的redo数据,那么这个过程是不需要dba手工参与的。
下表描述 其它 情况下如何同步standby与primary数据库。
Standby 数据库状态 |
Standby 服务器操作 |
解决方案 |
没有应用resetlog之前的redo数据 |
自动应用新的redo数据 |
无须手工介入 |
应用了resetlog之 后 的redo数据,不过standby打开了flashback。 |
可以应用,不过需要dba手工介入 |
1. 手工flashback到应用之前
2. 重启redo应用,以重新接收新的redo数据。 |
应用了resetlog之 后 的redo数据,而且没有flashback。 |
完全无法应用 |
重建物理standby是唯一的选择 |
很绕是吧,举个例子你就明白了:
假设primary数据库当前生成的archive sequence#如下:...26,27,28,然后在28的时候执行了resetlogs,又生成了新的1,2,3.....,那么standby能够正常接收并应用26,27,28及新产生的1,2,3....
如果primary数据库在28的时候发生数据出现故障,recover到27,然后resetlogs,又生成了新的1,2,3.....,这个时候(大家注意,招子放亮点):如果standby还没有应用28,刚刚应用到27,则standby还可以继续接收新的redo数据1,2,3.....并应用。
如果此时不幸,standby由于是实时应用,已经应用了28的redo数据,那么如果standby打开了flashback,不幸中的万幸啊,这时候只需要dba手工介绍先flashback到27,然后再接收并应用新的1,2,3....
如果此时非常不幸,standby由于是实时应用,已经应用了28的redo数据,并且standby也没有打开flashback,那么,重建物理standby是你唯一的选择。
这下大家都明白了吧,赶紧起立鼓掌感谢yangtingkun大大的友情客串及形象示例,很通俗,很易懂:)。
|