暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

#Oracle# 恼人的OGG-01934 OGG-06530 OGG-00543

OCM之家 2021-04-16
2036

一、事故现场


今早巡检告警显示OGG出现异常,源端抽取进程延迟时间将近20小时,一种不详的预感漫上心头。
首先得到怀疑的是系统存放dump文件的目录满了,满了之后抽取进程会Hang着等待,直到放置文件的目录出现可用空间。查看了目录才占用68%,显然不是这个原因。
那会不会是EXTSTN进程假死了呢?重启EXTSTN进程发现端倪,原来是MGR管理进程宕掉了。那就重启MGR进程呗,嚯,一动不动,妥了,大活儿来了。


打开MGR进程Report报告,Warning三兄弟洋洋得意的向我招手:
OGG-01934  Datastore repair failed.
OGG-06530  Berkeley Database encountered a critical error.
OGG-00543  Unexpected threading library failure. Error code 16
                           (Device busy).
嘿,又是你。



二、解决之道


说到这个问题可真算是“老朋友”了,当年第一次出现的时候,让我如芒刺背,至今记忆犹新。
网络上对于OGG问题的分享少之又少,翻烂了百度,找遍了Google之后,最后是在MOS里找到了解决之道。
这个问题记录在 (Doc ID 2149151.1) OGG-00543 Unexpected Threading Library Failure. Error Code 16 (Device Or Resource Busy) 中,文中分析是由于OGG存放信息的Barkeley数据库出现了问题,由于数据库轻量,且无业务内容存放,故只需删除重建即可,给出的解决方案如下:


三、说干就干


既然定位到问题在哪了,那就快点恢复吧。
1. 按照指导,首先要把OGG有关进程全部停掉。由于MGR进程已经停摆,这里需要使用文件系统Kill -9的方法,灭口所有活着的进程们。


2. 杀掉进程后,GGSCI环境再次查看一下进程情况,全部关闭后(其实不关也没啥问题),我们动手删除Datastore。
这里就出现了一个小点,当年这个点可也是卡了好一会:在删除Datastore后务必要退出GGSCI再次登录,这样才能刷新上下文,让后面的创建工作成功进行。


3. 好,没有问题,接下来就是核心步骤:mmap方式重新创建Datastore,然后启动MGR进程。一般这个步骤时间会在几秒到几分钟徘徊,稍安勿躁,耐心等待即可。


4. 成功启动MGR进程后,双保险再查看一下MGR的Report日志,问题不大,MGR起来了。


5. 最主要的步骤已经完成了,接下来就是把其他难兄难弟们都拉起来,启动后Info all查看进程状态,诸位各司其职,OGG恢复正常。


6. 再拿日志验证一下,日志留下了他们启动的记录,启动成功。


至此,问题解决了,“老朋友”希望没有下次见了。


四、不吐不快


自OGG同步表体积超过500G之后,我们的OGG就开始频繁出现问题。最开始的目标端REP进程延迟8小时,之后的频繁出现batch模式失败错误,为了这个问题,修改了应用模式,于是又导致出现了这个问题。可以说我们是一直用问题来解决问题的。

目前同步表体积已经超过1T,虽然我们还在挣扎,对热点业务改造,对表进行分区,把无用索引删除等等等等,但也只是把延迟时间控制进了4小时。但是不断增长的数量级,让“娇弱”的OGG已经疲惫了。

我们必须承认技术是必须要依托使用场景的,对于目前的场景,OGG已成强弩之末,看来需要替换掉这位老将了。


文章转载自OCM之家,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论