技术专题总结：standby Database (已经加入精华区，取消置顶)

lmh

我在单机上建立双机热备份成功,设置SQL>recover managed standby database timeout 20;20分钟内没有传来归档日志,跳出会话之后,应该如何再次进入MANAGED备份模式?试了几次都未成功.
而且进入READ ONLY 模式之后也无法返回到 recover  managed standby database timeout 20;模式,
为什么?
报错如下:
ORA-01093: ALTER DATABASE CLOSE ?????????????

kerlion

首先我要感谢snowwhite2000的辛苦工作，和无私的贡献

我个人也认为STANDBY，不是个好用的东西，我也曾经兴致勃勃地研究过，发现他有用的东西实在太少，缺点太多
1.技术过于复杂，除非你想印证一下你的ORACLE技术
2.我们从STANDBY得到的好处，实在不值得一提，得到远少于付出
3.如果mount only后，能够auto continous apply logs,那该是一个多么好的东西啊，可惜没有。
4.如果要进行报表分析等。shutdown/backup/recover to anonter machine,明显要简单快捷的多，而且还可做任何操作
5.如果真的primary DB 当掉了，最后一个current log，也许本身并
没有损坏，但是你不能open db,所以你不能achive current log,
如果我能open，我还需要standby 吗？所以一定要丢失数据，
那么我们有怎么能把此standby db做为primary DB呢？？如果能直接copy current log ，那也许好多了
6. active standby 数据库后， 一般都被RESETLOG，这又涉及到ORACLE另一个特别麻烦的技术，一不注意，你可能进入万劫不复
的地步。TMD，你所烦不烦恼。

我觉得OPS也不好用，技术更加复杂，
CLUSTER+RAID技术，比ORACLE的解决方案简单实用

overtime

[I]首先我要感谢snowwhite2000的辛苦工作，和无私的贡献
我个人也认为STANDBY，不是个好用的东西，我也曾经兴致勃勃地研究过，发现他有用的东西实在太少，缺点太多
1.技术过于复杂，除非你想印证一下你的ORACLE技术 [/I]

不会吧！

[I]2.我们从STANDBY得到的好处，实在不值得一提，得到远少于付出 [/I]

Oracle 公司真的这么没品味？

[I]3.如果mount only后，能够auto continous apply logs,那该是一个多么好的东西啊，可惜没有。 [/I]

manage standby  不是这样吗？

[I]4.如果要进行报表分析等。shutdown/backup/recover to anonter machine,明显要简单快捷的多，而且还可做任何操作 [/I]

这样也行，那这个数据库太小了。还要shutdown, 7*24怎么办？

[I]5.如果真的primary DB 当掉了，最后一个current log，也许本身并
没有损坏，但是你不能open db,所以你不能achive current log,
如果我能open，我还需要standby 吗？所以一定要丢失数据，
那么我们有怎么能把此standby db做为primary DB呢？？如果能直接copy current log ，那也许好多了 [/I]

不用activate standby的方式，oracle是可以在primary和standby之间切换而不用重建数据库的，current log也可以应用到standby上。

[I]6. active standby 数据库后， 一般都被RESETLOG，这又涉及到ORACLE另一个特别麻烦的技术，一不注意，你可能进入万劫不复
的地步。TMD，你所烦不烦恼。[/I]

成长的烦恼

[I]我觉得OPS也不好用，技术更加复杂，
CLUSTER+RAID技术，比ORACLE的解决方案简单实用[/I]

这和standby就不是一回事，磁盘阵列坏了，或文件被误删除了，你的cluster和raid有什么用？

oracle

如果你真正理解了oracle的概念，standby和OPS小菜一碟。
如果cluster和raid能解决，还有人去要OPS和standby吗？Oracle也没必要做这些产品。raid不能解决机器down的问题，做真正的cluster还不是要OPS？
standby是有缺点，但注意它实施的经济代价是很低的，没钱又想做很多的事情，不太现实吧？就好象Linux有很多的弱点，但它不要你钱，还能说什么呢？

最初由 kerlion 发布
[B]首先我要感谢snowwhite2000的辛苦工作，和无私的贡献

我个人也认为STANDBY，不是个好用的东西，我也曾经兴致勃勃地研究过，发现他有用的东西实在太少，缺点太多
1.技术过于复杂，除非你想印证一下你的ORACLE技术
2.我们从STANDBY得到的好处，实在不值得一提，得到远少于付出
3.如果mount only后，能够auto continous apply logs,那该是一个多么好的东西啊，可惜没有。
4.如果要进行报表分析等。shutdown/backup/recover to anonter machine,明显要简单快捷的多，而且还可做任何操作
5.如果真的primary DB 当掉了，最后一个current log，也许本身并
没有损坏，但是你不能open db,所以你不能achive current log,
如果我能open，我还需要standby 吗？所以一定要丢失数据，
那么我们有怎么能把此standby db做为primary DB呢？？如果能直接copy current log ，那也许好多了
6. active standby 数据库后， 一般都被RESETLOG，这又涉及到ORACLE另一个特别麻烦的技术，一不注意，你可能进入万劫不复
的地步。TMD，你所烦不烦恼。

我觉得OPS也不好用，技术更加复杂，
CLUSTER+RAID技术，比ORACLE的解决方案简单实用 [/B]

eve

Thank you snowhite2000

snowhite2000

五、Primary and standby database的重建

当原 standby database 因为 primary database的  failure而成为 primary database 之后，一般在仅接下来的第一个非高峰工作时段，就要进行 standby database的重建。

怎样对 Standby database进行重建，首先要考虑系统的设置，以及有多少的时间进行重建。

实例一：如果 primary/standby  两个nodes都是为该数据库专用的，且设置相同的话，可以保留 standby node上面的数据库做为 primary database，在原来的 primary上面建立一个standby database就可以了。系统不需要 downtime。备份文件可以采用上一部份中，standby database变为 primary database open 之前的冷备份，再手工 apply 从数据库 open  到目前的所有 archived logs。

注意，这种情形下，要重新设置当前 primary database node的 tnsnames.ora文件，以及当前 standby node上面的 listener.ora文件。(详细参见上面部份的 standby database的建立)

这种设置在 standby database系统中算是最理想的设置了，甚至在某些情形下面，可以 activing standby database，直接对 primary database进行 recovery，再在standby node上重建 standby database。具体的设置和操作，是要根据项目的要求设定的。

实例二：这种情况下，不管怎样，原来的primary node 要变回 primary database的服务器， standby node上的database要回归 standby database 的状态。在这种情形下，如果你能得到足够的系统 down time，最容易的办法，就是将 standby node上面的database shutown，拷贝所有的 all database file (包括 control files，但不包括 parameter file) 到 primary node 原来的目录下面，覆盖住原来的文件，清除掉原来 database的 alter.log/trace files/archived log files等等，直接 open database，同时把 application side的所有 tnsnames.ora文件 host name/IP 改回成 primary node 即可。重建 primary database的时间只比系统拷贝文件的时间多出 10分钟而已。

在 standby node上面：在 database shutdown之后，拷贝文件去 primary node的过程中，要对整个 database进行一次冷备份。之后用原来备份的 standby database的 parameter file取代当前的 parameter file，再从已经 open的 primary database上面建立一个 standby database的 control file拷贝到 standby node上面取代当前的 control files。

如果此时，primary database 尚未生成新的 archived log files， standby database 可以直接进入 managed recovery mode。

这个实例是我本人比较喜欢采用的一种方法。现给出具体的操作步骤如下：

重建 primary database的过程：

1)        在 standby node上面建一个 standby database 的 control file:
Alter database create standby control file ‘/oradba/DBA/stcrt1si.ctl’;
2)        Shutdown database normal/immediate;
3)        对 database进行一个冷备份
4)        清除所有 archived log files (原来的 primary node上面的)
5)        拷贝除了 parameter file 之外的所有 data files/control files/online redo log files 到 primary node 原来 directory下面，覆盖掉原来的文件。
6)        可以用原来已经存在的 instance 直接 open database
       
重建 standby database的过程：

1)        拷贝刚刚建好的 control file (见重建 primary database过程) standby database parameter file 指定的 directory 下面
2)        清除 standby node上面全部的 archived log files.
3)        核对一下 parameter file是否与原来的 standby database parameter file相同 (应该是相同的) 之后，就可以直接 Startup standby database:
Startup nomount pfile=’xxxxxxxxxxxxxxxxxxx’;
Alter database mount standby database;
4)        Recover managed standby database timeout 15;
(因为是在非工作繁忙期，所以，primary上面不会有很多 transactions，所以没有产生新的 archived log file之前，可以直接进入 managed recover mode。如果已经产生了 archived log files，要先手工 recover。



实例三：在实例二的情况下，如果在 primary node 上面重建 primary database 的时间，用户不允许有足够多的系统down time，可以采用的方法就是，在 primary node 上面再建目前运行的 database 的standby database，建立好之后，可以在最短时间内，进行一个转换。

在这种情况下，需要主意的问题是，在原来的 primary node 上面的 parameter file 要修改成为 standby mode 的 parameter，同时 network file 也需要做相应的更改。 (standby database 改来改去的，最好每个版本的文件，如果 parameter file, tnsnames.ora, listener.ora 等文件，专门收集到一个地方，会受益非浅的。)

在这个实例下运行，在 activated 了在 primary node 上面的 standby database，shutdown 之后，还是要做一次 cold backup 的。因此需要的 system downtime，几乎就是一次 cold backup 的时间。怎样重建standby database 在原来的 standby node上面，请参照前面如何建立 standby database 部份所讲的内容。

snowhite2000

后记

从去年的十二月十八日开始写 standby database 的技术总结，到今天完成后记，历时两年，可谓长矣。

對于本篇的內容，白雪力求完成一份概括全部讨论问题的技术总结，希望从来没有使用的 standby database 的朋友，有一个基本的概念；希望对要实施 standby database 的朋友，有一个基本的技术指导。希望该篇技术总结能够达到白雪的初衷，对论坛的各位朋友有所帮助。

日精月华，斗转星移。回想每每遇到困难，得到了论坛上朋友们多方鼓励和支持，是很多年来未曾有過的﹐白雪非常的感動。在此﹐向這些朋友致以衷心的敬意和感谢。

同时亦非常感谢当初参加讨论的所有朋友，特别是提供资料的朋友：blossom(ak66), allanliao, 半瓶醋(it is a good name. ), guan_yi 等。

日后在精力和时间都允许的情形下，白雪愿意继续推出大家感兴趣的技术专题。如果您有问题，请贴在论坛上，或留悄悄话给我，欢迎大家参与。

最后，对支持白雪的朋友再次的感谢。


参考文献：
1.        Oracle 8i 随机文档：Oracle8i Standby Database Concepts and Administration
http://otn.oracle.com/docs/produ ... .817/a76995/toc.htm

2.        Oracle white papers.
        http://otn.oracle.com/deploy/ava ... s/ha8i_listing.html

duanyan

冬天了，虽然是暖冬，却是IT的严寒，在这个冬天，认识了ITPUT，认识了如白雪一样无私的各位。感动。

yybsnz

大家好：
我对于在primary database里做nologging操作时，要将做此操作的table a和control flie都拷到standby database有一点疑问：如果table a 在做完了nologging操作后又做了其它操作 （假设命名为operateA,logging方式），,然后将table a 和control file 拷到standby database.当standby database 用archived log做恢复时，会不会又将operateA再做一遍（此时拷过来的table a 里已有此操作了）。为什么？

恳请各位大侠无私的帮助！

ruiliming

首先感谢白雪先生的无私奉献，希望大侠能在方便的时候做一个关于OPS的专题好吗。