python sqlparse_SQL Parse

Parse CPU to Parse Elapsed%是一个我们在分析AWR报告时常会看到的解析性能指标,该指标反映了 快照内解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time); 若该指标水平很低,那么说明在整个解析过程中 实际在CPU上运算的时间是很短的,而主要的解析时间都耗费在各种其他非空闲的等待事件上了(如latch:shared pool,row cache lock之类等), 通过该指标我们可以了解是否有必要来调优Oracle的优化器Optimizer的解析(parse)工作, 调优的对象包括软、硬解析(soft and hard parse),理论上我们的目标是有极少的硬解析,少量的软解析,以及Parse CPU to Parse Elapsed% 接近于100% 相当于解析时都是在CPU上运算 而不等待, 所以Parse CPU to Parse Elapsed%也同时给我们以调优方向的启示。

Soft Parse %是AWR中另一个重要的解析指标,该指标反应了快照时间内 软解析次数 和 总解析次数 (soft+hard 软解析次数+硬解析次数)的比值,若该指标很低,那么说明了可能存在剧烈的hard parse硬解析,大量的硬解析会消耗更多的CPU时间片并产生解析争用(此时可以考虑使用cursor_sharing=FORCE); 理论上我们总是希望 Soft Parse % 接近于100%, 但并不是说100%的软解析就是最理想的解析状态,通过设置 session_cached_cursors参数和反复重用游标我们可以让解析来的更轻量级,即通俗所说的利用会话缓存游标实现的软软解析(soft soft parse)。

其他一些对于tuning SQL parse调优SQL解析有帮助的指标信息:

Reloads:

Library Cache Activity -> SQL Area reloads 信息,该指标反映了 游标被重新加载到shared pool共享池中的次数,引起reload重新装载的原因可能是共享游标失效Invalidation (失效可能由DDL等操作引起),也可能由shared pool共享池Free memory空闲内存过少导致sql reloads;reloads往往意味着本来可能已经被解析好的SQL语句,需要再次经历硬解析才能使用。

Library Cache Activity

“Pct Misses” should be very low

Namespace

Get Requests

Pct Miss

Pin Requests

Pct Miss

Reloads

Invali- dations

BODY

245

0.41

1,835

0.05

0

0

CLUSTER

665

0.00

155

0.00

0

0

DBLINK

1,020

0.00

0

0

0

EDITION

34

0.00

52

0.00

0

0

INDEX

308

3.90

244

10.66

14

0

OBJECT ID

273

100.00

0

0

0

QUEUE

5

0.00

762

0.00

0

0

RULESET

2

0.00

2

0.00

0

0

SCHEMA

1,077

0.00

0

0

0

SQL AREA

3,224

29.44

30,256

2.92

119

89

SUBSCRIPTION

1

0.00

1

0.00

0

0

TABLE/PROCEDURE

6,210

0.55

8,069

2.12

40

0

TRIGGER

182

0.00

188

0.00

0

0

High version Count:

在Oracle中同样的SQL语句可能被硬解析成不同的子游标(child cursor),一句SQL statement拥有过多的child cursor(例如超过50个子游标)往往说明游标无法被共享,若游标无法被共享使用那么只好每一次都再次硬解析和生成更多的子游标了,可以通过v$sql_shared_cursor来了解具体无法共享游标的原因。 实际引起SQL High Version Count的原因可能有很多,这里不再一一列举,特别需要注意的是以下2个Note涉及到的问题:

AWR中提供了SQL ordered by Version Count信息方便用户了解该指标

SQL ordered by Version Count

Only Statements with Version Count greater than 20 are displayed

Version Count

Executions

SQL Id

SQL Module

SQL Text

37

4

python.exe

select * from www.askmaclean.com

32

0

SELECT COUNT(CLIENT_INFO) FROM…

30

0

SELECT DECODE(COUNT(CLIENT_INF…

27

24

MMON_SLAVE

select tablespace_id, rfno, al…

26

24

MMON_SLAVE

select * from www.askmaclean.com

24

4

SELECT a.name task_name, nvl(e…

24

8

SELECT dbin.instance_number, d…

24

4

SELECT owner#, property FROM s…

24

4

SELECT advisor_id FROM sys.wri…

22

4

SELECT (m.current_size / 10485…

具体的high version count诊断步骤:

1 select sql_text, hash_value,address from v$sqlarea where sql_id ='{sql id

from AWR>}'

2 select * from v$sql_shared_cursor where address =

3 SELECT sql_text,version_count,address FROM V$SQLAREA order by version_count desc;

4 From step 3 , take the sql with highest version count and put in below

SELECT * FROM V$SQL_SHARED_CURSOR WHERE address = 'HERE';

5. 检查 参数 NLS_LENGTH_SEMANTICS  What is the value of NLS_LENGTH_SEMANTICS ?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值