eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 恩墨科技为中国国际电子商务中心提供服务 | Blog首页 | 儿子 恩墨 登上了万里长城 - 黄花城 »

10g临时表空间组导致递归SQL高度解析案例

前几天在为客户提供服务时,发现客户的系统中,存在一条高解析执行的SQL:

Parse Calls

Executions

% Total Parses

SQL Id

SQL Module

SQL Text

21,220,546

21,298,871

78.62

8sph6b5p41afr

 

select min(bitmapped) from ts$...

531,686

531,682

1.97

8q7uku4ra1w29

JDBC Thin Client

SELECT * FROM te WHERE tei.........

这条SQL占据了78.62%的解析比重,在10小时的AWR报告采样中,共执行了2千多万次,平均每秒解析执行约600次,这个高解析执行的SQL引起了我的注意,其SQL的完整文本为:

select min(bitmapped) from ts$ where dflmaxext =:1 and bitand(flags, 1024) =1024

这条SQL直观判断是和系统递归调用相关的,查询了底层的ts$视图,如果跟踪一下普通查询,我们发现这个SQL都有很高的解析度。比如跟踪如下SQL查询:

SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.

SQL> select count(*) from dba_indexes;
  COUNT(*)
----------
      5890

tkprof格式化后台跟踪文件可以发现,在这个查询中,后台ts$递归查询高达3305次:

select min(bitmapped)
from
 ts$ where dflmaxext =:1 and bitand(flags,1024) =1024


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse     3305      0.02       0.04          0          0          0           0
Execute   3305      0.24       0.30          0          0          0           0
Fetch     6610      0.90       1.05          0     317280          0        3305
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    13220      1.16       1.39          0     317280          0        3305

而且逻辑读很高。

这使得我怀疑可能是某个Bug在作祟,检索Metalink,马上发现了相关Bug,bug号为:5455880。

该Bug的影响版本为:

Product (Component)

Oracle Server (Rdbms)

Range of versions believed to be affected

Versions < 11

Versions confirmed as being affected

Platforms affected

Generic (all / most platforms affected)

客户的数据库版本为10.2.0.2,正好在受影响之列,这个Bug是说,当使用了Oracle 10g的临时表空间组特性时,后台的递归SQL可能会发生高昂的解析及执行:

When using a tablespace group as the temporary tablespace
excessive recursive queried against TS$ can impact performance.
The offending SQL is of the form:
  "select min(bitmapped) from ts$  where dflmaxext =:1 and bitand(flags,1024)=1024"

这个Bug在10.2.0.4之后修正,暂时的解决方案是停用临时表空间组。

用户调整了临时表空间组的使用之后,这个SQL立即消失了,系统的解析等负载概要信息也发生了较大变化:

1st Per Sec

2nd Per Sec

%Diff

1st Per Txn

2nd Per Txn

%Diff

Parses:

743.69

145.64

-80.42

22.40

5.78

-74.20

Sorts:

4,534.49

2,670.65

-41.10

136.60

106.02

-22.39

Executes:

1,032.02

425.26

-58.79

31.09

16.88

-45.71

我们在使用Oracle的一些新特性时,一定要注意观察,看是否会引发一些新的问题,最近发现的几个Bug都和Oracle的一些新特性相关。

记录一下,供大家参考!

-The End-




历史上的今天...
    >> 2017-06-12文章:
    >> 2012-06-12文章:
    >> 2007-06-12文章:
           生如夏花
    >> 2006-06-12文章:
    >> 2005-06-12文章:

无觅

By eygle on 2009-06-12 10:21 | Comments (8) | Case | 2308 |

8 Comments

实在不认为临时表空间组能带来什么好处
为什么有点新东西大家就拼命的上列
也不管是否真的没有这个玩意业务就不能运行。

俺还是觉得
除非必须,否则不用新特性,毕竟没有经过大规模的检验。

你用用就有大规模检验了!

呵呵,2年多以前,我也碰到了这个BUG

http://zhang41082.itpub.net/post/7167/432285

大熊 的Blog很有技术含量,有没有整理好的文章?可以投稿给我正在编辑的 案例 书。

期待大师更详细的解释。。。

咦?
最后的那个 “系统的解析等负载概要信息” 这张表是怎么点出来的?我不知道在哪儿?

awr比较报告
用$ORACLE_HOME/rdbms/admin/awrddrpt.sql生成

大师怎么知道执行这个语句
select count(*) from dba_indexes;就一定会调用select min(bitmapped) from ts$ where dflmaxext =:1 and bitand(flags, 1024) =1024
,是猜测的还是一个一个试出来的

谢谢


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com