点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！某核心业务系统数据库突然无法登陆，Observer core退出，业务SQL导致系统CPU耗尽，临时绑定outputline，最终通过补丁升级解决。
2. 处置方法
原因定位某SQL(select * from dual)异常，修改proxy固定路由参数proxy_primary_zone_name指向新主zone，默认主zone为zone3，并重启proxy，修改后业务立即恢复。oceanbase数据库相关机制不太完美，在OBProxy1.8.7版本中，主zone故障h后无法在第一时间内自动切换到正常zone。但从OBProxy3.2.6版本开始，引入了新的参数enable_primary_zone，默认为true，需要将proxy_primary_zone_name以及proxy_idc_name设置为空，在上线前的高可用测试过程中经过多轮验证符合预期要求。对于紧急故障短时间无法快速恢复的，可以通过快速重启OBPROXY进程解决。
1. 现象
2. 处置方法
经分析该表上存在频繁的DML操作时，可能会遇到一种现象：虽然表中的数据行数并不大，但是查询和更新的性能出现明显下降。这种现象在 OceanBase 中称为Queuing 表(业务上有时又称 buffer 表)效应。解决办法：绑定执行计划。对于存在可用索引，但 OB 优化器计划生成为全表扫描的场景。需要手动进行outline绑定执行计划，指定sql_id从plan_cache中刷出。为避免此类情况再次发生，将DML操作频繁的表设置为buffer表，这样表的转储与系统的大版本转储时间就不再保持一致，而是根据自身的变化，自行判断转储的时间点。
2. 处置过程
1）排查mysql日志，出现了got 11 error的错误，这是由于bug or 机器硬件导致的。3）检查mysql日志，发现mysql使用了8.0.29的版本，此版本由于出现重大bug，开源社区已回收此版本，需升级到8.0.30.在升级过程中，由于mysql频繁重启，导致实例崩溃恢复无法完成，故升级无法进行。需将原备份导入到新实例中，问题解决。3. 新炬建议
及时关注官网信息，定期对数据库进行升级。检查所有生产环境是否存在8.0.29版本数据库，如果存在，需要及时升级到最新版本。
1. 现象
3. 新炬建议
1）对业务账号权限进行规划管控，按照权限最小化原则进行赋权，防止赋权过大。
2）对业务操作变更操作进行管理，防范未经评审变更。
3）所有数据库都要进行备份，备份是运维最后一道防线，或者最后一根稻草，一定要守住。
业务运行缓慢，同时数据库主机资源紧张，数据库存在大量等待CPU的等待事件。3）对比历史执行计划和当前执行计划，由于自适应游标共享（Adaptive Cursor Sharing）特性引发执行计划发生变动，进而CPU资源上涨。3. 新炬建议
部署SQL执行计划变化告警（如果担心告警过多，可以增加过滤条件）：例如只对核心SQL进行监控，或者只对资源消耗排在TOP的SQL进行监控。某场地oracle 12c 数据库集群1节点突然宕机，无法启动。2）检查报错文件状态，发现文件权限不对，再次检查上级目录权限，发现Oracle软件安装目录权限均错误。3）通过相关脚本获取2节点目录权限，重新授予1节点目录权限。该问题是oracle和grid数据库属组发生的变更，按照正常节点修改属组后，数据库访问正常。3）对数据库维护人员警示作用，生产操作再三确认，先思后行。
在添加asm磁盘组添加磁盘提示无法添加，并提示ORA-15137: The ASM cluster is in rolling报错。经分析数据库补丁更新后，数据库补丁模式在rolling下，导致无法添加asm磁盘。1）上线通过命令asmcmd showclusterstate查看数据库补丁状态信息，返回值为In Rolling Patch。2）通过命令kfod op=patches查看补丁集信息状态。3）在实际情况中kfod op=patches碰到过两种情况：- （2）两边补丁信息一致，但是数据库仍然提示为in rolling patch模式
- （2）patchgen commit -rb +补丁号，进行回滚操作
5）针对补丁信息一致但是仍然提示rolling patch情况，两边节点按照步骤执行：在宝贵的补丁停机时间中，我们在补丁更新后要主动检查补丁状态信息，不能在补丁更新中无报错就直接忽略，从而避免不必要的后续故障问题。
查看哪些索引导致集群进入黄色状态,增加每个黄色索引的最大重试次数。1）以混沌工程为切入点，完善相关监控项和自愈方案开发。2）完善ES告警体系，对ES未分片进行告警。
ipv6 前缀地址(类似ipv4的子网掩码)是128，ipv6双栈改造报错，不同网段的主机不通。1）观察到ipv6 的前缀地址之后，反馈给主机和网络检查，ping IPV6 测试主机网络是通的。2）ORACLE集群添加ipv6 的子网直接报错如下：./srvctl modify network -subnet 2049:8020:5cc0:bbf2:c701::/112
PRCN-2070 : Failed to validate network. No interface matches required network
(subnet: 2049:8020:5cc0:bbf2:c701::, netmask: 112 adapters: ).
3）再次联系网络的同事检查，经确认是由于/usr/sbin/dhclient-script 脚本导致的，因为ipv6 从dhcp 不能获取到子网信息，前缀地址是固定在脚本中的，需要修改脚本中new_ipv6_prefixlen=128 为new_ipv6_prefixlen=划分的子网长度。3. 新炬建议
对于IPV6改造，要提前进行子网规划，提前进行相关测试。避免因为双栈改造导致业务故障。
zabbix_server采集延迟越来越大，查看zabbix_server服务进程时发现预处理进程（preprocessing）积压数据越来越大，最终缓存数据会撑爆主机内存导致内存溢出，操作系统自动kill调zabbix_server进程。1）观察zabbix_server预处理进程（preprocessing)数据积压是否越来越大，历史数据同步进程（history syncer）是否存在耗时较大的情况；2）zabbix_server运行日志error报错处理，重点关注写入/更新报错日志并跟进处理，其次可能会存在因为脚本下发不成功或者脚本未能正常更新导致的采集指标报错的日志，需要重新下发/更新采集脚本/禁用监控项方式解决掉报错问题；3）proxy状态排查和参数优化,重点关注proxy有无磁盘空间满、proxy进程耗时较长情况，proxy参数重点关注ConfigFrequency参数（该参数为proxy向zabbix_server端检索配置数据的频率，如果较为频繁，会增加zabbix_server压力）；4）zabbix_server性能调优(重点关注StartPollers和StartPreprocessors参数)。1）增加对ZABBIX积压告警，大多数情况下ZABBIX主要用于各类运维系统，需要增加自监控，防止监控系统在自身出现问题时灯下黑，进而让运维人变成睁眼瞎。
2）对zabbix进行性能调优。
推荐阅读：
