oracle ash的作用,关于数据库: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去考察了。

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

2021/03/17 @ Dalian