最近碰到了一个bug，导致逻辑备库重建，相当的郁闷。我们一个系统，包含一个主库，一个物理备库，一个逻辑备库。系统不久前刚从9i升级到10.2.0.4。5.30号因为系统维护，将原主库和物理备库做了一次switchover，切换没有什么问题，做了很多次了。这是逻辑备库突然报出了ora-600错误：
ORA-00600: internal error code, arguments: [2730], [331], [1], [13], [293130], [293130], [], []
ok，不用紧张，这个错误没啥问题。因为主库从9i升级到10g之后，为了保留降级的可能，compatible参数还是保留设置为9.2.0.0.0了，而这次切换，顺便把compatible改成了10.2.0.0.0，所以出现主备库的参数不一致了，就会报该错误。修改该参数即可。
但是，问题出来了：
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [293141], [91], [96], [], [], []
Metalink上一查(Doc ID:761661.1)，麻烦来了:
The ORA-00600: [KRVXBPX20] indicates that logical standby builder detects IMU (In Memory Undo) in the redo streams. Logical standby does not support IMU and enabling supplemental logging disables the IMU.
In customer’s case, supplemental logging is enabled in the original primary database, but it is not enabled in the original physical standby database. Prior to 11.2 (which has not been released yet at the time of writing), supplemental logging DDLs are not propagated to the physical standby database. Thus they had a situation where the primary has supplemental logging set, but the physical standby did not.
晕死，逻辑备库不支持IMU(In Memory Undo,10g新特性)，所以要使用逻辑备库，必须在主库禁用IMU，否则将导致逻辑备库损坏，并只能重建。那为什么原来主库升级到10g之后，逻辑备库是正常的，而执行switchover切换到物理备库，才碰到问题呢？
我们的升级，是在主库执行升级脚，然后备库使用新版本的oracle软件直接应用主库传过来的日志的方式来完成整个系统的升级的。因为逻辑备库是在主库升级到10g后配置的，在执行exec dbms_logstdby.build生产数据字典信息的时候自动配置了supplement logging，而开启supplement logging将自动禁用IMU，所以未切换前逻辑备库是正常的。而问题在于，主库设置supplement logging的语句，并不会在物理备库上自动应用，这样实际上物理备库还是原来9i默认的未开启supplement logging的状态，这样一切换过来，问题就发生了。
如果你也在使用10g的逻辑保备库，要避免该问题，则可以：
1.直接在主库和物理备库都设置_in_memory_undo=false
2.在主库和物理备库检查supplement logging的状态
select supplemental_log_data_min as supp_log,
supplemental_log_data_pk as supp_pk,
supplemental_log_data_ui as supp_ui
from v$database;
SUPP_LOG SUPP_PK SUPP_UI
---------- ---------- ----------
NO NO NO
只要上述结果中，任意一列值为NO，则需要执行（物理备库可以mount状态或者open readonly状态执行）：
alter database add supplemental log data (primary key, unique index) columns;
近期评论