sql monitor的使用(一) (r2第30天)

在sql调优中,对于sql语句的实时监控显得尤为重要,如果某条sql语句的性能比较差。可能从前端的直观感觉就是执行时间比较长。 对于dba来说,可能关注的相关因素需要多一些. 1)可以通过top命令来监控sql的性能情况,查看cpu使用率较高的oracle process,然后通过查看session和process得绑定得到对应的session,然后得到对应的sql语句。 2) 如果已经过去了一段时间,而且在缓存中已经没有对应的sql语句了,可以通过awr得到一个大体的报告做分析,排查问题的大体范围,在这个基础上定位更精准的时间段,做一个ash。 3) 如果已经定位到sql_id了,想做进一步的分析,可以通过awrsqrpt来得到对应时间段的执行计划 。。。 对于执行计划的分析方式就更多了,但是oracle也提供了一些比较方便的功能集,你用或者不用,它就在那里。 sql monitor是一个实时的sql监控工具,11g里对dbms_tune做了不少的改进和提升。动态视图v$sql_monitor中有被监控的sql语句的一些明细信息。 一般对于执行时间超过5秒的sql语句,都会成为监控对象。 首先看看11g的库是否启用了这项功能 SQL> show parameter CONTROL_MANAGEMENT_PACK_ACCESS; control_management_pack_access string DIAGNOSTIC+TUNING 然后模拟一个大查询,做个并行,表t里面有150万左右的数据,我本地的机器查询奎尼丁超过5秒。 SQL> select /*+ parallel(8) */count(1) from t ; 1536604 然后查看v$sql_minotor set long 99999 set pages 0 set linesize 200 col status format a20 col username format a30 col module format a20 col program format a20 col sql_id format a20 col sql_text format a50 select STATUS , USERNAME , MODULE , PROGRAM, SQL_ID , SQL_TEXT from v$sql_monitor / DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) N1 SQL*Plus sqlplus@rac1 (TNS V1 21df1v060g0wq select /*+ parallel(8) */count(1) from t -V3) DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq DONE (ALL ROWS) 21df1v060g0wq 9 rows selected. 下面这个功能才是重点,生成报告。 这个报告风格类似awr,ash有html,text,xml的格式类型。输入sql_id就能得到具体的报告。 col comm format a200 SELECT dbms_sqltune.report_sql_monitor( sql_id => '21df1v060g0wq', report_level => 'ALL', type=>'TEXT' ) comm FROM dual; 展示一个文本格式的报告。 SQL Text ------------------------------ select /*+ parallel(8) */count(1) from t Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : N1 (254:77) SQL ID : 21df1v060g0wq SQL Execution ID : 16777216 Execution Started : 07/10/2014 06:40:49 First Refresh Time : 07/10/2014 06:40:52 Last Refresh Time : 07/10/2014 06:41:06 Duration : 17s Module/Action : SQL*Plus/- Service : SYS$USERS Program : sqlplus@rac1 (TNS V1-V3) Fetch Calls : 1 Global Stats ========================================================================================= | Elapsed | Cpu | IO | Concurrency | Other | Fetch | Buffer | Read | Read | | Time(s) | Time(s) | Waits(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | Bytes | ========================================================================================= | 114 | 1.81 | 108 | 2.67 | 1.14 | 1 | 8913 | 1193 | 68MB | ========================================================================================= Parallel Execution Details (DOP=8 , Servers Allocated=8) ============================================================================================================================================ | Name | Type | Server# | Elapsed | Cpu | IO | Concurrency | Other | Buffer | Read | Read | Wait Events | | | | | Time(s) | Time(s) | Waits(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | (sample #) | ============================================================================================================================================ | PX Coordinator | QC | | 3.10 | 0.04 | 0.01 | 2.67 | 0.38 | 5 | 1 | 8192 | os thread startup (3) | | p000 | Set 1 | 1 | 14 | 0.21 | 14 | | | 1075 | 143 | 8MB | direct path read (13) | | p001 | Set 1 | 2 | 14 | 0.23 | 13 | | 0.22 | 1190 | 158 | 9MB | direct path read (12) | | p002 | Set 1 | 3 | 14 | 0.21 | 14 | | | 1078 | 142 | 8MB | direct path read (12) | | p003 | Set 1 | 4 | 14 | 0.20 | 14 | | | 1030 | 139 | 8MB | direct path read (14) | | p004 | Set 1 | 5 | 14 | 0.25 | 13 | | 0.07 | 1166 | 156 | 9MB | direct path read (13) | | p005 | Set 1 | 6 | 14 | 0.22 | 13 | | 0.23 | 1074 | 145 | 8MB | direct path read (13) | | p006 | Set 1 | 7 | 14 | 0.25 | 14 | | | 1288 | 176 | 10MB | direct path read (14) | | p007 | Set 1 | 8 | 14 | 0.20 | 14 | | 0.23 | 1007 | 133 | 8MB | direct path read (13) | ============================================================================================================================================ SQL Plan Monitoring Details (Plan Hash Value=3126468333) ======================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (%) | (# samples) | ======================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +17 | 1 | 1 | | | | | | 1 | SORT AGGREGATE | | 1 | | 1 | +17 | 1 | 1 | | | | | | 2 | PX COORDINATOR | | | | 17 | +1 | 9 | 8 | | | 2.63 | os thread startup (3) | | 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | 1 | +17 | 8 | 8 | | | | | | 4 | SORT AGGREGATE | | 1 | | 14 | +4 | 8 | 8 | | | 0.88 | Cpu (1) | | 5 | PX BLOCK ITERATOR | | 2M | 338 | 13 | +5 | 8 | 2M | | | | | | 6 | TABLE ACCESS FULL | T | 2M | 338 | 14 | +4 | 115 | 2M | 1192 | 68MB | 96.49 | Cpu (6) | | | | | | | | | | | | | | direct path read (104) | ========================================================================================================================================================

文本格式的报告简单明了,但是html的报告来说更加清晰,而且还有额外的一些信息。性能瓶颈类问题,一目了然。

SQL Text

select /*+ parallel(8) */count(1) from t

SQL Plan Monitoring Details (Plan Hash Value=3126468333)

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-07-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏码神联盟

碎片化 | 第四阶段-51-Hibernate注解使用-视频

如清晰度低,可转PC网页观看高清版本: http://v.qq.com/x/page/y0568gleo8f.html 版权声明:本视频、课件属本公众号作者...

34710
来自专栏杨建荣的学习笔记

复杂SQL性能优化的剖析(一)(r11笔记第36天)

今天本来是处理一个简单的故障,但是发现是一环套一环,花了我快一天的时间。 开始是早上收到一条报警: 报警内容: CPUutilization is too hi...

35712
来自专栏小俊博客

[测评]云迪Host US-LA-SSD KVM Mini_384M VPS测评

最近博主买了KYRAHOST的LA CN2 VPS这款,SSD硬盘,从测试看,硬盘I/O还可以,有500-800左右,据商家说是SSD阵列RAID10,一个月才...

1151
来自专栏杨建荣的学习笔记

job处理缓慢的性能问题排查与分析(r4笔记第18天)

昨天开发的同事找到我说,生产有个job处理数据的速度很慢,想让我帮忙看看是怎么回事,最近碰到这种问题相对比较多了,但是问题的原因也是五花八门。我还是大体找他们了...

2856
来自专栏python3

django--ORM的单表操作

它的作用相当于 在该app下建立 migrations目录,并记录下你所有的关于modes.py的改动,比如0001_initial.py, 但是这个改动还没有...

1343
来自专栏杨建荣的学习笔记

一次数据库响应慢的问题诊断(r6笔记第39天)

今天接到开发一个同事的电话,说前端系统那边反馈有一个查询很慢,初步怀疑是有一些并发或者锁之类的问题导致的。 接到问题之后,自己还是带着一些的紧迫感来处理的。 首...

2725
来自专栏数据和云

极限优化:从75到2000,由技能到性能提升岂止20倍

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracl...

2484
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第十篇(r3笔记第39天)

陆陆续续写了九篇关于生产环境sql语句的调优案例,发现了不少问题,可能有些问题回头来看是比较低级的错误,稍加改动就能够运行在秒级,有些可能是在秒级到毫秒级的小步...

3375
来自专栏杨建荣的学习笔记

MySQL中的Online DDL(第一篇)(r11笔记第3天)

记得有一天快下班的时候,一位开发同事找到我说,需要对一个表做变更,数据量据说有上千万,而当时是使用的MySQL版本是5.5,这可如何是好,对于在线业务要求高的情...

3419
来自专栏杨建荣的学习笔记

使用shell来定制dbms_sqltune(r7笔记第39天)

在sql调优中使用dbms_sqltune是一个很高效的工具,如果说awr发现了性能问题sql,addm可以给出调优建议,sql monitor能够监控性能问...

3174

扫码关注云+社区