In Memory Undo与logical standby database

最近碰到了一个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;

Oracle10gR2 Logical Standby(七)日常管理与优化

有一段时间没怎么写技术性的文章了,继续前面的逻辑备库系列,这是第七篇。

对于逻辑备库来说,日常管理主要需要关注SQL Apply。切换是很少发生的动作,而logminer的速度相对于sql apply来说是很快的,恢复的进度主要还是取决于SQL Apply的进度。

一、SQL Apply进程

SQL Apply实际上是一组后台并行进程,包括reader,preparer,builder,analyzer,coordinator,applier 六种不同作用的进程:

  • reader:读取redo记录传递给preparer进程
  • preparer: 根据redo记录和数据字典信息生成LCR
  • builder: 将同一个事务的LCR打包。对于大事务(eager transaction),可能被打成多个事务包(transaction chunk),那么可能有些包里是不包含commit的,每一个事务包都可能交给不同的applier进程。
  • analyzer:分析事务包之间的依赖关系
  • coordinator:将分析好的事务包交给applier进程
  • applier:将事务包应用,如果事务包依赖其他事务包,则需要等待相应的事务包完成。事务能否commit,可能还需要根据不同的情况从coordinator获得相应的信息。

Read more of this post

Oracle10gR2 Logical Standby(六)逻辑备库的Failover

当主库由于某种原因不可用时,需要考虑将备库直接拉起来,这就是failover。基本原理和操作步骤和switchover差不多只是不管主库,直接将备库切换成新的主库。

一.切换前的检查

确保所有能应用的归档都已经应用。确保监听设置正确。确保切换后应用能连接到新的主库等。

二.停止SQL Apply

如果原来是停止的,那么可能还有部分最新的日志没有应用,则最好先应用一下日志,减少最终切换需要的时间:


alter database start logical standby apply finish;

alter database stop logical standby apply;

三.激活备库

以下命令会终止RFS,然后应用还未应用的日志,最后将数据库转换成primary角色。

alter database activate logical standby database finish apply;

至此,逻辑备库已经转换成主库,非常的简单。由于数据库本身是open的,转换后无须再作任何操作

select database_role from v$database;

DATABASE_ROLE
—————-
PRIMARY

四.处理其他备库

如果原来的DataGuard中还有不止一个逻辑备库,则其中一个逻辑备库failover成主库以后,其他的备库需要重新指向新的主库。首先在其他备库创建一个到新主库的database link

alter session disable guard;
create database link newprimary connect to user identified by password using ‘newprimary';
alter session enable guard;

然后重新指向新的备库

alter database start logical standby apply new primary newprimary;

如果执行时出现ORA-16109: failed to apply log data from previous primary,则备库只有重做了。

Oracle10gR2 Logical Standby(五)逻辑备库的Switchover

相对物理备库的切换,逻辑备库的切换稍微复杂点,但只要按照步骤,整个操作过程也可以在很短的时间内完成。这里记录下主库正常时的switchover操作过程:

1.切换前的检查
包括主备库参数设置,主备库的TNS设置,以及应用连接数据库的TNS等,确保主备库角色转换后整个系统运行不受影响。

2.主库准备切换

alter database prepare to switchover to logical standby;

命令执行成功后,主库的状态

select switchover_status from v$database;

SWITCHOVER_STATUS
——————–
PREPARING SWITCHOVER

3.备库准备切换

alter database prepare to switchover to primary;

命令执行成功后,备库的状态

select switchover_status from v$database;

SWITCHOVER_STATUS
——————–
PREPARING SWITCHOVER

4.主库开始切换
执行完第3步后,现在的备库需要生成logminer所需要的数据字典信息,然后传送到现在的主库,所以要执行逻辑备库切换,必须在备库也设置到主库的归档路径,并且主备库监听都需要保持开启。否则,切换的状态就会一直停留在PREPARING SWITCHOVER。

备库数据字典信息传递到主库后,主库的状态变成TO LOGICAL STANDBY,这时才能执行实际的切换。

select switchover_status from v$database;

SWITCHOVER_STATUS
——————–
TO LOGICAL STANDBY

alter database commit to switchover to logical standby;

注:在PREPARING SWITCHOVER状态时,可以通过执行以下命令取消切换操作:

alter database prepare to switchover cancel;

5.从库切换
上一步成功后,备库的状态应该变成了TO PRIMARY,则可以执行切换

select switchover_status from v$database;

SWITCHOVER_STATUS
——————–
TO PRIMARY

alter database commit to switchover to primary;

6.在新的备库启动日志应用进程

alter database start logical standby apply;

如果是实时应用,则

alter database start logical standby apply immediate;

无觅相关文章插件,快速提升流量