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的技术人员及时帮你解决问题却是不现实的。一帮人只知道常识，想来很少有实际经验的。