Real-Time SQL Monitoring

Real-Time SQL Monitoring可以在sql运行的时候监控其性能。 缺省情况下,单个sql执行花费的CPU或I/O时间超过5秒或sql并行执行的时候,Real-Time SQL Monitoring会自动启动。

可以通过视图v$sql_monitor、v$sql_plan_monitor来查看sql语句运行时的统计信息。

在结合以下视图,可以获取更多的信息: v$active_session_history、v$session、v$session_longops、v$sql、v$sql_plan

一旦开始监控,就会在v$sql_monitor中增加一个entry,包含性能统计信息。执行结束后,对应的entry不会立即删除,而是会保留一分钟。 v$sql_monitor和v$sql不同,前者中的一个entry对应一个单独执行的语句;后者是累积的结果。

对于那些执行计划特多的查询sql,如果超出了隐含参数"_sqlmon_max_planlines"的设置,默认是300,sql monitor为了减少开销(cpu和内存)就不会再监控。
可以动态修改该参数:

SQL> alter system set "_sqlmon_max_planlines"=500 scope=both;

1.Real-Time SQL Monitoring主要包含以下方面的内容:

(1).SQL Plan Monitoring 实时sql监控也包含监控执行计划中每一步操作的统计信息。可以通过v$sql_plan_monitor查看。统计信息的保存周期和v$sql_monitor类似。v$sql_plan_monitor中对应一条sql会有多个entry。

(2).Parallel Execution Monitoring 并行查询、并行ddl、并行dml会被实时sql监控自动监控。

2.产生实时sql监控报告

实时sql监控报告会涉及以下视图:

gv$sql_monitor、gv$sql_plan_monitor、gv$sql、gv$sql_plan、gv$active_session_history、gv$session_longops

dbms_sqltune.report_sql_monitor可以返回一个指定sql的监控报告

SQL> var my_rept clob;
SQL> begin
  2     :my_rept := dbms_sqltune.report_sql_monitor(); #默认是text格式,还有html、xml格式
  3  end;
  4  /

PL/SQL procedure successfully completed.

SQL> print :my_rept

以html格式查看某个sql的sql monitor报告:

SET LONG 1000000
SET FEEDBACK OFF
spool monitor_sql.html
SELECT DBMS_SQLTUNE.report_sql_monitor(sql_id =>‘‘0tqfh0cggfg0v‘,type=> ‘HTML‘)
AS report FROM dual;
spool off

以text格式查看某个sql的sql monitor报告:

SET LONG 1000000
SET LONGCHUNKSIZE 1000000
SET LINESIZE 1000
SET PAGESIZE 0
SET TRIM ON
SET TRIMSPOOL ON
SET ECHO OFF
SET FEEDBACK OFF

SELECT DBMS_SQLTUNE.report_sql_monitor(sql_id => ‘<sql_id>‘, type => ‘TEXT‘)
AS report FROM dual;

TEXT结果示例:

set long 10000000
set longchunksize 10000000
set linesize 200
select dbms_sqltune.report_sql_monitor from dual;

SQL Text
----------------------------------------------------------------------------------------
select * from (select O_ORDERDATE, sum(O_TOTALPRICE)
               from  orders o, lineitem l
               where l.l_orderkey = o.o_orderkey
               group by o_orderdate
               order by o_orderdate) where rownum < 100
----------------------------------------------------------------------------------------

Global Information
 Status              :  EXECUTING		#正在执行
 Instance ID         :  1
 Session ID          :  980
 SQL ID              :  br4m75c20p97h
 SQL Execution ID    :  16777219
 Plan Hash Value     :  2992965678
 Execution Started   :  06/07/2007 08:36:42
 First Refresh Time  :  06/07/2007 08:36:46
 Last Refresh Time   :  06/07/2007 08:40:02

-----------------------------------------------------------------------------------
| Elapsed |   Cpu   |    IO    | Application |  Other   | Buffer | Reads | Writes |
| Time(s) | Time(s) | Waits(s) |  Waits(s)   | Waits(s) |  Gets  |       |        |
-----------------------------------------------------------------------------------
|     198 |     140 |       56 |        0.31 |     1.44 |  1195K | 1264K |  84630 |
-----------------------------------------------------------------------------------

SQL Plan Monitoring Details
# Time Active(s): 该步操作持续的active的时间,单位是秒
# Start Active: 该步操作在执行计划中相对于sql开始执行时的时间,单位是秒
=======================================================================================
| Id   |         Operation          |   Name   |  Rows   | Cost  |   Time    | Start  |
|      |                            |          | (Estim) |       | Active(s) | Active |
=======================================================================================
|    0 | SELECT STATEMENT           |          |         |  125K |           |        |
|    1 |   COUNT STOPKEY            |          |         |       |           |        |
|    2 |    VIEW                    |          |    2406 |  125K |           |        |
|    3 |     SORT GROUP BY STOPKEY  |          |    2406 |  125K |        99 |   +101 |
| -> 4 |      HASH JOIN             |          |   8984K |  123K |       189 |    +12 |
|      |                            |          |         |       |           |        |
|    5 |       INDEX FAST FULL SCAN | I_L_OKEY |   8984K | 63191 |        82 |     +1 |
|      |                            |          |         |       |           |        |
|    6 |       PARTITION RANGE ALL  |          |  44913K | 57676 |        94 |    +84 |
|    7 |        PARTITION HASH ALL  |          |  44913K | 57676 |        94 |    +84 |
|    8 |         TABLE ACCESS FULL  | ORDERS   |  44913K | 57676 |        95 |    +84 |
|      |                            |          |         |       |           |        |
|      |                            |          |         |       |           |        |
=======================================================================================

continuation of above table
# Starts:表示在执行计划中运行的次数
# Rows (Actual): 产生的行数
# Activity (percent):所用的数据库时间占整个执行计划的百分比
# Activity Detail(sample #):显示活动的本质,比如cpu、等待事件
=======================================================================================
 Starts |   Rows   | Memory | Temp | Activity  |      Activity Detail      | Progress |
        | (Actual) |        |      | (percent) |        (sample #)         |          |
=======================================================================================
      1 |          |        |      |           |                           |          |
      1 |          |        |      |           |                           |          |
      1 |          |        |      |           |                           |          |
      1 |        0 |        |      |      4.02 | Cpu (8)                   |          |
      1 |   28130K | 10000K | 724M |     25.13 | Cpu (48)                  | 87%      |
        |          |        |      |           | direct path read temp (2) |          |
      1 |   32734K |        |      |     34.17 | Cpu (58)                  | 100%     |
        |          |        |      |           | direct path read (10)     |          |
      1 |   45000K |        |      |           |                           |          |
     84 |   45000K |        |      |           |                           |          |
    672 |   45000K |        |      |     36.68 | Cpu (28)                  |          |
        |          |        |      |           | reliable message (3)      |          |
        |          |        |      |           | direct path read (42)     |          |
=======================================================================================

列出v$sql_monitor中的sql语句:

SET LINESIZE 300
COLUMN sql_text FORMAT A100
SELECT sql_id, status, sql_text FROM v$sql_monitor;

3.开启/关闭实时sql监控
当参数statistic_level设置为typical、all的时候,实时sql自动监控就自动开启了。
同时control_management_pack_access要被设置为DIAGNOSTIC+TUNING,因为sql监控属于调优包组件。

也可以使用hint开启/关闭:

select /+monitor+/ from dual;
select /+no_monitor+/ from dual;
时间: 2024-10-12 22:17:15

Real-Time SQL Monitoring的相关文章

【SQL Performance】实时SQL监控功能(Real-Time SQL Monitoring)

概述 使用条件 监视对象 查看实时SQL监控结果的方法 DBMS_SQLTUNE包的以下子程序包 动态视图 Enterprise ManagerEM 相关参数 各版本变化 实时SQL监控使用的例子 参考 概述 实时SQL监控功能(Real-Time SQL Monitoring)是Oracle11g推出的功能,通过这个功能可以实时地监视执行中的SQL性能. 使用条件 要想使用实时SQL监控功能(Real-Time SQL Monitoring),必须满足以下几个条件 ?EE版本,购买了Diagn

Real-Time SQL Monitoring using DBMS_SQLTUNE

Real-Time SQL Monitoring reports are available from three locations: Enterprise Manager - Click the "Performance" tab, then the "SQL Monitoring" link at the bottom-right of the page to display the "Monitored SQL Executions" s

sql monitor生成不了报告&amp; FFS hint不生效两个问题思考

事情的发生就是这么偶然,一步步的深入才能汲取到更深入的知识~~ -------------------START-------------------------------------------   来了一个query running longer than 4hours的邮件,来看看里面有哪些sql: SID    SERIAL#    INST_ID SQL_ID        Run_in_sec OS_user     MACHINE       SQL_TEXT         

使用Operations Manager监视Windows Server和SQL Server

在这个实验章节中通过监控Windows Server.SQL Server.来了解使用Operations Manager监控企业基础架构.这里需要下载 1. System Center Management Pack for Windows Server Operating System管理包 2. System Center Management Pack for SQL Server管理包 http://down.51cto.com/data/1895686 一. 监视Windows Se

EBS_DBA_优化:掌握SQL Monitor这些特性,SQL优化将如有神助! (转)

SQL分析的苦与痛 对于线上的SQL语句,很多DBA都总会有一些疑问,看着执行计划cost还不错,但是实际执行的时候效果却有天壤之别,这是为什么呢? 对于一个庞大的SQL语句,看着得到的执行计划却不知道瓶颈在哪里,SQL语句太复杂,执行计划看起来更复杂,要读明白它掌握要领也不是一件容易的事情. 偶尔会有一些朋友问我,怎么去读一个执行计划,这个无论说得怎么细,似乎都不得要领,毕竟纯文字描述和图形的效果还是有很大的差别. 如果你在11g的版本中,SQL Monitor就是一个大大的福利,上面的问题可

Oracle 11g实时SQL监控 v$sql_monitor

Oracle 11g实时SQL监控: 前面提到,在Oracle Database 11g中,v$session视图增加了一些新的字段,这其中包括SQL_EXEC_START和SQL_EXEC_ID, 这两个字段实际上代表了Oracle 11g的一个新特性:实时的SQL监控(Real Time SQL Monitoring). 在Oracle 11g之前的版本,长时间运行的SQL可以通过监控v$session_longops来观察,当某个操作执行时间超过6秒, 就会被记录在v$session_lo

Oracle 11g Articles

发现一个比较有意思的网站,http://www.oracle-base.com/articles/11g/articles-11g.php Oracle 11g Articles Oracle Database 11g: New Features For Administrators OCP Exam Articles Oracle Database 11g Release 1: Miscellaneous Articles Oracle Database 11g Release 2: Misc

Oracle内存管理(之五)

[深入解析--eygle]学习笔记 1.4. 2其他内存组件 Large Pool-大池是SGA的一个可选组件,通常用于共享服务器模式(MTS). 并行计算或 RMAN的备份恢复等操作. Java Pool-Java池主要用于JVM等Java选件. Streams Pool-Streams pool是Oracle10g引入的概念,为Oracle的Streams功能所使用,如果不定义该参数,这部分内存将从Shread Pool中分配 对于SGA各部分内存分配,可以从数据库的视图中查询得到: 17:

Oracle ErrorStack 使用和阅读详解

一.概述 在Oracle数据库运行过程中,我们经常会遇到这样或那样的错误,但是错误的提示并不具体,加大了我们在诊断问题时的难度. ErrorStack是Oracle提供的一种对于错误堆栈进行跟踪的方法,通过设置跟踪可以将一些指定错误的后台信息详细的转储出来,写入跟踪文件,帮助我们诊断问题. 备注: 1.当oracle发生关键的错误诸如:ora-600,Errorstack是自动被oracle dump写入trace文件中. 2.当你在alert.log里面看见这类错误,并提示已经产生trace文