2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2010年6月 其他数据库开发大版内专家分月排行榜第二2010年6月 Oracle大版内专家分月排行榜第二2010年5月 其他数据库开发大版内专家分月排行榜第二
2011年1月 其他数据库开发大版内专家分月排行榜第三2010年12月 其他数据库开发大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。博客访问： 82224
博文数量： 280
注册时间：
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Oracle
原文地址： 作者：
一般来说一条sql语句执行个4秒钟是可以接受的，没有什么问题，但是如果应该执行1秒，却执行了4秒，问题就挺大的了。
今天查看数据库负载，发现在中午12:00 到1点之间，数据库的负载急剧增加，负载达到了百倍。
Cursors/Session
Begin Snap:
29-Sep-14 12:00:07
29-Sep-14 13:00:13
60.10 (mins)
8,575.93 (mins)
为了一看究竟，抓取了一个awr报告。
发现系统的负载情况确实很严重，每秒的redo有1.6M,可见系统的负载不是主要在select上，可能有一些dml之类的操作极为频繁。
Per Second
Per Transaction
DB Time(s):
DB CPU(s):
Redo size:
1,694,755.6
Logical reads:
Block changes:
Physical reads:
Physical writes:
User calls:
Hard parses:
W/A MB processed:
Rollbacks:
Transactions:
看了下等待事件。都是关于lock的。这个时候就有些纳闷了。到底什么样的操作会导致严重的锁等待。
Top 5 Timed Foreground Events
Avg wait (ms)
Wait Class
enq: TX - row lock contention
Application
log file sync
db file sequential read
35,361,005
read by other session
首先DB time极高，这个时候就可以关注一些elapsed time比较高的sql语句。
可以看到第一个sql语句占用了大量的时间，而且是一个dml语句。后面的几个都是select相关的，占用的比例不是很大，就没有全列出来。
Elapsed Time (s)
Executions
Elapsed Time per Exec (s)
SQL Module
235,032.84
JDBC Thin Client
update EC1_USER set SYS_UPDAT...
ORACLE.EXE
SELECT "A3"."SUBSCRIBER_NO", "...
JDBC Thin Client
selectNameAd...
这个时候怎么把这条sql语句和对应的等待时间关联起来呢，如果为了清晰方便，可以使用ash。
Top SQL with Top Events
Sampled # of Executions
% Activity
Top Row Source
enq: TX - row lock contention
update EC1_USER set SYS_UPDAT...
db file sequential read
INDEX - RANGE SCAN
selectNameAd...
db file sequential read
TABLE ACCESS - FULL
SELECT "A3"."SUBSCRIBER_NO", "...
read by other session
INDEX - UNIQUE SCAN
selectS...
问题基本确定了，是这条Update语句的执行极为频繁，但是执行时间达到了4秒。一个小时以内执行了5万多次。
但是为什么sql语句的执行时间这么长呢，是不是没有走索引，在简单排查了一下，索引是启用了的。
抓了一个awrsqrpt的报告。可以看到执行计划中的唯一性索引是启用了的，而且查取效率很多。0.01秒就查到了对应的记录，对于update的部分，不会那么慢把。
Execution Plan
Cost (%CPU)
UPDATE STATEMENT
&&&& INDEX UNIQUE SCAN
EC1_USER_PK
这个时候怎么解释执行计划效率很高，但是执行时间却很长的问题。
第一个猜想就是系统的负载加大了，可能查取数据的时候就慢了。但是反过来说，也不会慢这么高的比例啊。
所以这种猜想不成立的。
第二个猜想就是有大量的并发dml,同时做update,导致其他的一些Update就在等待。当然这种设计是有问题的。
但是时间已经过去了很久，v$session里面早就没有对应的记录了。怎么验证自己的猜想呢。
还是使用ash。里面有一个章节是blocking sessions的细节。
Blocking Sid (Inst)
% Activity
Event Caused
# Samples Active
log file sync
oracle@xxxx(LGWR)
97/360 [ 27%]
enq: TX - row lock contention
JDBC Thin Client
45/360 [ 13%]
enq: TX - row lock contention
JDBC Thin Client
44/360 [ 12%]
enq: TX - row lock contention
JDBC Thin Client
18/360 [ 5%]
793,65345( 1)
enq: TX - row lock contention
JDBC Thin Client
65/360 [ 18%]
通过这个就能看到有4个并发的session在同时做dml操作了。这样问题就能够基本定位了。
有了这些信息，就可以和开发部门协调。看看下一步该怎么改进了。
阅读(99) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。MSSQL新技术
共有224位成员 　 人气指数 - 　 最新排名 -
【话题】如何让执行一条SQL语句后，等待1秒后在输入下一条语句
05:45:17　来自:dingruohong 浏览数：47次
如何让执行一条SQL语句后，等待1秒后在输入下一条语句
雨后心情回复于20日05点53分　
auditjh回复于20日05点59分　
waitfor delay '00:00:01'
军人的力量回复于20日06点07分　
waitfor delay '00:00:01'
han323回复于20日06点14分　
waitfor delay '00:00:01'
songbin回复于20日06点21分　
--延迟多长时间执行
waitfor delay '00:00:01'
--延迟到几点
waitfor time '18:21:01'
dorothy回复于20日06点28分　
美知瑠可的杯子回复于20日06点35分　
waitfor delay '00:00:01'
溪水欢歌回复于20日06点42分　
--延迟多长时间执行
waitfor delay '00:00:01'
--延迟到几点
waitfor time '18:21:01'
数迷1号回复于20日06点48分　
waitfor delay '00:00:01'
DELAY 'time_to_pass'
| TIME 'time_to_execute'
| [ ( receive_statement ) | ( get_conversation_group_statement ) ]
[ , TIMEOUT timeout ]
可以继续执行批处理、存储过程或事务之前必须经过的指定时段，最长可为 24 小时。
'time_to_pass'
等待的时段。可以使用 datetime 数据可接受的格式之一指定 time_to_pass，也可以将其指定为局部变量。不能指定日期；因此，不允许指定 datetime 值的日期部分。
指定的运行批处理、存储过程或事务的时间。
'time_to_execute'
WAITFOR 语句完成的时间。可以使用 datetime 数据可接受的格式之一指定 time_to_execute，也可以将其指定为局部变量。不能指定日期；因此，不允许指定 datetime 值的日期部分。
receive_statement
有效的 RECEIVE 语句
MSSQL新技术的其他话题...
热门脚本语言：}