点击上方“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数据库无法使用
一
OceanBase迁移过程中影响源生产库性能
1.1 现象
某国产化项目数据迁移阶段，在OMS配置数据源，其中Oracle侧数据库属性设置为主库+备库的模式；数据迁移过程中，抽数均从主库抽取，影响Oracle主库性能，影响生产业务。
1.2 处置方法
1）抽数过程中，实时监控主库.ADG库主机网络流量波动情况，发现ADG库主机网卡流量无变化，主库主机网卡流量增涨明显；
2）检查Oracle库连接会话及执行SQL，发现大量oms服务器主机的进程在连接oracle主库；
3）经ob研发分析，OMS主备模式下，从4.0.1版本引入的主优先的模式，全量是会自动去连主库导致。后来4.1修复了，优先选择备模式。
1.3 新炬建议
迁移过程中要多角度全方位对Oracle数据库及主机进行监控，避免产生影响。二
OceanBase备份失败
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 新炬建议
目前OceanBase数据库国产化项目很多都部署在集团一级云资源池环境中，一级云资源配置复杂，使用时需要进行完整的验证测试。三
OceanBase表存在clob字段，导致查询效率极低
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）提前对陌生字段的表做相应测试。
2）对查询时间差别大的sql要引起重视。四
Oracle lib文件权限只读导致补丁升级失败
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文件存在。
2）打完补丁后，检查是否有只读权限的lib文件。五
Oracle IPV4+IPV6双栈改造实施后，单节点vip资源无法正常开启
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 新炬建议
在实施此方案时一定要注意数据库版本信息，对于数据库版本低的不适用。六
Oracle由于安全扫描程序命中bug导致数据库hang死
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
