好烦啊，1个SQL干崩核心系统长达12小时！

作者：IT邦德
中国DBA联盟(ACDU)成员，10余年DBA工作经验，
Oracle、PostgreSQL ACE
CSDN博客专家及B站知名UP主，全网粉丝10万+
擅长主流Oracle、MySQL、PG、
高斯及Greenplum备份恢复，
安装迁移，性能优化、故障应急处理

微信:jem_db
QQ交流群:587159446
公众号：IT邦德

前言

1.故障现象

enq:TX -index contention
cursor: pin S wait on X
direct path read

通过监控发现服务器IO和CPU使用率已经高达90%
整个数据库算是夯住了！
根据经验判断应该是性能的问题

2.排查过程

2.1 AWR分析

2.2 定位异常SQL

2.3 分析执行计划

--该方法是从共享池得到
如果SQL已被age out出share pool，则查找不到
select * from table
(dbms_xplan.display_cursor('&sql_id',null,'typical'));

--该方法是通过awr中得到
select * from table(dbms_xplan.display_awr('&sql_id'));

2.4 故障定位

3.处理过程

1.定位到SQL的内存地址，从内存中刷出执行计划
select address,hash_value,
executions,parse_calls 
from  v$sqlarea where
sql_id='4ca86dg34xg62';

--刷出内存
exec sys.dbms_shared_pool.purge('C000000A4C502F40,4103674309','C');  

2.收集分区统计信息

BEGIN
    -- 为整个表加上统计信息（包括所有分区）
    DBMS_STATS.GATHER_TABLE_STATS(
        ownname     => 'YOUR_SCHEMA', -- 替换为你的模式名
        tabname     => 'YOUR_PARTITIONED_TABLE', -- 替换为你的分区表名
        cascade     => TRUE, -- 收集所有分区的统计信息
        estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -- 自动估算采样百分比
        method_opt  => 'FOR ALL COLUMNS SIZE AUTO', -- 为所有列自动决定采样大小
        degree      => DBMS_STATS.DEFAULT_DEGREE -- 使用默认并行度
    );
END;
/

此时我们再次查看执行计划，正确了！

4.技能拓扑

5.总结

警惕Oracle数据库性能“隐形杀手”——Direct Path Read, 如果不把导致问题的根本原因找到，那么很有可能下次还会再发生！