新炬运维避坑指南连载（九）

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！  

  

指南1分钟速览

• OceanBase迁移过程中影响源生产库性能

• OceanBase备份失败

• OceanBase表存在clob字段，导致查询效率极低

• Oracle lib文件权限只读导致补丁升级失败

• Oracle IPV4+IPV6双栈改造实施后存在单节点vip资源无法正常开启

• Oracle由于安全扫描程序命中bug导致数据库hang死

• OGG因NFS系统故障hang死

• kafka 部分topic分区出现leader是-1情况导致分区不可用

• Gbase版本V9.5.2存在产品缺陷

• gaussdb200数据库无法使用

某国产化项目数据迁移阶段，在OMS配置数据源，其中Oracle侧数据库属性设置为主库+备库的模式；数据迁移过程中，抽数均从主库抽取，影响Oracle主库性能，影响生产业务。

1.2 处置方法

1）抽数过程中，实时监控主库.ADG库主机网络流量波动情况，发现ADG库主机网卡流量无变化，主库主机网卡流量增涨明显；

2）检查Oracle库连接会话及执行SQL，发现大量oms服务器主机的进程在连接oracle主库；

3）经ob研发分析，OMS主备模式下，从4.0.1版本引入的主优先的模式，全量是会自动去连主库导致。后来4.1修复了，优先选择备模式。

1.3 新炬建议

2.1 现象

某国产化项目功能验证阶段，ob数据库备份失败。

2.2 处置方案

1）检查日志里有current index file is empty的报错，这个报错一般都是nfs导致的；

2）检查nfs挂载参数，发现使用的nfs是V3版本，ob使用V3版本的nfs存在Bug，会导致备份失败；

3）协调一级云资源池厂家确认，目前一级云上的不同系统分配的不同型号的文件存储，其中浪潮nas只支持V3协议，华为nas可以支持V4.0协议；

4）紧急更换该项目nas型号，从浪潮换到华为后，数据库备份验证正常。

2.3 新炬建议

3.1 现象

表存在clob字段，导致查询效率极低。

3.2 处置方案

1）执行select操作，在clob字段加了to_char，效率变快，不加to_char从业务侧看延迟在1.6秒 ，加了to_char延迟在100ms以内。

2）上传observer日志和obproxy日志提供研发。

3）在测试环境，改造带clob字段的表，将clob字段改为varchar2,to_char() clob字段就相当于将字段类型改为varchar2，执行效率迅速提高。

3.3 新炬建议

1）提前对陌生字段的表做相应测试。

4.1 现象

lib文件权限只读导致补丁升级失败。

4.2 处置方案

在应用19.20.0.1230718PSU时出现报错，lib文件libclntsh.so.19.1为只读，无法writeable，检查发现该文件是上次打PSU(19.12.0.0.210720)时候，文件权限被设置成了444，34套库68个节点都是同样的情况，修改文件权限为755后，补丁应用成功。

4.3 新炬建议

1）打补丁前，检查是否有444的lib文件存在。

5.1 现象

故障数据库环境Oracle 19.7 rac，在配置ipv4+ipv6双栈网络后。总存在一个节点vip资源无法开启，导致问题节点监听无法拉起，实例无法对外提供服务。

实施的双栈方案通过，在网络配置中添加ipv6网络资源，修改vip（先remove再重新添加v4和modify v6ip），将新的网络添加到集群。扫描scan ip,激活v4和 IPv6，集群验证状态后，再次重启集群完成配置。

日志节选：

• 停集群时显示日志：

Action for VIP aborted
Action for VIP aborted

CRS-2799: Failed to shut down resource 'ora.-01rs.vip' on '-01rs'
CRS-2799: Failed to shut down resource 'ora.scan1.vip' on '-01rs'
CRS-2794: Shutdown of Cluster Ready Services-managed resources on '-01rs' has failed
CRS-2675: Stop of 'ora.crsd' on '-01rs' failed
CRS-2678: '02rs.vip' on '-02rs' has experienced an unrecoverable failure
CRS-2799: Failed to shut down resource '02rs.vip' on '02rs'
CRS-2794: Shutdown of Cluster Ready Services-managed resources on '02rs' has failed
CRS-2675: Stop of 'ora.crsd' on '02rs' failed
CRS-4704: Shutdown of Clusterware failed on node -01rs.
CRS-4704: Shutdown of Clusterware failed on node -02rs.
CRS-4000: Command Stop failed, or completed with errors.

• 查看日志有类似如下报错alert日志：

2023-10-27 16:01:05.530 [CRSD(968678)]CRS-2769: Unable to failover resource 'ora.net2.network'.
2023-10-27 16:01:05.532 [CRSD(968678)]CRS-2769: Unable to failover resource 'ora.net1.network'.
2023-10-27 16:01:06.257 [CRSD(968678)]CRS-2769: Unable to failover resource 'ora.net1.network'.
2023-10-27 16:01:06.258 [CRSD(968678)]CRS-2769: Unable to failover resource 'ora.net2.network'.
2023-10-27 16:03:05.087 [ORAROOTAGENT(1089558)]CRS-5818: Aborted command 'check' for resource 'ora.scan1.vip'. Details at (:CRSAGF00113:) {0:8:2} in crsd_orarootagent_root.trc.
2023-10-27 16:03:05.087 [ORAROOTAGENT(1089558)]CRS-5818: Aborted command 'check' for resource 'ora.01rs.vip'. Details at (:CRSAGF00113:) {0:8:2} in crsd_orarootagent_root.trc.
2023-10-27 16:04:17.863 [ORAROOTAGENT(1093468)]CRS-8500: Oracle Clusterware ORAROOTAGENT process is starting with operating system process ID 1093468
2023-10-27 16:06:17.972 [ORAROOTAGENT(1093468)]CRS-5818: Aborted command 'check' for resource 'ora.-01rs.vip'. Details at (:CRSAGF00113:) {0:9:2} in crsd_orarootagent_root.trc.

• 后来手动拉监听时alert日志报错：

Failed to check 2:0203 on bond0.2112
CRS-5005: IP Address: 2:0203 is already in use in the network
2023-11-03 10:51:09.962 :CLSDYNAM:3052320512: [ora.01rs.vip]{1:31596:55665} [start] ActiveAddr::publishSV6 IP address start/stop Exception: CRS-5005: IP Address: 2:0203 is already in use in the network

• 最早在crsd_orarootagent_root_2.trc日志中对应停集群时就有对应的bug日志：

2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.02rs.vip]{2:40767:13339} [stop] Deleting ipv6 address '2204', on the interface name 'bond0.2112'
2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.02rs.vip]{2:40767:13339} [stop] sclsideladdrsv6 returned
2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.02rs.vip]{2:40767:13339} [stop] Failed to delete 2204 on bond0.2112
2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.-2rs.vip]{2:40767:13339} [stop] (null) category: -2, operation: ioctl, loc: SIOCDIFADDR, OS error: 99, other: failed to delete address
2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.02rs.vip]{2:40767:13339} [stop] VipActions::stopIpV6 }
2023-10-27 15:56:53.007 :CLSDYNAM:229943040: [ora.02rs.vip]{2:40767:13339} [stop] VipActions::stopIpV6 {

5.2 处置方案

在重启集群时发生故障，停集群执行时间明显比正常时间长，集群无法正常关闭。报Action for VIP aborted， CRS-2799: Failed to shut down resource 错误。查看alert日志有CRS-5818，CRS-2769报错。

使用-f强制关闭集群后重启集群出现现象----总存在一个节点vip无法正常开启，节点监听offline。

尝试手动拉起监听报CRS-5005: IP Address: 2409 is already in use in the network错误（vip）。

怀疑网络被占用，但再次重启集群节点故障状态可切换，原故障节点正常，原正常节点报相同故障。

查找相关资料，怀疑版本bug，联系原厂收集信息后确定为版本bug_32128969发生在modify ipv4 to ipv6之后，不能停止vip资源。官方回复在19.11以及之后版本修复。报错关键日志Failed to delete ipv6-vip on bond0.2112。

5.3 新炬建议

6.1 现象

某核心库因安全扫描程序查询大量系统视图命中oracle 11g BUG，导致核心生产库直接hang死，严重影响系统业务。

6.2 处置过程

某核心生产数据库出现大量enq：SQ-contention.latch：sharedpool和rowcachelock，随着数据库活动会话的异常积压，导致核心库实例Hang，应用程序无法正常连接。现场DBA查杀会话后，数据库恢复正常。

1）从monilock日志初步分析，扫描程序用户通过JDBC程序在凌晨2点发起，在2点前发生少量rowcache objects的等待事件，在2点后此类等待事件增多。分析等待事件相关SQL发现这个扫描程序的逻辑是对数据库所有表进行全字段的抽样查询rownum<=1000，这类任务扫描大量的对象导致share pool负载增加，数据库的shared pool正在purge大量的rowcache objects 从而引发latch:shared pool争用问题，最后导致前台活动会话阻塞。

2）实例1在2:24出现ORA-600 kkmendsel-pin报错，触发ORA-600报错,核查SQL是扫描程序用户正在查询业务视图，该视图的LAST_DDL_TIME是报错发生时间点。与MOS 文档(Doc ID 2491737.1)中的版本和症状描述基本一致，确定是命中Bug 18199537 RAC database becomes almost hung when large amount of row cache are used in shared pool导致的。

6.3 新炬建议

7.1 现象

某OGG同步kafka因NFS文件系统通信故障，导致OGG进程hang死，数据同步延迟。

7.2 处置过程

1）某日晚23点时收到源端OGG的投递进程异常告警，核查错误日志出现TCP：73错误，重启无法解决，将投递进程做了etrollover操作后进程恢复正常。

2）次日下午15点左右，接业务侧反馈kafka未收到同步数据，当及核查目标端OGG同步情况，发现所有涉及到该库的复制进程延迟近16小时。排查源端OGG进程状态正常，核查目标端日志有timeout信息但无error现象，准备重启复制经常，发现进程无法正常停止，force stop也无法停止，进一步分析发现操作系统上涉及到B库的OGG复制进程状态全为Ds状态，疑似IO问题导致进程夯死，最后只能通过重启主机释放进程。

3）重启主机后，该库的复制进程状态仍为running转态，延迟持续增长，且操作系统上没有该库的复制进程。由于紧急恢复业务需要，只能重配所有复制进程，重新配置后从当日凌晨跳过的trail文件开始应用，数据逐渐追平，业务恢复。

7.3 新炬建议

1）禁止OGG软件目录部署在NFS文件系统上；

2）做好OGG进程源端和目标端监控；

8.1 现象

kafka 部分topic分区出现leader 是-1情况导致分区不可用。

8.2 处置方法

1）kafka集群业务出现部分分区无法写入情况，检查集群状态发现部分topic的分区leader 是-1，也即没有任何分区ID的情况。

2）先尝试使用kafka-reassign-partitions命令，编写topic的json，将此分区恢复，发现修复失败。

3）于是尝试从zk底层进行修复，先get brokers/topics/{topic名字}/partitions/{分区id}/state 查看异常分区信息{"controller_epoch":241,"leader": -1 "version":1,"leader_epoch":3,"isr":[]}。

4）再修改信息，将-1改为broker的id，同时将isr同步信息也修改为此broker，其余不变并set进去。

set /brokers/topics/{topic名字}/partitions/{分区id}/state {"controller_epoch":241,"leader":92,"version":1,"leader_epoch":3,"isr":[92]}

5）再次检查发现topic分区leader变为92号broker，问题修复。

8.3 新炬建议

1）从根本解决就是增加每个topic的副本数，修改为2或3副本，避免单副本时，一旦损坏一个数据盘就导致数据丢失和分区不可用情况；

9.1 现象

通过gcadmin和服务状态监控数据库出现一致性状态异常的告警，并且在运行过程中出现了连续的多个数据节点Gbased服务宕机重启事件，导致部分数据节点间数据不同步，进而出现数据库不能自动修复的event事件，正常情况下event事件数据库会自动修复。

与业务沟通了解在超过10亿行数据表频繁进行写入的情况下易出现gbased服务宕掉的情况，且部分情况下业务的写入中断。

9.2 处置过程

1）出现event事件不能自动修复，出于安全性考虑未直接对各节点表进行修复，而是采用手动对触发表进行重建并将原表数据进行转移，之后删除原表的方式处理，event事件消失。

2）对于Gbased服务宕机重启，升级数据库版本，观察至今未出现相同类似的情况。

9.3 新炬建议

10.1 现象

gaussdb200数据库整个集群不可用，告警出现standby promoting，disk damaged，standby need repair。

分析发现是由于一个节点磁盘损坏，在硬盘更换过程数据重平衡重启后整个集群不可用。

10.2 处置过程

1）通过查看集群节点状态发现集群状态不可用，DataNode27节点上所有实例异常，DataNode26节点上的6379实例处于standby promoting状态。

2）查看DataNode27节点上实例的日志发现报could not read directory No data available,进一步分析发现DataNode27节点上2个数据目录不能读写，主机命令ls查看这2个数据目录都报错IO错误。

3）为了提高在单节点停掉下的集群性能，将synchronous_commit参数的值修改成off。

4）此时集群依旧不可用，通过分析确认是DataNode26节点上的6379实例无法切主导致，查看DataNode26节点上的6379实例日志发现报can not accept connection in promoting standby mode错误。

5）通过分析是由于主库的max_wal_senders设置过小，主备wal_sender槽位满导致无法正常建立联系导致。通过将max_wal_senders从4设置成8后，kill第三备库DataNode22节点3191实例的pid重启之后，DataNode26节点上的6379实例恢复正常。此时集群状态从Unavailable(不可用)变成Degraded(降级)，业务恢复正常。

6）确认DataNode27节点所有数据目录可读写后，拉起DataNode27节点上所有实例，除6397实例处于standby need repair状态外，其他所有实例均同步完成恢复正常。

后分析6397实例处于standby need repair是由于缺失pg_csnlog导致，而后集群自动同步该部分缺失日志，整个集群恢复正常。

10.3 新炬建议

增加数据库巡检和告警内容，针对硬盘状态和目录读写状态进行监控，及时发现异常可以减少故障时间和业务受影响时间。

END