OracleDG 环境主备业务数据不同步备库报ORA-600错误的处理过程

用户6543014

发布于 2020-08-11 15:42:39

1.3K0

发布于 2020-08-11 15:42:39

这是一个单实例数据库，oracle11.2.0.4 ，跑在Wondows上，当时主库压力太大，用户有容灾和读写分离的需求，这样在主库跑了一段时间后搭建了一个备库，这个备库一直跑到很好，最多主库由于存储压力，删除过几个归档日志，这个删除也是确认了备库应用之后操作的，对主备都已经没有影响。所以，当这家南方公司的负责人（我就称为王工）找到我时，我还是觉得意外。

其实针对这种情况，作为DBA首先要做的就是询问最近客户做了哪些变更或者其他项目组有什么异常操作。还没等我问，王工就迫不及待的说“林工，这个库系统的人做巡检，发现空间不够，顺手删除了几个大文件，而这几个文件正好是我们的归档日志文件”，听到这我大致觉得可能跟这个操作有关系。“还有当时删除了主库一个文件xxx_temp.dbf,这个文件也很大，但是重启后又出现了一个文件，主库也拉起来了” ，删除大文件往往是系统维护的工程师清理空间的操作，由于不知道数据库自身对文件的依赖关系，随意删除文件时有发生，这次已经是遇到的第二次了。

从用户的这几个操作看，似乎觉得不可能引发ORA-600错误，由于当时我在公司，电话交流了几句，希望提供主库备库的日志，发了几个语句查看主备的同步以及相关进程情况，就放在一边了。刚下班走出公司大楼，微信突然发来王总的信息“林工，看今天能不能给解决这个问题，我们看了日志发现卡在日志17620和17621上了”，虽然王总不是搞数据库的，之前我们做过技术交流以及他也是很爱学习的人，感觉他还是看到了日志的问题，在手机上看日志，讨论确实比较痛苦，我答应王总，这个问题咱们今天争取解决，我先看看备库日志报错信息，找找资料，看了600的报错，我然王工把ORA-600的两个trc文件发给我，orclstd_rfs_32611.trc， orclstd_rfs_32613.trc两个文件。

终于回到家，泡了一杯红茶，工作过程中习惯了红茶作伴，总能给紧张的神经一丝放松，于是开始了下面的交互。看主库日志分布情况

select name,sequence#,thread#,fal,applied,archived from v$archived_log where sequence#>17600;

发现两个日志都存在，我看了下大小，比较奇怪的地方

17620_964956507.dbf 大小 1K，而17621_964956507.dbf 2662K ,对于这个大小还是感觉比较奇怪，顺带问王工是否手工切过日志，得到的答复是否定的，数据库他们没有做任何操作，除了系统维护人员的操作。

其实，系统维护人员已经意识到自己的操作是十分不当的，一直跟王工他们道歉，但是从问题现象看我们也不能就把责任直接推个对方，虽然在现实环境下推卸责任是“业内常态”，我也在微信里说了对方操作可能对数据库造成严重影响，但是并没有直接将责任算在对方身上，毕竟我们做DBA的要找到问题根源，先解决问题，拍板子就上王工他们去处理吧。

然后又继续查看双方日志是否同步

主库：max(sequence#) from v$archived_log;备库：max(sequence#) from v$archived_log;
   17788    17787

从备库日志以及查询结果看，其实主库的日志是传到了备库，但是备库卡在17620和17621，也就是这个日志文件备库无法写入数据库。

随后让王工看下备库导入日志gap也就是Oracle认为它缺少哪个日志，造成后续的数据一直无法同步，我们在备库查varchive_gap 和 vmanaged_standby结果如下所示

SQL> select * from v$archive_gap;
     THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
--------------------------------------------------------------------------------
                   1              17620                       17621


SQL> select process,status,sequence# from v$managed_standby;
PROCESS                       STATUS                        SEQUENCE#
---------------------------  ------------------------  -------------------
ARCH                              CONNECTED                       
ARCH                              CONNECTED                       
ARCH                              CONNECTED                       
ARCH                              CONNECTED                       
ARCH                              CONNECTED                       
MRP0                              WAIT_FOR_GAP            17620
RFS                                 IDLE                               17796
RFS                                 IDLE

从问题看是日志除了17620和17621之后的日志都传到备库，好像是什么原因导致这两个日志没有应用到备库，目前看好像问题比较明朗了，也就是日志文件写Buffer异常，造成无法应用该日志，而缺日志备库就无法后续日志推进，也就无法实现与主库的业务数据同步。

我打开trc文件，记录如下

ORA-00600: 内部错误代码, 参数: [2730], [331], [1], [5], [17620], [17620], [512], [512], [], [], [], []
Exception 600 received while writing lno 5 thread 1 seq 17620
*** 2020-06-16 11:41:17.221 4639 krsb.c
krsb_stream_write: Error 600 while attempting to write buffer
Redo Shipping Client Established Network Login
krsv_dsga: Dispatching RFS shutdown notification

我们发现最扎眼的一行记录krsb_stream_write: Error 600 while attempting to write buffer写错误

看来是读文件写Buffer报错了,从报错信息，经过查询发现是如下问题导致

This happens due to Unmatched compatibility setup on the primary and the standby.The value of compatible parameter in primary and standby is different.

但是之前主备compatibility参数没有改过，一直也没有问题，而这种说法感觉缺少十足的依据，是否是Oracle没有公布的bug呢，这就不得而知了，所以我跟王工提出，将主库的日志文件拷贝到备库，在注册归档日志，看是否报compatible错误，果然手工注册过程确实报错如下：

alter database register logfile '/opt/oracle/archivelog/1_17620_964956507.dbf';
ORA-00331：日志版本11.2.0.4与Oracle版本11.2.0.0不兼容 ORA-00334
归档日志：'/opt/oracle/archivelog/1_17620_964956507.dbf'

这个问题需要修改参数COMPATIBLE解决，需要重启备库

Alter system set compatible='11.2.0.4' SCOPE=SPFIE;

注意：此时我们做的操作是将主库日志重新拷贝的备库之前的归档目录下，从trc文件提示可以知道Oracle是知道这个归档日志是存在的，只是在读日志文件报错了，造成后续归档无法推进。

为了该参数生效我们先关闭备库，再重启备库，这个时Oracle会做自动做恢复追归档

alter database recover managed standby database cancel;
shutdown immediate;

重启备库

startup mount;
alter database open;
alter database recover managed standby database using current logfile disconnect from session;

在重启之后，我让王工监控告警日志，并提示”很可能这两个日志能跑过去“，此时王工风趣的回复”意思是不用注册了？那就完美了！“，客户对我们充满信任，但是我们每次说话还是有技术经验和原理在支撑着，当然即使有其他问题相信我们也能解决，正如一位朋友说的”没有解决不了的技术问题“。”好像跑过去“，身隔千里，我似乎感受到王工的喜悦之情，赶紧看看他发过来的日志

Parallel Media Recovery started  with 8 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /opt/oracle/archivedlog/1_17620_964956507.dbf
Media Recovery Log /opt/oracle/archivedlog/1_17621_964956507.dbf
Media Recovery Log /opt/oracle/archivedlog/1_17622_964956507.dbf
....

看到这，也就十分肯定的说，备库已经成功应用了之前无法读取的两个日志，开始追后面的归档，这个就是时间问题了。

”王工，确实跑过去，就等着数据追平吧“我也故作淡定的说，其实内心还是比较激动，每次成功处理完客户的故障性能问题，心里总有种莫名的满足感，或许这就是做技术人的价值追求吧！

备注：虽然问题处理了，但是还是感觉有疑问，之前主备同步日志，应用日志都没问题，到底是什么触发了这个两个日志文件的写入问题呢，这个疑问留给大家分析吧，如果你也遇到过，欢迎继续交流。

- End -

本文参与?腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2020-08-07，如有侵权请联系?cloudcommunity@tencent.com 删除

数据库