故障描述

时间脉络：

2025 年 01 月 10 日

08 点 20 分，客户 hihis 库产生卡顿现象，事权从急，客户主动重启服务器尝试恢复业务。

08 点 33 分，工程师接到客户电话反馈， hihis 数据库出现卡顿现象，工程师第一时间远程接入排查问题，并且准备切换容灾。

08 点 50 分， hihis 库尝试重启服务器，并于 08 点 55 分使用 switchover 的方式完成数据库切换。

08 点 55 分，工程师远程、现场同步进行，开始排查本次数据库故障。

问题详细诊断过程

卡顿期间数据库的 awr 报告，可以发现当天等待事件列表中，对比前一天的同时间段， direct path write temp 等待事件的等待远超正常的值。

排查该等待事件发现相关语句（ 69w0duhr38pkt ）

从各维度（执行时间、 io 、 cpu 、 hets 等等）排序 top 语句，该语句（ 69w0duhr38pkt ）都名列前茅。

查看数据库 alert 日志，可以发现 pga 内存问题。

查看该报错的 trc 文件，发现问题原因与 awr 报告的结论吻合，（ 69w0duhr38pkt ）语句导致 pga 使用过度。

完整问题语句

SELECT "PBID",
       "YSDM",
       "YGXM",
       "YGXB",
       "KSDM",
       "KSMC",
       "KSMS",
       "PBRQ",
       "ZBLB",
       "HYZS",
       "HYKY",
       "CATEGOR",
       "GHF",
       "ZLF",
       "PBZT",
       "HYJH",
       "JGBM",
       "MZLB",
       "GHLB2",
       "YZBZ",
       "GZRQ",
       "PBFWMC"
  FROM "V_YY_GET_DEPT_KSPBCX" "A"
 WHERE "GHLB2" = :1
   AND "MZLB" = :2
   AND (SYS_OP_C2C("KSMC") LIKE 'hi%' OR SYS_OP_C2C("KSMC") LIKE 'A%')
   AND ("GZRQ" >= TO_DATE(TO_CHAR(:3, 'yyyy-mm-dd'), 'yyyy-mm-dd') + 1 AND
       TO_DATE(TO_CHAR("GZRQ", 'yyyy-mm-dd') || :4,
                'yyyy-mm-dd hh24:mi:ss') <= :5 + 29 OR
       (TO_CHAR(:6, 'hh24:mi:ss') >= :7 AND
       TO_CHAR(:8, 'hh24:mi:ss') <= :9 OR
       "ZBLB" = 2 AND TO_CHAR(:10, 'hh24:mi:ss') >= :11 AND
       TO_CHAR(:12, 'hh24:mi:ss') <= :13) AND "GZRQ" = TRUNC(:14))

查看 awr 报告中 pga 参数相关部分，起库时使用 8g ，问题时间点关库时使用 80+g ，对应上了 alert 日志中 pga 使用过度的问题。

Hash join ，驱动表的 select 列和 join 列写入 pga 的 work area 中，对驱动表的连接列进行 hash 运算，在 pga 中产生一个 hash 表，被驱动表与 pga 中的 hash 表进行关联。

pga 不能容纳驱动表的时候，驱动表会溢出到临时表空间，进而和磁盘 hash 连接， hash 连接性能严重下降。

怀疑该问题语句执行计划抖动严重，查看不同时间点 hash value 的变化。发现确实存在多个执行计划。

拉取 awrsql 报告，查看问题时间点的 sql 变化，发现故障前后时间内存在 2 个执行计划，并且性能差距过大。

下图为将更优执行计划（ hash value 3881640883 ）绑定问题语句（ 69w0duhr38pkt ）。

执行计划绑定完，业务速度得到显著提升。