数据库管理-第九十二期 一周故障汇总（20230717）
第九十二期 一周故障汇总（20230717）
距离上一篇已经过了整整一周了，平时我虽然不是生产队的驴，但是一周一篇以上的数量还是维持了一段时间了。为啥上周只写了一篇，因为各种故障、各种保障、各种割接忙了整整一周，确实没有多的精力来写这些东西，这里给过去“悲惨”的一周做个总结。
1 ksplice
同红帽的kpatch一样，OracleLinux有一提供了一个名为ksplice的Linux内核热修复技术，可以在不停机的情况下修复Linux内核的各种问题和BUG[具体详见：
HOWTO: Install ksplice kernel updates for Exadata Database Nodes (Doc ID 2207063.1)（好像现在没法通过ULN直接下载了）]。
上周有一天凌晨一体机有一个计算节点出现了重启的现象，经过排查是因为之前打补丁的时候，重启过服务器，操作系统的内核热修复丢了：
[root@xxx01 ~]# rpm -qa|grep uptrack
[root@xxx01 ~]
#这里发现对应的ksplice包不见了
#通过EXACHK检查操作系统发现节点1出现ksplic的异常告警
[root@xxx02 ~]# rpm -qa|grep uptrack
uptrack-offline-1.2.62.offline-0.el7.noarch
uptrack-updates-4.14.35-1902.9.2.el7uek.x86_64-20221103-0.noarch
##对应另一台机器包则正常。
[root@xxx01 ~]$ which uptrack-show
/usr/sbin/uptrack-show
[root@xxx01 ~]$ which uptrack-install
/usr/sbin/uptrack-install
#uptrack相关命令还在
[root@xxx01 ~]$ uptrack-show
Installed updates:
Effective kernel version is 4.14.35-2047.518.4.1.el7uek
#显示没有任何热修复被安装
[root@xxx02 ~]$ uptrack-show|wc -l
430
##另一个节点则显示安装了总计427个补丁
[root@xxx01 ~]$ uptrack-install --all -y
....
... sucess ... ##通过该命令完成内核热修复安装
[root@xxx01 ~]$ uptrack-show|wc -l
430
##热修复完成
这也让我在以后任意一体机节点重启后，增加一个ksplice内核热修复的检查项。
2 jobs
重启完成后发现一个PDB的job都没法正常执行了，基础排查发现是schedule date
没有更新，手动执行job出现以下报错：
ORA-27492: unable to run job "" : scheduler unavailable
ORA-06512: at "SYS.DBMS_ISCHED", line 185
ORA-06512: at "SYS.DBMS_SCHEDULER", line 486
ORA-06512: at line 2
经过排查发现这个异常PDB的启动状态是RESTRICTED:
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBxx1 READ WRITE NO
4 PDBxx2 READ WRITE YES --这里出了问题
这个导致了JOB执行异常，检查对应PDB的状态：
SQL> select type,status,action from pdb_plug_in_violations;
TYPE STATUS
--------- ---------
ACTION
--------------------------------------------------------------------------------
ERROR RESOLVED
Call datapatch to install in the PDB or the CDB
ERROR PENDING
Call datapatch to reinstall
ERROR PENDING
Call datapatch to install in the PDB or the CDB
SQL> select MESSAGE from PDB_PLUG_IN_VIOLATIONS;
MESSAGE
--------------------------------------------------------------------------------
19.16.0.0.0 Release_Update 2207030222: APPLY with status WITH ERRORS in the PDB
Interim patch 35204190/25161908 (MERGE ON DATABASE RU 19.16.0.0.0 OF 34725493 34
476155): APPLY with status WITH ERRORS in the PDB.
Interim patch 35204190/25161908 (MERGE ON DATABASE RU 19.16.0.0.0 OF 34725493 34
476155): Installed in the CDB but not in the PDB
进一步检查发现是上周GIS相关补丁应用出现了异常，但是打完补丁后，datapatch的output均显示成功，且启动后所有PDB都不是RESTRICTED状态，检查上一次的SQLPatch日志：
ERROR at line 1:
ORA-04021: timeout occurred while waiting to lock object xxx.xxxxxxx --这里出现了异常
ORA-06512: at line 17
ORA-06512: at line 10
随即重新执行datapatch并重启PDB，恢复正常。这里初步排查是异常重启触发了补丁异常引起PDB启动状态异常引起JOB无法执行，需要进行重新修复。这里又让我在将来的datapatch后，添加“grep ERROR xxx.log”的操作内容（前台输出有时候真不靠谱）。
3 EMC VMAX
其实前周末开始我这里就得一套X86的RAC集群就出现了大量的REDO、UNDO和集群IO异常的现象，但是由于业务负载确实低，前台没啥影响，加上周末就暂时没管，来到星期一就发现集群的IO等待上升了很多，集群活动会话数是前一周未出问题时数量的4倍左右：
跟硬件那边确认所有FC链路都是16Gbp，但是集群IO只能跑到100MB/s左右，这时候业务也开始反馈感觉数据库延迟比之前要大。最终和虚拟化那边沟通发现，使用同一套存储的虚拟化也出现了相同的问题，EMC工程师排查发现部分链路的存储端口数量不足，导致整个存储外部性能下降，当晚割接增加存储端口解决了该问题。
4 sid=?
这里说一个我之前忽略的一个东西，在RAC中，带sid的参数优先级是：
sid=‘SIDX’ > sid=‘*’
这个不注意经常会造成重启数据库后某些实例参数异常，可以使用reset清除带有具体实例的数据库参数的实力：
alter system reset db_cache_size [spfile=xxx] sid='SID1';
alter system reset shared_pool_size [spfile=xxx] sid='SID1';
5 bond
本周还协助处理了一个堆叠交换机异常，两台中的一台两个电源同时冒烟，影响了部分没有做bond的RAC集群（也就是那种服务器只有俩网口，两台机器生产和私网都分别接到了各自的交换机上），整个进群直接崩了。
最后协助结果就是把一台机器的两根线接到同一个交换机，然后把交换机端口调整到对应vlan先恢复数据库单点运行，恢复业务。
6 其他
- 其他还有某些服务器运行过程中异常重启，没法进入系统，最终排查boot分区损坏，进救援模式重建又因为BIOS启动时EFI or Legacy，导致前几次修复都因为救援禁了Legacy模式导致修复失败。最终调回仅EFI模式修复成功。
- 还是上面那台机器涉及的RAC集群，由于私网是直连的，在这台机器挂掉后，另一台机器的私网网卡就down掉了（确切来说是私有IP掉了），但是HAIP还在网卡上挂着，因此这个节点集群没挂，但是之前出问题的节点因为私网不通无法启动，就需要重启没出问题这台机器的网卡来解决这个问题。哎。。多灾多难。
总结
多灾多难的一周。
老规矩，知道写了些啥。