乐趣区

关于数据库:Oracle-性能调查之ASH一

jiezi

在 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

◆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 去考察了。

明天只是用一个小例子来简略阐明一下 ASH 的用法，当前我会分享更多的例子，欢送关注。

2021/03/17 @ Dalian

退出移动版