点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
指南1分钟速览：
-
oracle大量“cursor: pin S wait on X”等待事件导致数据库DBTIME较高
-
oracle数据库出现ORA-04031报错，节点实例down，业务登录数据库失败
-
oracle软件安装目录使用率异常增长
-
oracle大量异常等待分析
-
磐维集群节点状态unkown报错处理
-
磐维2.0数据库安装问题
-
Weblogic大版本升级后，应用部署失败问题
-
weblogic中间件的应用系统,数据库相关方法调用失败
-
Oceanbase OAT 报密码验证失败问题分析
-
Oceanbase oms增量迁移延迟处理
一
oracle大量“cursor: pin S wait on X”等待事件导致数据库DBTIME较高
1.1 现象巡检发现大量“cursor: pin S wait on X”等待事件且数据库该时间端DBTIME高。1.2 处置过程1）巡检发现大量“cursor: pin S wait on X”等待事件2）awr报告发现此时段dbtime极高3）查询此等待事件均由sys发起，会话状态均为active4）采集其中一个等待事件的spid，通过oradebug开启10046事件跟踪此进程生成trace日志5）解读trace日志发现产生此等待事件的sql来至同节点上的uat实例，为克隆的uat测试环境，此克隆环境已经hang死6）kill等待事件的sid，停止克隆进程，删除克隆环境重新发起克隆，问题解决1.3 新炬建议1）使用Oracle的自动工作负载仓库（AWR）和自动数据库诊断监视器（ADDM）等工具来定期分析数据库性能，并根据报告进行优化2）定期评估数据库设计，特别是锁定策略和并发控制机制，确保符合当前的业务需求3）管理和监控测试环境的运行状态，确保测试操作不会对生产环境产生负面影响
4）窗口期执行的任务需要闭环
后期检查，无问题才能申报作业结束。
二
oracle数据库出现ORA-04031报错，节点实例down，业务登录数据库失败
2.1 现象业务侧反馈数据库无法访问，数据库告警日志大量ORA-04031报错。2.2 处置过程1）收到业务反馈，数据库无法访问2）用管理员无法登录到数据库4节点，3节点登录出现卡顿，无法正常执行操作命令3）检查alert日志，发现大量ORA-04031，无法分配40字节share memory；同时，发现大量等待事件“library cache lock”4）多次手动刷新share pool，数据库还是处于卡死状态5）手动将数据库服务切换到备用的两个节点，发现备用两节点陆续被卡死6）重启异常的两个节点实例，同时通知业务停止业务连接，不要同时启动所有应用节点，陆续开启应用并发，最终陆续启动完所有应用节点，数据库恢复正常；业务恢复正常7）此次停机故障最终定位为业务量并发突增导致2.3 新炬建议1）使用 Oracle 的自动工作负载仓库（AWR）报告和统计视图来分析内存使用情况和等待事件2）利用 Oracle 的 V$LIBRARYCACHE 和 V$SGASTAT 视图来监控共享池的使用情况，特别是在高负载时期3）审查并优化 SQL 语句和应用程序代码，减少对共享内存的需求，特别是那些频繁解析和执行的 SQL 语句4）实施 SQL 绑定变量来减少硬解析的次数，可以显著减少共享池的使用
5）实施更精细的并发控制机制，如数据库连接池，以避免业务并发突增直接影响数据库性能
三
oracle软件安装目录使用率异常增长
3.1 现象oracle软件安装目录突然告警文件系统使用率大于85%，使用率86%，该目录使用率增长很快，该目录大小500G。3.2 处置过程1）检查发现oracle日志目录diag大约占用370G空间，其中diag目录下子目录cdump占用空间330G2）排查oracle的alert_$ORACLE_SID.log日志文件发现大量报错（ORA-07445:[pevm_icd_call_common()+225] [SIGSEGV] [ADDR:0x0] [PC:0x1289FAA1] [SI_KERNEL(general_protection)] []），一直输出大量trace3）分析相关trace日志，确定MMON_SLAVE 进程执行Automatic Report Flush导致了ORA-07445，并且在cdump目录下打印大量core文件4）查询ORA-07445相关Bug确定符合该bug（ORA-07445: [pevm_icd_call_common()] Generating Core Files in 19c (Doc ID 2743772.1) Bug 31932633 - W2K12:GIDBRU/ORA 7445 [PEVM_ICD_CALL_COMMON]+262）5）动态修改以下隐藏参数，禁用“自动报告刷新”
alter system set "_report_capture_cycle_time"=0; /* Default is 60 seconds */
修改该参数没有影响，因为它仅禁用12c中引入的自动报告捕获功能。它没有禁用原来的SQL监控框架。SQL监控可以正常使用。6）修改参数后，日志中ORA-07445报错消失，不再打印trace文件和core文件，手动清理diag目录下的子目录cdump，释放大约320G空间3.3 新炬建议1）增加对Oracle诊断目录大小的监控，设置合理的阈值，以便在异常增长时及时发出警告2）对于频繁出现的错误和core dump生成，设置特定的监控和报警逻辑，以便快速响应3）实施日志轮转和自动清理策略，定期清理旧的trace文件和core dump文件，保持文件系统的健康状态4）协调与Oracle支持的沟通，跟进BUG修复的补丁和版本更新，确保在后续的数据库维护中应用5）定期检查Oracle支持网站关于已知问题的更新，以便及时获取修复信息
6）定期进行基础设施审计，评估存储使用效率和性能状况，必要时进行硬件扩展或升级
四
oracle大量异常等待分析
4.1 现象数据库突现大量的latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件影响业务。4.2 处置过程数据库突现大量的latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件影响业务，产生等待事件的语句都是insert同一个表。与业务侧确认，近期应用程序有调整，入库数据新增较多，业务优先调整入库数据量，等待事件消失，问题暂时恢复。事后分析，产生大量latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件的session 在执行sql id 83yyz41uvtkt1，插入表FLOW_HIS_202403。显示在index IDX1_FLOW202403 上有高的buffer busy wait的竞争。分析Latch Miss Sources：
- Latch 丢失源主要为（ges resource hash list kjlrlr: remove lock from resource queue 0 1,660,441 1,609,680、ges resource hash list kjrmas1: lookup master node 0 184,690 394、ges resource hash list kjakcai: search for resp by resname 0 19,125 130）
查到确定符合该Bug。（Bug 29780459 High Waits On "latch :ges resource hash list" After Upgrading to 18c or Above）本次故障因为业务高并发insert，进而触发bug，产生异常等待营销业务。原厂建议升级数据库到RU 19.17或以上修复bug。4.3 新炬建议1）人工介入分析大量等待事件出现，没有短时间恢复造成入库数据积压影响业务。警示数据库运维人员遇到大量等待事件没有恢复，应及时人工介入分析处理。2）及时与业务沟通确定业务是否有变动，共同定位问题、解决问题。3）加强对关键资源的监控如CPU、内存、I/O和重要的等待事件，定期检查AWR报告和Active Session History (ASH)数据，分析和识别性能瓷瓶颈。4）定期进行故障模拟演练包括模拟高并发场景，确保系统的稳定性和可靠性。
5）增强团队对异常等待事件的响应能力，制定明确的故障处理流程
五
磐维集群节点状态unkown报错处理
5.1 现象查询集群节点状态为unkown。5.2 处置过程1）检查磐维数据库发现集群节点为unkown状态。2）进一步检查数据库参数配置发现audit_xid_info为开启状态，表示当前磐维数据开了事务ID审计记录功能。3）报错原因由于开启了事务ID审计audit_xid_info参数，当cm获取dn节点状态时，无法获取dn节点状态，从而会导致集群节点状态异常。4）报错处理关闭事务ID审计参数：
gs_guc reload -N all -I all -c "audit_xid_info=0"
5）cm_ctl query -Cvidid 查看集群及节点状态恢复正常“cluster_state: Normal”5.3 新炬建议1）在开启数据库的某些功能之前，需要仔细评估其对系统整体性能和运行状态的影响对于诸如事务ID审计这样的功能，需要考虑其对集群状态检测等功能的影响。2）确保在对数据库进行配置更改时，有清晰的文档记录和变更管理流程
3）定期跟踪数据库厂商发布的更新和最佳实践，并在必要时更新系统以确保安全和稳定性
六
磐维2.0数据库安装问题
6.1 现象问题1：磐维2.0数据库安装报错：
'utf-8' codec can't decode byte 0xbb in position 913: invalid start byte
问题2：磐维2.0双中心搭建时，从中心启动时报错：
Exception: [GUASS-51632]: Failed to copy secure file dir
报错从中心主节点无法连接主中心各备节点，实际网络、端口均是通的，且能远程连接主中心。6.2 处置过程问题1解决方法：1）通过检查日志发现是安装时内部执行py脚本报错字符乱码2）修改当前安装用户系统环境变量，在/home/omn/.bashrc中添加"export LANG=zh_CN.gbk"，即调整系统字符集为gbk格式后再安装问题2解决方法：1）修改gs_sdr工具py脚本
- which gs_sdr，找到gs_sdr工具所在路径；
- 进入gs_sdr所在路径；
- 继续进入impl/streaming_disaster_recovery路径，找到streaming_base.py这个脚本；
- 搜索__copy_secure_dir_from_dn_dir这个函数，删除该函数中"| unset LD_LIBRARY_PATH &&"这部分；
- more streaming_base.py|grep "| unset LD_LIBRARY_PATH &&"，找到脚本中匹配的4处"| unset LD_LIBRARY_PATH &&"，将该内容移到命令最前面。
2）磐维原厂研发针对该问题会临时出一个patch补丁，且下个大版本该问题会修复6.3 新炬建议1）在安装之前，建议确认系统的字符集编码，并确保所有相关环境都采用相同的字符集编码这可以减少由于字符集不一致导致的问题。2）在安装过程中，可提前设置好必要的环境变量，以确保安装程序能够正确识别和处理字符集这可以通过修改安装脚本或在安装之前设置系统环境变量来实现。3）在遇到类似问题时，建议详细记录问题现象、解决方法和改进建议，并及时向厂商报告问题这有助于厂商了解用户的需求和反馈，并提供更好的支持和服务。
4）保持系统和相关工具的更新和维护，以确保可以及时获取到厂商提供的补丁和修复程序
这可以帮助解决一些已知的问题，并提高系统的稳定性和安全性。
七
Weblogic大版本升级后，应用部署失败问题
7.1 现象某系统Weblogic大版本升级，从weblogic10.3.6.0+jdk1.6升级到weblogic12.2.1.4+jdk1.8，应用部署异常，启动失败。7.2 处置过程首先，协调应用侧开发人员核查确认应用工程代码是否与原生产环境一致；开启weblogic 日志的dubug模式，从日志中看报错的方法类均与org.glassfish.jersey*相关，系jersey2.X版本，而现场应用工程使用的是jersey1.X版本，对应类方法类为com.sun.jersey*。经分析，发现Weblogic优先加载了Weblogic12.2.1.4安装目录下的org.glassfish.jersey*相关方法类（jersey2.X版本），导致应用工程启动异常。注：Weblogic12.2.1.4内置了jersey2.X版本包，而Weblogic12.1.3/11g内置的是jersey1.X版本包。解决方法：通过修改应用工程WEB-INF文件夹下的配置文件web.xml与weblogic.xml：
- 将应用工程包内Jersey设置为优先加载；
- 再将Weblogic中自动发现Jersey功能关闭。
7.3 新炬建议1）大版本升级前，应充分了解相关版本升级注意事项2）全面掌握新版本相比老版本新增，优化，升级，删除等调整了哪些内容3）同步告知开发人员，做相关适配改造
4）在遇到部署失败的情况时，建议开启详细的日志记录，包括调试模式，以便更好地分析和定位问题
通过查看日志，可以更快地发现问题所在，并采取相应的解决方案。
八
weblogic中间件的应用系统,数据库相关方法调用失败
8.1 现象业务侧反馈数据库相关方法调用失败，数据库侧同事核查并反馈当前库并无异常，但在此之前的某个时间数据库有重启操作（测试环境国产数据库，时常做优化、配置修改，会涉及库重启生效。）8.2 处置过程从日志看是应用从JDBC连接池取到的连接都是已关闭连接。经核查weblogic数据源连接池配置，发现该数据源未勾选“保留时测试连接”选项。
注：该选项，需要如下两个参数配合：
- 测试频率（比如：120s）；
- 测试表名称（比如：SQL SELECT 1 FROM DUAL）。
“保留时测试连接”选项：
- 作用是使Weblogic 将连接池中的连接提供给客户端使用之前，对该连接进行有效性测试，无效的连接将被关闭，并重新创建。因此，当连接池未开启“保留时测试连接”选项，并且数据库在此之前有重启的情况下，就可能导致连接池中的连接失效，从而影响业务调用。
反馈业务侧，修改JDBC连接池相关配置，问题解决：
- 勾选“保留时测试连接”选项；
- 配置“测试频率”（比如：120s）；
- 填写“测试表名称”（比如：SQL SELECT 1 FROM DUAL）。
8.3 新炬建议1）Weblogic数据源的“保留时测试连接”选项默认都是关闭状态，应该在创建JDBC连接池时直接勾选/开启该选项2）BES中间件数据源配置默认会开启“获取连接池验证”选项，保证连接有效性，“连接空闲时验证”选项默认是禁用，该选项是主动探测池中连接，主动保证池中连接为有效连接，应该主动开启该选项3）在修改配置或者应用程序代码时，确保使用版本控制系统进行管理，并及时更新相关的文档记录
这样可以方便团队成员了解配置变更的内容，并及时回滚到之前的状态。
九
Oceanbase OAT 报密码验证失败问题分析
9.1 现象因生产环境OCP密码不符合客户安全管理规范，在更新密码后,部署新机器时OAT 报密码验证失败，无法通过OAT进行主机初始化推送。9.2 处置过程1）登录OAT 容器
docker exec -it oms bash
2）查看 OAT 密码配置文件的密码信息，确认密码是否与当前新密码一致（如不需要加密密文可改为明文）
cd /oat/task_engine/plugins/
cat shared_conf.py| grep "OCP_PASS"
3）修改密码配置文件4）重启服务
supervisorctl restart all
9.3 新炬建议1）配置管理工具使用如 Ansible、Chef 或 Puppet 等配置管理工具，可以帮助自动化配置文件的更新和部署，确保所有相关的组件都使用最新的配置。2）密钥和密码管理考虑使用密钥管理系统，如 HashiCorp Vault、AWS Secrets Manager 等，统一管理密码和密钥。这样，只需在一个地方更新密码，相关系统和工具可以自动获取最新的凭证。3）详细的日志记录确保所有的认证失败事件都能被详细记录，包括时间、操作者和所涉及的服务等。这有助于快速定位问题和进行后续的安全审计。4）实时监控和警报实施实时监控系统，对认证失败事件设置警报。一旦出现异常情况，相关人员可以立即得到通知并采取行动。5）定期审计定期进行安全审计，检查系统和应用的配置是否符合最新的安全政策和规范。6）渗透测试
定期进行渗透测试，模拟攻击者的行为来测试系统的安全性，特别是对敏感操作如密码更改和系统访问权限等。
十
Oceanbase oms增量迁移延迟处理
10.1 现象生产环境割接时，通过oms数据迁移mysql到obmysql,业务停止服务后，增量延迟一直增长无法正常进行正向切换，按照 Oracle 割接经验切换日志无效果。10.2 处置过程1）检查数据库是否还有连接在
select * from information_scheam.processlsit;
2）切换日志
SHOW MASTER STATUS;
FLUSH LOGS;
3）创建临时表，写入临时数据
create table test as select table_name,table_schema,rows
from information_schema.tables;
4）如延迟未达到切换标准，重复 2、3 操作
FLUSH LOGS;
create table test2 as select table_name,table_schema,rows from information_schema.tables;
10.3 新炬建议1）限制大量的写入操作在割接过程中，尽量避免执行大批量的写入操作，如 create table as select 可能会产生大量日志，增加迁移过程的复杂度和延迟。2）逐步迁移数据采用逐步迁移策略，先迁移非业务关键数据，逐渐过渡到关键数据，以此来分散风险。3）确保迁移过程中的每一步都有详尽的监控和日志记录以便于在出现问题时可以快速定位和解决。4）使用性能监控工具监控数据库的性能指标如延迟、IOPS和吞吐量，确保在整个迁移过程中性能指标符合预期。
新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
END
本文作者：秘而不宣(上海新炬中北团队）
本文来源：“IT那活儿”公众号
