oracle的ash信息被清理了,性能优化 ---- ORACLE数据库的ASH

最新推荐文章于 2023-10-14 09:01:07 发布

weixin_39633113

最新推荐文章于 2023-10-14 09:01:07 发布

阅读量265

点赞数

文章标签： oracle的ash信息被清理了

本文通过一个实例展示了如何使用ASH(Active Session History)视图来调查Oracle数据库中CPU使用率高的问题。在特定时间段，发现'JDBCThinClient'执行的'SELECT'操作数量较多，可能是造成CPU高负载的原因。通过进一步的数据分析，确认了该现象并非由于Bug，而是业务处理过多。ASH作为Oracle的细粒度历史数据工具，为性能调优提供了宝贵信息。

摘要由CSDN通过智能技术生成

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，可以参考以下。

bVcMYAX

下面我用一个简单的例子来说明如何通过ASH数据调查CPU使用率高的问题。

客户问题描述

9个节点构成的RAC环境中，有一个节点在下列时间段CPU使用率偏高，同时出现以下待机事件。【日時】

2020/12/01

①12:00 ～ 13:00

②19:00 ～ 21:00

③22:00 ～ 23:00

【待机事件】

latch: row cache objects

enq: US - contention

enq: 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_history

where INSTANCE_NUMBER=5

and 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,PROGRAM

order by substr(to_char(SAMPLE_TIME,'yyyy/mm/dd hh24:mi'),1,15);

2 3 4 5 6 7

AA SESSION_STATE SQL_OPNAME PROGRAM COUNT(*)

------------------------------ -------------------- --------------- ------------------------------ ----------

2020/12/01 12:0 ON CPU INSERT JDBC Thin Client 6

2020/12/01 12:0 ON CPU SELECT JDBC Thin Client 232

2020/12/01 12:0 ON CPU SELECT oracle@db215jln (PZ99) 1

2020/12/01 12:0 ON CPU SELECT python@db215jln (TNS V1-V3) 2

2020/12/01 12:0 ON CPU UPDATE JDBC Thin Client 1

2020/12/01 12:0 ON CPU UPDATE oracle@db215jln (SMON) 1

2020/12/01 12:0 ON CPU JDBC Thin Client 8

2020/12/01 12:0 ON CPU oracle@db215jln (DIA0) 1

2020/12/01 12:0 ON CPU oracle@db215jln (LCK0) 1

2020/12/01 12:0 ON CPU oracle@db215jln (LMD0) 1

2020/12/01 12:0 ON CPU oracle@db215jln (LMON) 1

2020/12/01 12:0 ON CPU oracle@db215jln (LMS0) 2

2020/12/01 12:0 ON CPU oracle@db215jln (LMS1) 1

2020/12/01 12:1 ON CPU INSERT JDBC Thin Client 13

2020/12/01 12:1 ON CPU PL/SQL EXECUTE JDBC Thin Client 3

2020/12/01 12:1 ON CPU SELECT JDBC Thin Client 249

2020/12/01 12:1 ON CPU UPDATE oracle@db215jln (SMON) 1

2020/12/01 12:1 ON CPU JDBC Thin Client 10

2020/12/01 12:1 ON CPU oracle@db215jln (DIA0) 1

2020/12/01 12:1 ON CPU oracle@db215jln (LCK0) 1

2020/12/01 12:1 ON CPU oracle@db215jln (LGWR) 3

2020/12/01 12:1 ON CPU oracle@db215jln (LMD0) 1

2020/12/01 12:1 ON CPU oracle@db215jln (LMS0) 5

2020/12/01 12:1 ON CPU oracle@db215jln (LMS1) 2

2020/12/01 12:1 ON CPU oracle@db215jln (PSP0) 1

2020/12/01 12:2 ON CPU INSERT JDBC Thin Client 34

2020/12/01 12:2 ON CPU SELECT JDBC Thin Client 317

2020/12/01 12:2 ON CPU UPDATE JDBC Thin Client 1

2020/12/01 12:2 ON CPU JDBC Thin Client 11

2020/12/01 12:2 ON CPU oracle@db215jln (DIA0) 2

2020/12/01 12:2 ON CPU oracle@db215jln (LCK0) 2

2020/12/01 12:2 ON CPU oracle@db215jln (LGWR) 2

2020/12/01 12:2 ON CPU oracle@db215jln (LMS1) 1

2020/12/01 12:3 ON CPU INSERT JDBC Thin Client 25

2020/12/01 12:3 ON CPU SELECT JDBC Thin Client 335

2020/12/01 12:3 ON CPU SELECT oracle@db215jln (PZ99) 2

2020/12/01 12:3 ON CPU UPDATE JDBC Thin Client 2

2020/12/01 12:3 ON CPU UPDATE oracle@db215jln (SMON) 1

2020/12/01 12:3 ON CPU JDBC Thin Client 12

2020/12/01 12:3 ON CPU oracle@db215jln (DBW3) 1

2020/12/01 12:3 ON CPU oracle@db215jln (DIA0) 2

2020/12/01 12:3 ON CPU oracle@db215jln (LGWR) 3

2020/12/01 12:3 ON CPU oracle@db215jln (LMD0) 1

2020/12/01 12:3 ON CPU oracle@db215jln (LMON) 1

2020/12/01 12:3 ON CPU oracle@db215jln (LMS0) 4

2020/12/01 12:3 ON CPU oracle@db215jln (LMS1) 2

2020/12/01 12:4 ON CPU INSERT JDBC Thin Client 90

2020/12/01 12:4 ON CPU PL/SQL EXECUTE JDBC Thin Client 2

2020/12/01 12:4 ON CPU SELECT JDBC Thin Client 407

2020/12/01 12:4 ON CPU SELECT oracle@db215jln (PZ99) 3

2020/12/01 12:4 ON CPU SELECT python@db215jln (TNS V1-V3) 1

2020/12/01 12:4 ON CPU UPDATE JDBC Thin Client 5

2020/12/01 12:4 ON CPU UPDATE oracle@db215jln (SMON) 1

2020/12/01 12:4 ON CPU JDBC Thin Client 13

2020/12/01 12:4 ON CPU oracle@db215jln (DBW3) 1

2020/12/01 12:4 ON CPU oracle@db215jln (DIA0) 1

2020/12/01 12:4 ON CPU oracle@db215jln (LCK0) 1

2020/12/01 12:4 ON CPU oracle@db215jln (LMS0) 1

2020/12/01 12:4 ON CPU oracle@db215jln (LMS1) 1

2020/12/01 12:5 ON CPU INSERT JDBC Thin Client 171

2020/12/01 12:5 ON CPU SELECT JDBC Thin Client 424 ★

2020/12/01 12:5 ON CPU UPDATE JDBC Thin Client 2

2020/12/01 12:5 ON CPU JDBC Thin Client 9

2020/12/01 12:5 ON CPU oracle@db215jln (DBW1) 1

2020/12/01 12:5 ON CPU oracle@db215jln (DIA0) 2

2020/12/01 12:5 ON CPU oracle@db215jln (LCK0) 3

2020/12/01 12:5 ON CPU oracle@db215jln (LMD0) 1

2020/12/01 12:5 ON CPU oracle@db215jln (LMS0) 4

2020/12/01 12:5 ON CPU oracle@db215jln (LMS1) 2

69行が選択されました。

通过上面的结果，我们可以看出在每个１０分钟内，“PROGRAM　='JDBC Thin Client'”的“SELECT”处理数是比较多的。导致这样的情况通常有两种原因：相同的处理被大量的实施，或者不同的处理被同时实施。为了确认客户环境的具体原因，我又使用了下面的SQL文：SQL> select SQL_ID,count(*)

from m_dba_hist_active_sess_history

where INSTANCE_NUMBER=5

and 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_ID

order by count(*) desc;

SQL_ID COUNT(*)

------------------ ----------

7f3a4khpu7n25 164 ★

1fa2urjuhszw0 112 ★

4f72h6sug6vah 75

7au5hjhjz8nd1 68

gmrv0dahmkhg6 58

0x1wyyvgkwx4g 49

ataahn09x2qr2 47

8mpsb34rxj96w 41

a0wsrytjhnncz 37

4wn22n0t23x8f 28

47ha0qjatpapp 28

2ppp78vj7ac34 28

273srycwymvpy 24

8037vz8n5t4j4 23

d94xfcs7yzwwn 21

19rf604u0dycw 21

6r4216jcwbyp2 21

9dqkydrfrpgm2 21

3d9pv0n2vsfp5 20

b9yjdusam9wp2 19

d9f8yxm8r3k3r 17

7mg7gtjwp644w 17

f7tqxnbcvv2ah 17

aszugq4dt7qcc 17

a97t6fkmquuj1 17

f21uh36n93rzv 16

1dg8hng84mrnc 15

bu51ut3y2ttr2 15

09u5mfdu2dyau 15

19d5qmbdwg028 15

4uf4x7zz96ban 15

2t21r20y0a3k7 15

65m1gs66zhw7z 14

05uya8bx3u382 14

ayknqa5wkd9zp 14

6ytwz7bgkbksc 14

bk3q8xpbr46n8 14

3kf4b3s3bdzaf 13

6z1hf4txv7f8c 13

438r3mjyuht18 12

8c1h7xwtm6gzv 12

fu9y7cmx4wy98 12

fgdtg91uuds65 12

4f96jfgdrwxgf 11

09yxbt27kpbq4 11

bghzspvbjh2vm 10

5xkjqnuqkbg2b 10

6za6t3kv5c7mj 10

fudk908tvjdfy 10

…略…

通过上面的结果，我们基本可以确认这个问题的原因就是在特定的时间段内通过“JDBC Thin Client”发行的业务处理过多，并不是遇到了Bug。

当然，在得出这个结论之前，我们也确认了以下两点：1.在客户提到的时间段之外，通过“JDBC Thin Client”发行的业务处理数较少。

2.在客户提到的另外两个时间段，也确认到了12：00 到13：00之间的现象。

最后，这只是一个应用ASH分析性能问题的小例子，ASH作为ORACLE数据库能提供的粒度最细的历史数据，还有许多实用的方法。如果想要灵活使用这些数据，笔者推荐仔细阅读ASH数据的每一个字段。

weixin_39633113

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
oracle的ash信息被清理了,性能优化 ---- ORACLE数据库的ASH

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次...
复制链接

扫一扫