Active Session History (ASH)视图以及实表是ORALCE数据库提供的一个十分有价值的调优工具。
ASH提供两个细粒度的视图：V$ACTIVE_SESSION_HISTORY和DBA_HIST_ACTIVE_SESS_HISTORY。V$ACTIVE_SESSION_HISTORY是1秒钟采样1次的动静视图，DBA_HIST_ACTIVE_SESS_HISTORY是10秒1次采样，存储到实表（WRH$_ACTIVE_SESSION_HISTORY）中的流动SESSION历史数据。
对于ASH数据的采样逻辑和关联的PROCESS，我会在当前的文章里阐明。
上面我用一个简略的例子来阐明如何通过ASH数据考察CPU使用率高的问题。
客户问题形容
9个节点形成的RAC环境中，有一个节点在下列时间段CPU使用率偏高，同时呈现以下待机事件。
【日時】2020/12/01 ①12:00 ～ 13:00②19:00 ～ 21:00③22:00 ～ 23:00【待机事件】latch: row cache objectsenq: US - contentionenq: SQ - contention为了确认第一个时间段（12:00～13:00）内“ON CPU”的解决内容，我查看了ASH数据的“SESSION_STATE='ON CPU'”的输入。
SQL> select substr(to_char(SAMPLE_TIME,'yyyy/mm/dd hh24:mi'),1,15) aa,SESSION_STATE,SQL_OPNAME,PROGRAM,count(*)from m_dba_hist_active_sess_historywhere INSTANCE_NUMBER=5and SESSION_STATE='ON CPU'and to_char(SAMPLE_TIME,'yyyy/mm/dd hh24')='2020/12/01 12'group by substr(to_char(SAMPLE_TIME,'yyyy/mm/dd hh24:mi'),1,15),SESSION_STATE,SQL_OPNAME,PROGRAMorder by substr(to_char(SAMPLE_TIME,'yyyy/mm/dd hh24:mi'),1,15); 2 3 4 5 6 7AA SESSION_STATE SQL_OPNAME PROGRAM COUNT(*)------------------------------ -------------------- --------------- ------------------------------ ----------2020/12/01 12:0 ON CPU INSERT JDBC Thin Client 62020/12/01 12:0 ON CPU SELECT JDBC Thin Client 2322020/12/01 12:0 ON CPU SELECT oracle@db215jln (PZ99) 12020/12/01 12:0 ON CPU SELECT python@db215jln (TNS V1-V3) 22020/12/01 12:0 ON CPU UPDATE JDBC Thin Client 12020/12/01 12:0 ON CPU UPDATE oracle@db215jln (SMON) 12020/12/01 12:0 ON CPU JDBC Thin Client 82020/12/01 12:0 ON CPU oracle@db215jln (DIA0) 12020/12/01 12:0 ON CPU oracle@db215jln (LCK0) 12020/12/01 12:0 ON CPU oracle@db215jln (LMD0) 12020/12/01 12:0 ON CPU oracle@db215jln (LMON) 12020/12/01 12:0 ON CPU oracle@db215jln (LMS0) 22020/12/01 12:0 ON CPU oracle@db215jln (LMS1) 12020/12/01 12:1 ON CPU INSERT JDBC Thin Client 132020/12/01 12:1 ON CPU PL/SQL EXECUTE JDBC Thin Client 32020/12/01 12:1 ON CPU SELECT JDBC Thin Client 2492020/12/01 12:1 ON CPU UPDATE oracle@db215jln (SMON) 12020/12/01 12:1 ON CPU JDBC Thin Client 102020/12/01 12:1 ON CPU oracle@db215jln (DIA0) 12020/12/01 12:1 ON CPU oracle@db215jln (LCK0) 12020/12/01 12:1 ON CPU oracle@db215jln (LGWR) 32020/12/01 12:1 ON CPU oracle@db215jln (LMD0) 12020/12/01 12:1 ON CPU oracle@db215jln (LMS0) 52020/12/01 12:1 ON CPU oracle@db215jln (LMS1) 22020/12/01 12:1 ON CPU oracle@db215jln (PSP0) 12020/12/01 12:2 ON CPU INSERT JDBC Thin Client 342020/12/01 12:2 ON CPU SELECT JDBC Thin Client 3172020/12/01 12:2 ON CPU UPDATE JDBC Thin Client 12020/12/01 12:2 ON CPU JDBC Thin Client 112020/12/01 12:2 ON CPU oracle@db215jln (DIA0) 22020/12/01 12:2 ON CPU oracle@db215jln (LCK0) 22020/12/01 12:2 ON CPU oracle@db215jln (LGWR) 22020/12/01 12:2 ON CPU oracle@db215jln (LMS1) 12020/12/01 12:3 ON CPU INSERT JDBC Thin Client 252020/12/01 12:3 ON CPU SELECT JDBC Thin Client 3352020/12/01 12:3 ON CPU SELECT oracle@db215jln (PZ99) 22020/12/01 12:3 ON CPU UPDATE JDBC Thin Client 22020/12/01 12:3 ON CPU UPDATE oracle@db215jln (SMON) 12020/12/01 12:3 ON CPU JDBC Thin Client 122020/12/01 12:3 ON CPU oracle@db215jln (DBW3) 12020/12/01 12:3 ON CPU oracle@db215jln (DIA0) 22020/12/01 12:3 ON CPU oracle@db215jln (LGWR) 32020/12/01 12:3 ON CPU oracle@db215jln (LMD0) 12020/12/01 12:3 ON CPU oracle@db215jln (LMON) 12020/12/01 12:3 ON CPU oracle@db215jln (LMS0) 42020/12/01 12:3 ON CPU oracle@db215jln (LMS1) 22020/12/01 12:4 ON CPU INSERT JDBC Thin Client 902020/12/01 12:4 ON CPU PL/SQL EXECUTE JDBC Thin Client 22020/12/01 12:4 ON CPU SELECT JDBC Thin Client 4072020/12/01 12:4 ON CPU SELECT oracle@db215jln (PZ99) 32020/12/01 12:4 ON CPU SELECT python@db215jln (TNS V1-V3) 12020/12/01 12:4 ON CPU UPDATE JDBC Thin Client 52020/12/01 12:4 ON CPU UPDATE oracle@db215jln (SMON) 12020/12/01 12:4 ON CPU JDBC Thin Client 132020/12/01 12:4 ON CPU oracle@db215jln (DBW3) 12020/12/01 12:4 ON CPU oracle@db215jln (DIA0) 12020/12/01 12:4 ON CPU oracle@db215jln (LCK0) 12020/12/01 12:4 ON CPU oracle@db215jln (LMS0) 12020/12/01 12:4 ON CPU oracle@db215jln (LMS1) 12020/12/01 12:5 ON CPU INSERT JDBC Thin Client 1712020/12/01 12:5 ON CPU SELECT JDBC Thin Client 424 ★2020/12/01 12:5 ON CPU UPDATE JDBC Thin Client 22020/12/01 12:5 ON CPU JDBC Thin Client 92020/12/01 12:5 ON CPU oracle@db215jln (DBW1) 12020/12/01 12:5 ON CPU oracle@db215jln (DIA0) 22020/12/01 12:5 ON CPU oracle@db215jln (LCK0) 32020/12/01 12:5 ON CPU oracle@db215jln (LMD0) 12020/12/01 12:5 ON CPU oracle@db215jln (LMS0) 42020/12/01 12:5 ON CPU oracle@db215jln (LMS1) 269行が選択されました。通过下面的后果，咱们能够看出在每个１０分钟内，“PROGRAM ='JDBC Thin Client'”的“SELECT”解决数是比拟多的。导致这样的状况通常有两种起因：雷同的解决被大量的施行，或者不同的解决被同时施行。为了确认客户环境的具体起因，我又应用了上面的SQL文：
SQL> select SQL_ID,count(*)from m_dba_hist_active_sess_historywhere INSTANCE_NUMBER=5and SESSION_STATE='ON CPU'and PROGRAM='JDBC Thin Client'and to_char(SAMPLE_TIME,'yyyy/mm/dd hh24')='2020/12/01 12'group by SQL_IDorder by count(*) desc;SQL_ID COUNT(*)------------------ ----------7f3a4khpu7n25 164 ★1fa2urjuhszw0 112 ★4f72h6sug6vah 757au5hjhjz8nd1 68 63gmrv0dahmkhg6 580x1wyyvgkwx4g 49ataahn09x2qr2 478mpsb34rxj96w 41a0wsrytjhnncz 374wn22n0t23x8f 2847ha0qjatpapp 282ppp78vj7ac34 28273srycwymvpy 248037vz8n5t4j4 23d94xfcs7yzwwn 2119rf604u0dycw 216r4216jcwbyp2 219dqkydrfrpgm2 213d9pv0n2vsfp5 20b9yjdusam9wp2 19d9f8yxm8r3k3r 177mg7gtjwp644w 17f7tqxnbcvv2ah 17aszugq4dt7qcc 17a97t6fkmquuj1 17f21uh36n93rzv 161dg8hng84mrnc 15bu51ut3y2ttr2 1509u5mfdu2dyau 1519d5qmbdwg028 154uf4x7zz96ban 152t21r20y0a3k7 1565m1gs66zhw7z 1405uya8bx3u382 14ayknqa5wkd9zp 146ytwz7bgkbksc 14bk3q8xpbr46n8 143kf4b3s3bdzaf 136z1hf4txv7f8c 13438r3mjyuht18 128c1h7xwtm6gzv 12fu9y7cmx4wy98 12fgdtg91uuds65 124f96jfgdrwxgf 1109yxbt27kpbq4 11bghzspvbjh2vm 105xkjqnuqkbg2b 106za6t3kv5c7mj 10fudk908tvjdfy 10…略…通过下面的后果，咱们根本能够确认这个问题的起因就是在特定的时间段内通过“JDBC Thin Client”发行的业务解决过多，并不是遇到了Bug。
当然，在得出这个论断之前，咱们也确认了以下两点：
1.在客户提到的时间段之外，通过“JDBC Thin Client”发行的业务解决数较少。2.在客户提到的另外两个时间段，也确认到了12：00 到13：00之间的景象。最初，这只是一个利用ASH剖析性能问题的小例子，ASH作为ORACLE数据库能提供的粒度最细的历史数据，还有许多实用的办法。如果想要灵便应用这些数据，笔者举荐仔细阅读ASH数据的每一个字段。