oracle sqlhc使用方法

• 具体使用 参照 Document 1366133.1 SQL Tuning Health-Check Script (SQLHC)

Oracle 的11g版本正式发布到今天已经10年有余，最新版本已经到了20c，但是Direct Path Read（直接路径读）导致性能问题的案例有很多，很多12c的用户还经常遇到这个问题，所以有必要把这个事情再跟大家讲一遍，通过2个典型案例加深理解。

早在2012年，盖国强大师就撰写文章，介绍了direct path read这个11g版本推出的新特性：
https://www.eygle.com/archives/2012/05/oracle_11g_direct_path_read.html ；也有人把关闭这个功能作为“最佳实践”，我建议先多了解一些具体情况再决定。

Direct path read的目的是让一些不常使用的大表数据（冷数据），在全表扫描时，每次都从磁盘读到用户的私有内存（PGA），而不要去挤占有限的、宝贵的、频繁使用的数据（热数据）所在的共享内存（SGA-bufer cache）。

热数据只在第一次访问时从磁盘读，读到SGA的buffer cache后，再次访问会直接从内存读，效率高、对存储压力小。

试想一个表被频繁全表扫描访问（缺少索引或业务设计不合理），一开始表还不算太大，会放到共享内存，只需要少量的磁盘读，这时对存储压力不大；随着记录数的不断增加，达到了一个参数设置的阀值和条件后，就会使用direct path read，频繁的磁盘读就会造成存储的巨大压力，出现严重的性能问题。

从共享内存读到直接路径读，这个变化在不频繁的全表扫描时是起到积极作用的；如果业务不合理（一个大表正常情况不会有频繁的全表扫描）、或者缺少索引（这个是比较多的情况），频繁的大表全表扫描就会在某个触发点上对数据库性能做出致命一击，导致业务瘫痪。

案例1：

某银行业务数据库A夜间跑批业务突然变慢，查了很长时间，对top sql也做了“优化”（清除历史数据，虽然是比较初级优化手段，但是也最有效，如果数据需要保留就不行），仍未解决。

因为是5~6套数据库共享一套存储，而且表现在存储响应时间慢，开始对其他几套库进行排查，发现其中一套数据库B在这段时间内IO消耗突增。

故障时段AWR报告显示如下：

1.jpg

2

3

数据库B之前正常时段AWR 情况：
（awr对比是分析系统性能问题的一个重要手段，建议定期保存awr基线）
Load Profile（Read IO相差1000多倍 1057.6M vs 0.7M）：

4

Top events：direct path read只占 DB time 的0.1% （故障时段63.1%):

5

Top Read SQL：消耗较少物理读

6

通过对比发现是一个SQL的物理读突增导致存储整体下降，影响到存储上的其他数据库。

对该TOP SQL分析发现，sql执行频繁，执行计划没有改变（下图红框内第一列，一直是全表扫描），但是某天夜间突然Disk Reads次数（下图中间部分）暴增，这个时间正是数据库A跑批业务出问题的时间段，下面是sqlhc收集到的sql执行历史信息：

7

该SQL逻辑比较简单，2个谓词条件的单表查询，只需要创建一个简单索引，即可避免全表扫描。创建索引后，一切恢复正常。