Memory Statistics
~~~~~~~~~~~~~~~~~ Begin End
------------ ------------

Host Mem (MB): 16,338.5 16,338.5
SGA use (MB): 3,072.0 3,072.0
PGA use (MB): 805.1 861.7
% Host Mem used for SGA+PGA: 23.73 24.08

异常响应:

Physical read (blocks): 35,368.4 3,067.3
Physical write (blocks): 6.8 0.6

Tota Wait % DB
Event Waits Time Avg(ms) time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
direct path read 912,622 306. 336 79.2 User I/O
read by other session 119,841 51.5 430 13.3 User I/O
log file sync 41,849 9467 226 2.4 Commit
db file scattered read 15,466 6459 418 1.7 User I/O
enq: TX - row lock contention 2 5208 2.6E+06 1.3 Applicatio
DB CPU 3868 1.0
db file sequential read 6,447 1635 254 .4 User I/O
Disk file operations I/O 691 534. 774 .1 User I/O
control file sequential read 377 167. 445 .0 System I/O
log file switch (private stran 5 39.3 7851 .0 Configurat

Physical Reads Elapsed
Reads Executions per Exec %Total Time (s) %CPU %IO SQL Id
----------- ----------- ---------- ------ ---------- ------ ------ -------------
1.23682E+08 7,632 16,205.7 97.7 306,686.8 1.0 98.9 ak7k07x5y8q12
SELECT this_.ID as ID49_0_, this_.LICENCE as LICENCE49_0_, this_.TYPE as TYPE49_
0_, this_.ROAD_TYPE as ROAD4_49_0_, this_.SPEED as SPEED49_0_, this_.STARTTIME a
s STARTTIME49_0_, this_.ENDTIME as ENDTIME49_0_ FROM VI_EXTERNALWARNING this_ WH
ERE this_.ENDTIME = :p0

一.DirectPath Reads 说明
在oracle 11g以前的版本中,如果对大表进行全表扫描,wait event是:db file scattered read;在11g中,如果对大表进行全表扫描,wait event是:direct path read;即在11g中,大表全表扫描是将数据块直接读入会话的pga区域。(具体的查看方法参考后面的示例)。
在11g中,大表全表扫描时数据块不经过sga而直接进pga,这样会造成每次进行大表全表扫描,物理读都是很大,而在10g中,由于全表扫描的数据块在sga中已经存在,所以执行全表扫描时,它的物理读为0。
但是这里主要是Oracle在优化策略上的进步,即假定大表频繁全表扫描这种现象,在生产库上不会太多,通过把数据直接读入pga,进而减少了cachebuffer的繁忙交换程度,提高了cachebuffer的使用效率.

Elapsed Elapsed Time
Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id
---------------- -------------- ------------- ------ ------ ------ -------------
306,686.8 7,632 40.18 79.3 1.0 98.9 ak7k07x5y8q12
SELECT this_.ID as ID49_0_, this_.LICENCE as LICENCE49_0_, this_.TYPE as TYPE49_
0_, this_.ROAD_TYPE as ROAD4_49_0_, this_.SPEED as SPEED49_0_, this_.STARTTIME a
s STARTTIME49_0_, this_.ENDTIME as ENDTIME49_0_ FROM VI_EXTERNALWARNING this_ WH
ERE this_.ENDTIME = :p0

SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR('ak7k07x5y8q12',0));
该sql 使用到全表扫描,请优化

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID ak7k07x5y8q12, child number 0
-------------------------------------
SELECT this_.ID as ID49_0_, this_.LICENCE as LICENCE49_0_, this_.TYPE
as TYPE49_0_, this_.ROAD_TYPE as ROAD4_49_0_, this_.SPEED as
SPEED49_0_, this_.STARTTIME as STARTTIME49_0_, this_.ENDTIME as
ENDTIME49_0_ FROM VI_EXTERNALWARNING this_ WHERE this_.ENDTIME = :p0

Plan hash value: 3931375654

--------------------------------------------------------------------------------
-----------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes |
Cost (%CPU)| Time |

--------------------------------------------------------------------------------
-----------------------

| 0 | SELECT STATEMENT | | | |
11048 (100)| |

| 1 | VIEW | VI_EXTERNALWARNING | 4 | 468 |

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
11048 (1)| 00:02:13 |

| 2 | UNION-ALL | | | |
| |

|* 3 | FILTER | | | |
| |

|* 4 | TABLE ACCESS FULL| MG_EXTERNAL_SPEED_WARNING | 1 | 55 |
3 (0)| 00:00:01 |

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
|* 5 | FILTER | | | |
| |

|* 6 | TABLE ACCESS FULL| MG_EXTERNAL_RESTRICTED_WARNING | 1 | 88 |
2 (0)| 00:00:01 |

|* 7 | FILTER | | | |
| |

|* 8 | TABLE ACCESS FULL| MG_EXTERNAL_IDLE_WARNING | 1 | 49 |
6631 (1)| 00:01:20 |

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

|* 9 | FILTER | | | |
| |

|* 10 | TABLE ACCESS FULL| MG_EXTERNAL_LONGTIMEXT_WARNING | 1 | 49 |
4412 (1)| 00:00:53 |

--------------------------------------------------------------------------------
-----------------------

主要是 I/O 吞吐慢

方向1:
请OA 检查6.101 的 IO,是否正常

方向2: 业务检查ak7k07x5y8q12 是否正常 ,此sql 消耗大量I/O

Physical Reads Elapsed
Reads Executions per Exec %Total Time (s) %CPU %IO SQL Id
----------- ----------- ---------- ------ ---------- ------ ------ -------------
1.23682E+08 7,632 16,205.7 97.7 306,686.8 1.0 98.9 ak7k07x5y8q12
SELECT this_.ID as ID49_0_, this_.LICENCE as LICENCE49_0_, this_.TYPE as TYPE49_
0_, this_.ROAD_TYPE as ROAD4_49_0_, this_.SPEED as SPEED49_0_, this_.STARTTIME a
s STARTTIME49_0_, this_.ENDTIME as ENDTIME49_0_ FROM VI_EXTERNALWARNING this_ WH
ERE this_.ENDTIME = :p0

正常响应:

Physical read (blocks): 14,991.1 99.8
Physical write (blocks): 21.4 0.1

Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tota Wait % DB
Event Waits Time Avg(ms) time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
DB CPU 2768 35.5
direct path read 193,541 2075 11 26.6 User I/O
db file scattered read 500,821 1465 3 18.8 User I/O
read by other session 423,225 1165 3 14.9 User I/O
log file sync 542,810 329. 1 4.2 Commit
db file sequential read 106,779 157. 1 2.0 User I/O
SQL*Net message to client 7,250,622 27.9 0 .4 Network
control file sequential read 771 5 6 .1 System I/O
Disk file operations I/O 1,434 2.8 2 .0 User I/O
SQL*Net more data to client 25,644 1.2 0 .0 Network

CPU CPU per Elapsed
Time (s) Executions Exec (s) %Total Time (s) %CPU %IO SQL Id
---------- ------------ ---------- ------ ---------- ------ ------ -------------
4,683.6 11,456 0.41 52.7 4,764.1 98.3 .0 ak7k07x5y8q12
SELECT this_.ID as ID49_0_, this_.LICENCE as LICENCE49_0_, this_.TYPE as TYPE49_
0_, this_.ROAD_TYPE as ROAD4_49_0_, this_.SPEED as SPEED49_0_, this_.STARTTIME a
s STARTTIME49_0_, this_.ENDTIME as ENDTIME49_0_ FROM VI_EXTERNALWARNING this_ WH
ERE this_.ENDTIME = :p0

数据库执行计划慢导致I/O 慢的更多相关文章

  1. MySQL数据库执行计划(简单版)

    +++++++++++++++++++++++++++++++++++++++++++标题:MySQL数据库执行计划简单版时间:2019年2月25日内容:MySQL数据库执行计划简单版重点:MySQL ...

  2. SQL Server中参数化SQL写法遇到parameter sniff ,导致不合理执行计划重用的一种解决方案

    parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的 ...

  3. SQL Server 执行计划缓存

    标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之 ...

  4. 谈一谈SQL Server中的执行计划缓存(下)

    简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优 ...

  5. 官方文档:11G新特性SQL PLAN BASLINE 执行计划基线

    什么是SQL执行计划管理? SQL计划管理(SQL plan management)是一咱预防机制,记录和评估SQL语句的执行计划.SQL plan management的主要功能是sql plan ...

  6. Oracle sql执行计划解析

    Oracle sql执行计划解析 https://blog.csdn.net/xybelieve1990/article/details/50562963 Oracle优化器 Oracle的优化器共有 ...

  7. MySql的执行计划

    一.什么是数据库执行计划: MySQL执行计划是sql语句经过查询优化器后,查询优化器会根据用户的sql语句所包含的字段和内容数量等统计信息,选择出一个执行效率最优(MySQL系统认为最优)的执行计划 ...

  8. Oracle数据库查看执行计划

    基于ORACLE的应用系统很多性能问题,是由应用系统SQL性能低劣引起的,所以,SQL的性能优化很重要,分析与优化SQL的性能我们一般通过查看该SQL的执行计划,本文就如何看懂执行计划,以及如何通过分 ...

  9. mysql数据库备份执行计划

    为什么需要数据备份?如果数据库因为人为或其他不可控的因素导致数据库数据丢失或损坏,导致的后果将会非常严重. 为什么需要执行计划?备份操作如果每天人工管理的话,将会非常麻烦,需要借助工具来制定执行计划, ...

随机推荐

  1. 区分Integer.getInteger和Integer.valueOf、Integer.parseInt() 的使用方法

    Integer类有两个看起来很类似的静态方法,一个是Integer.getInteger(String),另外一个是Integer.valueOf(String).如果只看方法名称的话,很容易将这两个 ...

  2. 在开发过程中,如何在手机上测试vue-cli构建的项目

    由于有时候谷歌手机调试与真是的手机环境还是有一定的差距,所以需要在手机上测试项目. 手机上测试vue-cli构建项目方法: 打开项目config/index.js文件,找到module.exports ...

  3. Python的字符串和列表和字典的方法/函数

    字符串 S.find()#可指定范围查找字串,返回索引值,否则返回-1 S.index()#同find,只是找不到的之后返回异常 S.count()#返回找到字串的个数 S.lower()#转小写 S ...

  4. Linux(Ubuntu14.04)下Google Chrome / Chromium标题栏乱码问题

    注:我使用的Linux发行版是Ubuntu 14.04,不同Linux发行版可能会有不同. 最近在使用Chromium的时候tab的标题栏中文显示乱码,在地址栏输入中文是同样时乱码,就像下图: 看起来 ...

  5. Openstack-Ceilometer-获取主机内存 的使用

    1. 物理server配置 1.1安装 參考 http://blog.csdn.net/qq_21398167/article/details/47019751 1.2      配置 关闭selin ...

  6. Fluently NHibernate 插入CLOB字段

    ORA-01461: can bind a LONG value only for insert into a LONG column 插入oracle某表时报的错. 查来查去,是插入的某个字段值超长 ...

  7. Apache Flink 1.5.0 Release Announcement

    Apache Flink: Apache Flink 1.5.0 Release Announcement https://flink.apache.org/news/2018/05/25/relea ...

  8. What's the difference between jquery.js and jquery.min.js?

    They are both the same functionally but the .min one has all unnecessary characters removed in order ...

  9. RabbitMQ(三)RabbitMQ消息过期时间(TTL)

    在RabbitMQ(二)AMQP协议mandatory和immediate标志位区别中我们提到,在RabbitMQ3.0以后的版本里,去掉了immediate参数支持,要实现类似的确认功能要使用TTL ...

  10. 并不对劲的bzoj3932: [CQOI2015]任务查询系统

    传送门-> 离线操作听上去很简单,遗憾的是它强制在线. 每个时刻可以看成可持久化线段树中的一个版本,而每一个版本的线段树维护的是值某一段区间且在这个版本对应的时刻出现的数之和. 会发现同一时刻可 ...