每月关注：55 页 干货，汇总一个月数据库行业热点事件、新的产品特性，包括重要数据库产品发布、警报、更新、新版本、补丁等。
亲爱的读者朋友：
为了及时共享行业案例，通知共性问题，达成共享和提前预防，以及共同学习国产数据库内容，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等，以及对国产数据库的一些突出能力的总结。
此文档原本是我们为重要客户整理的经典案例，现限时开放下载，希望可以帮助到读者朋友们。
目录
- 新闻：2020年2月数据库流行度排行
- 聚焦：深入解析 | Oracle Database 20c 十大新特性一览
- 聚焦：Oracle Database 20c ：云上数据库创建步骤指南抢鲜预览
- 经验：MySQL故障分析之Abort Connection
- 经验：探索内存问题如何造成数据库性能严重异常
- 问题：机房掉电LostWrite强制启库
- 问题：核心数据库一波三折异常重启分析
- 警示：Oracle 18及19c Merge into因bug触发ORA-30081
- 警示：Oracle 11g部分版本因bug导致宕机
- 总结：高斯数据库运维应知应会
- 公告：数据库“每日一题”新功能上线！
本文出自《云和恩墨技术通讯-2020.02》，原文：https://www.modb.pro/doc/2249（复制到浏览器中打开或者点击左下角“阅读原文”）
另：在“数据和云"公众号后台回复“云和恩墨技术通讯”即可查看并下载往期技术通讯集锦。
问题：核心数据库一波三折异常重启分析——桑凯
数据库异常重启的原因多种多样，但总的来说不外乎以下原因：存储、网络、操作系统或者数据库本身以及bug等等。当我们面对这类故障时，细致入微的排查显得格外重要，尤其是当提SR之后无法准确定位问题时，那我们是否就缴械投降了呢？答案是否定的。本文分享一起客户近期数据库异常重启，且提SR依然未解决的案例，在此分享给大家。
问题描述
某客户核心数据库第二节点在2019年12月21日3:06出现实例重启。该数据库第一节点在2020年1月29日2:06又一次出现实例重启。
问题分析
1.查看alert和trc日志
通过查看数据库故障时间段的alert和trc日志发现从数据库在2019-12-21 03:06:32出现600错误：
随后在03:06:42实例2被LMS进程terminate。
通过该Alert日志中“ORA-00600: internal error code, arguments: [kjbmpsch:rcvrd], [174],[1], [], [], [], [], [], [], [], [], []”错误函数和对应的TRC文件stack信息，在Oracle MOS中找到如下BUG信息，但是“ kjbmpsch:rcvrd ”相关的BUG在 12.1.0.1时已经修复，而我们数据库目前的版本为12.1.0.2版本，与BUG环境并不匹配。
经过进一步深入排查发现该AlertLog的LMS0的进程号(7079142)和做Cdump时显示的OSID(46662761)并不对应，该问题通过SR咨询Oracle官方，官方也未给出明确原因，仅要求升级到更高版本。
通过查看2020-01-29的日志分析：数据库在2020-01-29 02:06:19出现ORA-00600错误：ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],[0x1268357A8], [0x1268368F8], [384], [], [], [], [], [], [], [], []。
通过我司对该ORA-00600错误函数和对应的TRC文件的stack信息，进行深入分析，在Oracle一篇关于AIX操作系统中LMS Crash with ORA-00600 [kjctr_pbmsg:badbmsg2] 和 ORA-29770报错的文档中匹配到了对应的报错函数和stack trace。
ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2], [0x1268357A8], [0x1268368F8], [384], [], [], [], [], [], [], [], []2020-01-29 02:06:19.643840 :kjzduptcctx(): Notifying DIAG for crash event----- Abridged Call Stack Trace -----ksedsts() 244<-kjzdssdmp() 236<-kjzduptcctx() 512<-kjzdicrshnfy() 1008<-ksuitm() 6136<-ksbrdp() 6144<-opirip() 1540<-opidrv() 1124<-sou2o() 240<-opimai_real() 292<-ssthrdmain() 452<-main() 208<-__start() 112 |
|---|
明确指出该问题是由于LMS进程由于不明的原因接受到一个巨大包或者损坏包，该问题间歇性发生，导致实例崩溃，数据包的损坏发生在操作系统或者网络层。
2.网络层分析
由于LMS进程主要负责私有网络的数据传输，对核心数据库双机的私有网络进行了比较细致的排查。
OSW数据分析：通过分析OSW每15秒采集的网络数据，可以看到在2019年12月21日03:06:27采集到第二节点的主机UDP信息中bad data length fields累计数值为5，而到了03:06:43该累加值变为77。期间刚好经历了实例重启。第一节点该指标并未变化。
zzz ***Sat Dec 21 03:06:27 CST 2019udp: 1941579855 datagrams received 0 incomplete headers 5 bad data length fields 0 bad checksums 17260917 dropped due to no socket 13170454 broadcast/multicast datagrams dropped due to no socket 20771 socket buffer overflows 1911127708 delivered 499362874 datagrams outputzzz ***Sat Dec 21 03:06:43 CST 2019udp: 1941734652 datagrams received 0 incomplete headers 77 bad data length fields 0 bad checksums 17262013 dropped due to no socket 13170454 broadcast/multicast datagrams dropped due to no socket 20771 socket buffer overflows 1911281337 delivered 499390230 datagrams output |
|---|
该指标显示出UDP数据包在传输过程中出现错误数据长度，数据包在传输中存在错包。
在2020-01-29 02:06OSW采集的网络统计数据中同样可以看到fragments dropped在数据库宕机前后出现跳变，该指标代表网络中存在丢包。在一个良好的网络中，该统计值应为0。
在参考Oracle两篇关于RAC性能和问题诊断的问题分析的文档，“Troubleshooting gc blocklost and Poor Network Performance in a RAC Environment (Doc ID 563566.1)”和“如何诊断RAC系统中的'gc cr multi block request'?(Community Discussion ID 3358223)”中指出网络指标中bad datalength等指标增长会导致RAC的性能问题。
网络拓扑：在经过对当前基础网络的调研后发现，目前私有网络的拓扑和官方推荐的配置有较大的差距。目前该数据库私有网络和业务网络共用VLAN和交换机方式，在Oracle Doc ID 563566.1文章中明确指出，业务网络和私有网络交换机的共用会导致应用性能下降、网络堵塞、global cache block loss等问题，文章中更进一步指出，RAC的业务网和私网应该使用独立的VLAN并且定义在non-routed子网。私有网络交换机应该是独立的，不应该从业务网络的接入交换机进行私网连接，如果使用了VLANs，那么每套数据的私网的VLAN应该是独立的。
通过Oracle CVU安装环境预检查工具进一步排查，发现该数据库私网的多播地址某a网段测试失败：
Oracle安装的先决条件是需要该检测两组IP均成功。经过和网络组人员了解该系统使用的xx交换机，该型号交换机如果需要开启某a网段多播地址通讯需要进行更多的配置。
3.系统参数
通过检查数据主机的参数发现两台主机的私网网卡的MTU值采用的是默认1500,该值过小会导致私网反复将需要传输的数据包拆开传输，如果连接私网的网络设备能够支持Jumbo Frames，建议开启Jumbo Frames，将MTU调大。这样可以极大提升私网网络的性能。
4.数据库相关业务分析
核心数据库曾在2018年11月18日星期日02:21，2018年12月8日星期六05:23出现LMS进程异常导致的数据库实例中断，从2018和近两次次故障时间点的共性可以看出每次出现该故障均为周末，并且都发生在夜间批处理期间，数据库业务繁忙，此时LMS进程的负载就会加重，会更容易发生该问题。
综上分析，通过宕库时的日志信息提供的线索，我们也查阅Oracle内部的大量BUG均未找到和本次故障相匹配的BUG，在发送SR请求Oracle协助分析过程中，Oracle方面也并未给出相关的BUG，所以该问题如果从BUG方向考虑则可能是由于Oracle一些未公开的BUG导致。
另一方面如果该问题并不是由于BUG导致，而是由于某些配置错误或者基础环境问题触发了Oracle的异常处理机制，进而出现ORA-00600的错误。我们通过一篇Oracle有关UDP私网传输出现坏包所产生的相关ORA-00600错误在下表可以看到。2018年的两次和近两次宕库的报错函数均有匹配，分别为：kjctr_pbmsg:badbmsg2、kjctr_pbmsg:badseq和kjbmpsch:rcvrd。
ORA-00600: internal error code, arguments: [kjbmpocr:spkey], [0], [2363548],ORA-00600: internal error code, arguments: [kjctr_rksxp:validate], [], [],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badseq], [8], [21],ORA-00600: internal error code, arguments: [corrupt_mh], [0x7FBB8B45EF08],ORA-00600: internal error code, arguments: [kjctr_rksxp: Nested receive], [],ORA-00600: internal error code, arguments: [ksxpmcpy1], [], [], [], [], [],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],ORA-00600: internal error code, arguments: [kjdrisRMnovalid:!creating_pt],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg],ORA-00600: internal error code, arguments: [kjbmpsch:rcvrd], [194], [4], [],ORA-00600: internal error code, arguments: [kjctr_rksxp:rcvr], [136], [2], |
|---|
通过我们对现场网络基础环境的排查发现了，数据库私网和业务网交换机共享，私网VLAN未做隔离，私网多播某a网段IP不通，OSW收集udp网络数据存在坏包。并且三次故障均在数据库有大量负载情况下发生，因此我们有理由认为问题极有可能是由于和网络相关的拓扑和配置未按照Oracle标准，导致私网网络数据包传出出现无法纠正错误导致。
问题解决
针对此次故障后分析后我们提出以下建议：
1)对于业务量较大的时间段，考虑停止统计信息收集、停止备份，减少数据库的压力，规避部分由于业务压力导致触发该问题的可能。
2)调整网络拓扑结构，对于xx交换机的某a网段多播关闭进行调整。
3)通过AIX: LMS Crashwith ORA-00600 [kjctr_pbmsg:badbmsg2] or ORA-29770 (Doc ID 2509185.1)文章给出的两种通过参数调整的解决方案，两个方案参数的调整需要关闭集群内所有数据库。
a.可以通过设置以下参数减少LMS数据包的大小到1500字节以下。
_lm_send_queue_batching=FALSE_lm_process_batching=FALSE_side_channel_batch_size=57 |
|---|
b.假如私网连接的网络设备支持Jumbo Frames，调整数据库私网的MTU值到9000。
