生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时间有1,2分钟左右,但是sql语句本身有潜在的性能问题,通过awr是定位不到的,ash尽管能够查到,但是我们在未知的情况下怎么知道问题发生的精确时间点,通过sql monitor能够查到一些实时的性能问题,但是还是需要按照自己的情况和要求来不间断地进行性能的监控。通过一个工具一劳永逸是不现实的。
今天想做数据迁移也有些日子了,看看生产环境中有哪些sql语句出现频繁,而且有明显的性能问题。
关于通过shell和sql查找性能sql的部分,可以参考如下的帖子,基本原理就是后台做sql_monitor的监控,然后由shell进行性能数据的统计。
http://blog.itpub.net/23718752/viewspace-1253426/
通过如下的sql语句定位到目前有如下的几个sql语句出现频繁,执行时间较长。
select *from (select sql_id,count(*)cnt from issue_sql where sql_date like '1408%' group by sql_id) order by cnt desc;
SQL_ID CNT
------------------------------ ----------
ap6dzwkwk4zrw 26
xxxxxxxxxxxxx
一般出现性能问题的sql语句执行时间都较长。
可以看到如下的sql语句执行时间很不稳定,最长执行时间差不多在5000多秒。最短在50秒左右。
Instance ID | : | 1 |
|
||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Session | : | xxxxxx(1925:53293) | |||||||||||||||||||
SQL ID | : | ap6dzwkwk4zrw | |||||||||||||||||||
SQL Execution ID | : | 16777216 | |||||||||||||||||||
Execution Started | : | 09/06/2014 16:40:45 | |||||||||||||||||||
First Refresh Time | : | 09/06/2014 16:40:51 | |||||||||||||||||||
Last Refresh Time | : | 09/06/2014 18:06:34 | |||||||||||||||||||
Duration | : | 5149s | |||||||||||||||||||
Module/Action | : | JDBC Thin Client/- | |||||||||||||||||||
Service | : | xxxxxx | |||||||||||||||||||
Program | : | JDBC Thin Client |
Instance ID | : | 1 |
|
||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Session | : | xxxxx(7425:49389) | |||||||||||||||||||
SQL ID | : | ap6dzwkwk4zrw | |||||||||||||||||||
SQL Execution ID | : | 16777216 | |||||||||||||||||||
Execution Started | : | 09/09/2014 07:05:34 | |||||||||||||||||||
First Refresh Time | : | 09/09/2014 07:05:40 | |||||||||||||||||||
Last Refresh Time | : | 09/09/2014 07:07:20 | |||||||||||||||||||
Duration | : | 107s | |||||||||||||||||||
Module/Action | : | JDBC Thin Client/- | |||||||||||||||||||
Service | : | xxxx | |||||||||||||||||||
Program | : | JDBC Thin Client |
通过查看执行计划,发现瓶颈在做递归查询的时候。其实那个表很小的,数据不到100条,但是怎么递归出来了百万的数据呢。
-> | 7 | ..... CONNECT BY WITHOUT FILTERING (UNIQUE) |
. |
. |
. |
|
1 | 12M |
. |
. |
|
|
|
相关的语句如下:
SELECT DISTINCT REGEXP_SUBSTR(PARAM_VALUES, '[^,]+', 1, LEVEL) AS SOC_NAME
FROM CM9_BATCH_CONTROL
WHERE PARAM_NAME = 'OFFER'
AND JOB_NAME = 'xxxxxxx'
AND JOB_REC = 'ENDDAY'
CONNECT BY REGEXP_SUBSTR((SELECT PARAM_VALUES
FROM CM9_BATCH_CONTROL
WHERE JOB_NAME = 'xxxxx'
AND PARAM_NAME = 'OFFER'),
'[^,]+',
1,
LEVEL) IS NOT NULL;
化繁为简,先来看一下这个语句想要做什么,通过下面的查询,发现出现了一些列值按照逗号进行分隔。
SELECT PARAM_VALUES
FROM CM9_BATCH_CONTROL
WHERE JOB_NAME = 'xxxxx'
AND PARAM_NAME = 'OFFER'
PARAM_VALUES
--------------------------------------------------------------------------------
ROHOMS01,ROHOMS02,TESTVDF01,TESTVDF02
可以猜想最开始的想法应该是要解析字符串,做一个行列转行。
在这个基础上去查看完整的语句就清楚了。
所以按照这个思路输出的结果应该是
SOC_NAME
--------------------------------------------------------------------------------
ROHOMS01
ROHOMS02
TESTVDF01
TESTVDF02
按照这个思路,可以给出如下的改进版本,这个语句的关键就在下面的标黄处。
生成一个类似dual表的虚表来存放一些需要的数据然后和基表做匹配。
SELECT CO.SOC_CD FROM (SELECT REGEXP_SUBSTR(PARAM_VALUES,'[^,]+',1,l) AS SOC_NAME
FROM CM9_BATCH_CONTROL
,(SELECT LEVEL l FROM DUAL CONNECT BY LEVEL
WHERE PARAM_NAME = 'OFFER'
AND JOB_NAME = 'xxxx'
AND JOB_REC = 'ENDDAY'
AND l
)T, CSM_OFFER CO WHERE T.SOC_NAME = CO.SOC_NAME
and T.SOC_NAME is not null
来看看执行的效果怎么样吧。
Elapsed: 00:00:00.05
生成的数据也是按照预期的格式进行了行列转换。