Oracle性能调查之ASH

柠檬

已于 2022-10-31 15:36:46 修改

阅读量184

点赞数

文章标签： oracle 数据库

于 2022-10-31 09:55:36 首次发布

原文链接：https://cloud.tencent.com/developer/article/2077761

版权

转载于：Oracle性能调查之ASH（一） - 腾讯云开发者社区-腾讯云

在ORACLE性能问题调查时，有价值的诊断情报多： STATSPACK， AWR，ASH， SYSTEMSTATE DUMP 等等。每一种都在特定的场景起到重要的作用。其中最多的一个场景就是问题发生后采用了紧急对应，暂时回避了问题，但是问题的原因需要详细的调查。这时候，ASH就是一个非常有效的情报。

为什么呢？

因为在这种情况下，无论是客户还是Support工程师,最想知道的就是到底发生了啥问题。

ASH就是为了满足这个需要而产生的，它可以提供两种时间间隔（1秒和10秒）的Active Session的几乎所有相关的信息。

下面先说一下ASH的内部设计吧。

参照上面的图，我们来整理一下ASH情报的来源和处理过程。

1. 后台进程MMNL（MMON Lite 即轻量化的MMON进程），每1秒钟1次（采集间隔由隐藏参数“_ash_sampling_interval”控制）把V$SESSION 和V$SESSION_WAIT的数据里的ACTIVE SESSION（非IDLE待机SESSION）转存到V$ACTIVE_SESSION_HISTORY里。 2. V$ACTIVE_SESSION_HISTORY的数据存储在SGA中的一个循环使用的Buffer里，大小用隐藏参数“_ash_size”控制。

3. Buffer里的记录按照比例（由隐藏参数“_ash_disk_filter_ratio”控制）被写到磁盘上，可以通过DBA_HIST_ACTIVE_SESS_HISTORY查询。

4. 存到磁盘上的数据遵守AWR的保存Policy。

关于ASH机能一些隐藏参数，可以参照以下：

Parameter                                          Value       Description
-------------------------------------------------- ----------- ----------------------------------------------------------------------------------------
_ash_sampling_interval                             1000        Time interval between two successive Active Session samples in millisecs

_ash_size                                          1048618     To set the size of the in-memory Active Session History buffers

_ash_enable                                        TRUE         To enable or disable Active Session sampling and flushing

_ash_disk_write_enable                             TRUE          To enable or disable Active Session History flushing

_ash_disk_filter_ratio                             10             Ratio of the number of in-memory samples to the number of samples actually written to disk

_ash_eflush_trigger                                66           The percentage above which if the in-memory ASH is full the emergency flusher will be triggered

_ash_sample_all                                    FALSE         To enable or disable sampling every connected session including ones waiting for idle waits

_ash_dummy_test_param                              0             Oracle internal dummy ASH parameter used ONLY for testing!

_ash_min_mmnl_dump                                 90            Minimum Time interval passed to consider MMNL Dump

_ash_compression_enable                            TRUE          To enable or disable string compression in ASH

_ash_progressive_flush_interval                    300           ASH Progressive Flush interval in secs

那么如何利用ASH情报分析性能问题呢？

这个问题没有固定答案，因为ASH是一种原始数据，只负责记录SESSION在采样时的状态。所以ASH并不直接反映问题，只提供分析问题的材料。

也就是说，DBA或Support工程师必须先对问题分析，想定一个或多个问题发生的原因和剧本。然后在利用ASH数据找到支持自己设想的证据。

今天举一个简单的例子。

客户报告3个APP Servers和两个节点的RAC环境中，有一个APP Server的处理比另外两个APP Servers的处理慢，但是发往3个APP Servers的处理本身没有任何区别。

因为客户是在APPLICATION 的画面上确认到的这个问题，所以首先调查了APP Server端，但是没有找到原因，于是APP Server的Support工程师怀疑DB端的问题，就向我们DB的Support发出了调查要求。

基于前面问题的描述，最直观的反应就是这个问题和DB没有关系，原因有二：第一是3个APP Servers发出的处理（SQL文）本身没有区别；第二是DB端处理SQL文时只关注SQL的请求内容，不会关注是哪一台APP Server发来的请求。

为了找到证据来证明上面的观点，我首先假设这个问题慢的地方不在DB，而是APP Server本身或网络延迟，而在DB端实际没有任何延迟，3台APP Servers的处理速度是一样的。

然后我用下面的SQL文对延迟时间段内3台APP Servers发出的所有SQL文进行了抽取和比较，结果如下：

SQL> select SQL_ID,SQL_PLAN_HASH_VALUE,SQL_EXEC_ID,count(*)
from m_dba_hist_active_sess_history
where PROGRAM='JDBC Thin Client'
and MACHINE='APP Server Name'
group by SQL_ID,SQL_PLAN_HASH_VALUE,SQL_EXEC_ID
order by count(*) desc;

◆1号点（Slow Node）
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777258 115
aaaaaaaaaaaa 2617621828 16777220 69
bbbbbbbbbbbb 1192575627 33554439 34
cccccccccccc 1878459779 16777216 13
dddddddddddd 2703624694 16777216 7
dddddddddddd 2703624694 33554432 6
eeeeeeeeeeee 876643066 33554438 4
eeeeeeeeeeee 876643066 33554439 4
eeeeeeeeeeee 876643066 16777238 4
eeeeeeeeeeee 876643066 16777237 4
eeeeeeeeeeee 876643066 16777240 4

◆2号点
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777223 150
aaaaaaaaaaaa 2617621828 16777221 150
aaaaaaaaaaaa 2617621828 16777224 30
aaaaaaaaaaaa 2617621828 16777222 30
aaaaaaaaaaaa 2617621828 16777225 27
aaaaaaaaaaaa 2617621828 16777219 16
aaaaaaaaaaaa 2617621828 16777218 16
bbbbbbbbbbbb 3425641204 16777222 32
bbbbbbbbbbbb 3425641204 16777221 31
bbbbbbbbbbbb 3425641204 16777223 28
bbbbbbbbbbbb 3425641204 16777220 16
bbbbbbbbbbbb 3425641204 16777219 15
dddddddddddd 2703624694 33554437 7
dddddddddddd 2703624694 33554436 6
eeeeeeeeeeee 876643066 33554450 4
eeeeeeeeeeee 876643066 16777219 4
eeeeeeeeeeee 876643066 16777220 4
eeeeeeeeeeee 876643066 33554440 4
eeeeeeeeeeee 876643066 16777221 4
eeeeeeeeeeee 876643066 33554452 4
eeeeeeeeeeee 876643066 16777222 3
eeeeeeeeeeee 876643066 33554441 3
eeeeeeeeeeee 876643066 16777241 3
eeeeeeeeeeee 876643066 16777224 3
eeeeeeeeeeee 876643066 33554453 3

◆３号点
SQL_ID SQL_PLAN_HASH_VALUE SQL_EXEC_ID COUNT(*)
-------------------- ------------------- ----------- ----------
aaaaaaaaaaaa 2617621828 16777217 7
bbbbbbbbbbbb 3425641204 16777218 8
eeeeeeeeeeee 876643066 16777216 6
eeeeeeeeeeee 876643066 33554449 4
eeeeeeeeeeee 876643066 33554446 4
eeeeeeeeeeee 876643066 16777239 4
eeeeeeeeeeee 876643066 16777244 4
eeeeeeeeeeee 876643066 16777223 4
eeeeeeeeeeee 876643066 16777243 4
eeeeeeeeeeee 876643066 33554443 4
eeeeeeeeeeee 876643066 16777217 4
eeeeeeeeeeee 876643066 16777245 3
eeeeeeeeeeee 876643066 33554445 3
eeeeeeeeeeee 876643066 33554444 3
eeeeeeeeeeee 876643066 16777218 3
eeeeeeeeeeee 876643066 33554442 3
eeeeeeeeeeee 876643066 33554448 3
eeeeeeeeeeee 876643066 33554451 3
eeeeeeeeeeee 876643066 33554447 3
eeeeeeeeeeee 876643066 16777242 3

通过上面的比较，我们会发现相同的SQL文在客户报告处理慢的1号机和不慢的2号机3号机相比，采样时并没有明显的区别。因为一个采样基本可以看作SQL文执行了10秒钟。（？？）

这就证明了我们对DB端没有区别，问题点也不在DB端的设想，剩下的就得让APP Server和网络的Support去调查了。