DataGuard - Logical Standby测试过程中的错误和解决方法

1。ORA-00332: archived log is too small - may be incompletely archived
ORA-00334: archived log: '/global/oradata/ctsdb/archive/arch1_1212.log'

设置操作系统的keepalive值可以解决,当RFS进程意识到Primary端已经断掉之后,alertlog中会有以下信息:

RFS: Possible network disconnect with primary database
Fri Aug 13 19:17:06 2004
RFS: Possible network disconnect with primary database
Closing latent archivelog for thread 1 sequence 1723
EOF located at block 15 low SCN 0:2164886 next SCN 0:2164902
Latent archivelog '/global/oradata/ctsdb/archive/arch1_1723.log'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/global/oradata/ctsdb/archive/arch1_1723.log';
Fri Aug 13 19:17:12 2004
RFS: Possible network disconnect with primary database

2。SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE

ORA-16209: Logical standby dictionary build failed to complete.

升级到9205之后出现的问题,删除原先分配给logminer用的表空间,然后catproc重新编译所有存储过程,再次执行上面的命令,就不会出错了

3。Standby端始终有一至两个日志不会被Apply,因为基于Trasaction考虑的Logical Standby Apply的机制决定了它一定不会将收到的redo全部apply,原因是事务是可能跨越几个redo的。而这一点在主库down机,尽量减少数据损失的要求面前显得很不让人满意。

4。ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL

ORA-01332: internal Logminer Dictionary error

没有解决,也正是这个错误,让我对Logical Standby彻底丧失了信心。

Bug实在是太多,性能又低,虽说可以同时Apply + Readonly,但这个优点在它的不稳定性面前实在是起不了什么决定性作用了。

整个方案改为:远程Physical Standby,本地加一台服务器用MV Replication提供查询服务。

BTW:Metalink上可以查问题,但是希望Oracle的技术人员及时帮你解决问题却是不现实的。一帮人只知道常识,想来很少有实际经验的。

 

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页