点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
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较高
巡检发现大量“cursor: pin S wait on X”等待事件且数据库该时间端DBTIME高。1）巡检发现大量“cursor: pin S wait on X”等待事件3）查询此等待事件均由sys发起，会话状态均为active4）采集其中一个等待事件的spid，通过oradebug开启10046事件跟踪此进程生成trace日志5）解读trace日志发现产生此等待事件的sql来至同节点上的uat实例，为克隆的uat测试环境，此克隆环境已经hang死6）kill等待事件的sid，停止克隆进程，删除克隆环境重新发起克隆，问题解决1）使用Oracle的自动工作负载仓库（AWR）和自动数据库诊断监视器（ADDM）等工具来定期分析数据库性能，并根据报告进行优化2）定期评估数据库设计，特别是锁定策略和并发控制机制，确保符合当前的业务需求3）管理和监控测试环境的运行状态，确保测试操作不会对生产环境产生负面影响4）窗口期执行的任务需要闭环
后期检查，无问题才能申报作业结束。
oracle数据库出现ORA-04031报错，节点实例down，业务登录数据库失败
业务侧反馈数据库无法访问，数据库告警日志大量ORA-04031报错。2）用管理员无法登录到数据库4节点，3节点登录出现卡顿，无法正常执行操作命令3）检查alert日志，发现大量ORA-04031，无法分配40字节share memory；同时，发现大量等待事件“library cache lock”4）多次手动刷新share pool，数据库还是处于卡死状态5）手动将数据库服务切换到备用的两个节点，发现备用两节点陆续被卡死6）重启异常的两个节点实例，同时通知业务停止业务连接，不要同时启动所有应用节点，陆续开启应用并发，最终陆续启动完所有应用节点，数据库恢复正常；业务恢复正常1）使用 Oracle 的自动工作负载仓库（AWR）报告和统计视图来分析内存使用情况和等待事件2）利用 Oracle 的 V$LIBRARYCACHE 和 V$SGASTAT 视图来监控共享池的使用情况，特别是在高负载时期3）审查并优化 SQL 语句和应用程序代码，减少对共享内存的需求，特别是那些频繁解析和执行的 SQL 语句4）实施 SQL 绑定变量来减少硬解析的次数，可以显著减少共享池的使用5）实施更精细的并发控制机制，如数据库连接池，以避免业务并发突增直接影响数据库性能
oracle软件安装目录突然告警文件系统使用率大于85%，使用率86%，该目录使用率增长很快，该目录大小500G。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文件确定符合该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）alter system set "_report_capture_cycle_time"=0; /* Default is 60 seconds */
修改该参数没有影响，因为它仅禁用12c中引入的自动报告捕获功能。它没有禁用原来的SQL监控框架。SQL监控可以正常使用。6）修改参数后，日志中ORA-07445报错消失，不再打印trace文件和core文件，手动清理diag目录下的子目录cdump，释放大约320G空间1）增加对Oracle诊断目录大小的监控，设置合理的阈值，以便在异常增长时及时发出警告2）对于频繁出现的错误和core dump生成，设置特定的监控和报警逻辑，以便快速响应3）实施日志轮转和自动清理策略，定期清理旧的trace文件和core dump文件，保持文件系统的健康状态4）协调与Oracle支持的沟通，跟进BUG修复的补丁和版本更新，确保在后续的数据库维护中应用5）定期检查Oracle支持网站关于已知问题的更新，以便及时获取修复信息6）定期进行基础设施审计，评估存储使用效率和性能状况，必要时进行硬件扩展或升级
数据库突现大量的latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件影响业务。数据库突现大量的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 丢失源主要为（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。大量等待事件出现，没有短时间恢复造成入库数据积压影响业务。警示数据库运维人员遇到大量等待事件没有恢复，应及时人工介入分析处理。如CPU、内存、I/O和重要的等待事件，定期检查AWR报告和Active Session History (ASH)数据，分析和识别性能瓷瓶颈。5）增强团队对异常等待事件的响应能力，制定明确的故障处理流程
发现audit_xid_info为开启状态，表示当前磐维数据开了事务ID审计记录功能。由于开启了事务ID审计audit_xid_info参数，当cm获取dn节点状态时，无法获取dn节点状态，从而会导致集群节点状态异常。gs_guc reload -N all -I all -c "audit_xid_info=0"
5）cm_ctl query -Cvidid 查看集群及节点状态恢复正常“cluster_state: Normal”1）在开启数据库的某些功能之前，需要仔细评估其对系统整体性能和运行状态的影响对于诸如事务ID审计这样的功能，需要考虑其对集群状态检测等功能的影响。2）确保在对数据库进行配置更改时，有清晰的文档记录和变更管理流程3）定期跟踪数据库厂商发布的更新和最佳实践，并在必要时更新系统以确保安全和稳定性
'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
报错从中心主节点无法连接主中心各备节点，实际网络、端口均是通的，且能远程连接主中心。1）通过检查日志发现是安装时内部执行py脚本报错字符乱码2）修改当前安装用户系统环境变量，在/home/omn/.bashrc中添加"export LANG=zh_CN.gbk"，即调整系统字符集为gbk格式后再安装- which 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补丁，且下个大版本该问题会修复1）在安装之前，建议确认系统的字符集编码，并确保所有相关环境都采用相同的字符集编码2）在安装过程中，可提前设置好必要的环境变量，以确保安装程序能够正确识别和处理字符集这可以通过修改安装脚本或在安装之前设置系统环境变量来实现。3）在遇到类似问题时，建议详细记录问题现象、解决方法和改进建议，并及时向厂商报告问题这有助于厂商了解用户的需求和反馈，并提供更好的支持和服务。4）保持系统和相关工具的更新和维护，以确保可以及时获取到厂商提供的补丁和修复程序
这可以帮助解决一些已知的问题，并提高系统的稳定性和安全性。
某系统Weblogic大版本升级，从weblogic10.3.6.0+jdk1.6升级到weblogic12.2.1.4+jdk1.8，应用部署异常，启动失败。首先，协调应用侧开发人员核查确认应用工程代码是否与原生产环境一致；开启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：- 再将Weblogic中自动发现Jersey功能关闭。
2）全面掌握新版本相比老版本新增，优化，升级，删除等调整了哪些内容4）在遇到部署失败的情况时，建议开启详细的日志记录，包括调试模式，以便更好地分析和定位问题
通过查看日志，可以更快地发现问题所在，并采取相应的解决方案。
weblogic中间件的应用系统,数据库相关方法调用失败
业务侧反馈数据库相关方法调用失败，数据库侧同事核查并反馈当前库并无异常，但在此之前的某个时间数据库有重启操作（测试环境国产数据库，时常做优化、配置修改，会涉及库重启生效。）从日志看是应用从JDBC连接池取到的连接都是已关闭连接。经核查weblogic数据源连接池配置，发现该数据源未勾选“保留时测试连接”选项。注：该选项，需要如下两个参数配合：
- 测试表名称（比如：SQL SELECT 1 FROM DUAL）。
- 作用是使Weblogic 将连接池中的连接提供给客户端使用之前，对该连接进行有效性测试，无效的连接将被关闭，并重新创建。因此，当连接池未开启“保留时测试连接”选项，并且数据库在此之前有重启的情况下，就可能导致连接池中的连接失效，从而影响业务调用。
反馈业务侧，修改JDBC连接池相关配置，问题解决：- 填写“测试表名称”（比如：SQL SELECT 1 FROM DUAL）。
1）Weblogic数据源的“保留时测试连接”选项默认都是关闭状态，应该在创建JDBC连接池时直接勾选/开启该选项2）BES中间件数据源配置默认会开启“获取连接池验证”选项，保证连接有效性，“连接空闲时验证”选项默认是禁用，该选项是主动探测池中连接，主动保证池中连接为有效连接，应该主动开启该选项3）在修改配置或者应用程序代码时，确保使用版本控制系统进行管理，并及时更新相关的文档记录这样可以方便团队成员了解配置变更的内容，并及时回滚到之前的状态。
Oceanbase OAT 报密码验证失败问题分析
因生产环境OCP密码不符合客户安全管理规范，在更新密码后,部署新机器时OAT 报密码验证失败，无法通过OAT进行主机初始化推送。2）查看 OAT 密码配置文件的密码信息，确认密码是否与当前新密码一致（如不需要加密密文可改为明文）cd /oat/task_engine/plugins/
cat shared_conf.py| grep "OCP_PASS"
supervisorctl restart all
使用如 Ansible、Chef 或 Puppet 等配置管理工具，可以帮助自动化配置文件的更新和部署，确保所有相关的组件都使用最新的配置。考虑使用密钥管理系统，如 HashiCorp Vault、AWS Secrets Manager 等，统一管理密码和密钥。这样，只需在一个地方更新密码，相关系统和工具可以自动获取最新的凭证。确保所有的认证失败事件都能被详细记录，包括时间、操作者和所涉及的服务等。这有助于快速定位问题和进行后续的安全审计。实施实时监控系统，对认证失败事件设置警报。一旦出现异常情况，相关人员可以立即得到通知并采取行动。定期进行安全审计，检查系统和应用的配置是否符合最新的安全政策和规范。定期进行渗透测试，模拟攻击者的行为来测试系统的安全性，特别是对敏感操作如密码更改和系统访问权限等。
生产环境割接时，通过oms数据迁移mysql到obmysql,业务停止服务后，增量延迟一直增长无法正常进行正向切换，按照 Oracle 割接经验切换日志无效果。select * from information_scheam.processlsit;
SHOW MASTER STATUS;
FLUSH LOGS;
create table test as select table_name,table_schema,rows
from information_schema.tables;
FLUSH LOGS;
create table test2 as select table_name,table_schema,rows from information_schema.tables;
在割接过程中，尽量避免执行大批量的写入操作，如 create table as select 可能会产生大量日志，增加迁移过程的复杂度和延迟。采用逐步迁移策略，先迁移非业务关键数据，逐渐过渡到关键数据，以此来分散风险。3）确保迁移过程中的每一步都有详尽的监控和日志记录如延迟、IOPS和吞吐量，确保在整个迁移过程中性能指标符合预期。新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
