数据库执行计划慢导致I/O 慢
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 慢的更多相关文章
- MySQL数据库执行计划(简单版)
+++++++++++++++++++++++++++++++++++++++++++标题:MySQL数据库执行计划简单版时间:2019年2月25日内容:MySQL数据库执行计划简单版重点:MySQL ...
- SQL Server中参数化SQL写法遇到parameter sniff ,导致不合理执行计划重用的一种解决方案
parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的 ...
- SQL Server 执行计划缓存
标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之 ...
- 谈一谈SQL Server中的执行计划缓存(下)
简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优 ...
- 官方文档:11G新特性SQL PLAN BASLINE 执行计划基线
什么是SQL执行计划管理? SQL计划管理(SQL plan management)是一咱预防机制,记录和评估SQL语句的执行计划.SQL plan management的主要功能是sql plan ...
- Oracle sql执行计划解析
Oracle sql执行计划解析 https://blog.csdn.net/xybelieve1990/article/details/50562963 Oracle优化器 Oracle的优化器共有 ...
- MySql的执行计划
一.什么是数据库执行计划: MySQL执行计划是sql语句经过查询优化器后,查询优化器会根据用户的sql语句所包含的字段和内容数量等统计信息,选择出一个执行效率最优(MySQL系统认为最优)的执行计划 ...
- Oracle数据库查看执行计划
基于ORACLE的应用系统很多性能问题,是由应用系统SQL性能低劣引起的,所以,SQL的性能优化很重要,分析与优化SQL的性能我们一般通过查看该SQL的执行计划,本文就如何看懂执行计划,以及如何通过分 ...
- mysql数据库备份执行计划
为什么需要数据备份?如果数据库因为人为或其他不可控的因素导致数据库数据丢失或损坏,导致的后果将会非常严重. 为什么需要执行计划?备份操作如果每天人工管理的话,将会非常麻烦,需要借助工具来制定执行计划, ...
随机推荐
- ICONFONT在APP中的使用
阿里IconFont平台 http://www.iconfont.cn/ 这里是阿里巴巴UED部门开发的IconFont平台,眼下阿里系的重量级产品都在使用,里面有非常多资源可供使用. 这里说说怎样在 ...
- 异或巧用:Single Number
异或巧用:Single Number 今天刷leetcode,碰到了到题Single Number.认为解答非常巧妙,故记之... 题目: Given an array of integers, ev ...
- 算法导论—无向图的遍历(BFS+DFS,MATLAB)
华电北风吹 天津大学认知计算与应用重点实验室 最后改动日期:2015/8/22 无向图的存储方式有邻接矩阵,邻接链表,稀疏矩阵等. 无向图主要包括双方面内容,图的遍历和寻找联通分量. 一.无向图的遍历 ...
- NS3网络仿真(9): 构建以太网帧
快乐虾 http://blog.csdn.net/lights_joy/ 欢迎转载,但请保留作者信息 在NS3使用了一个叫Packet的类来表示一个数据帧,本节尝试用它构造一个以太网帧. 以下是一个典 ...
- POI异步导入Excel兼容xsl和xlsx
项目架构:spring+struts2+hibernate4+oracle 需求:用户导入excel文件,导入到相应的数据表中,要求提供导入模板,支持xls和xlsx文件 思路分析: 1.提供一个下载 ...
- C项目案例实践(0)-语言基础
1.C语言数据类型 所谓数据类型是按被定义变量的性质.表示形式.占据存储空间的多少.构造特点来划分的.C中数据类型可分为基本数据类型.构造数据类型.指针类型.空类型4大类,结构如图: (1)基本数据类 ...
- high-level operations on files and collections of files
11.10. shutil — High-level file operations — Python 3.6.5 documentation https://docs.python.org/3/li ...
- p_CreateAuditEntry
如果你能搜到我这篇博客,相信你导遇到的了和我一样在导入CRM组织时遇到了类似的错误.这个错误我查资料可以通过CRM升级来解决参考下面连接: https://support.microsoft.com/ ...
- lucene DocValues——本质是为通过docID查找某field的值 看图
Why DocValues? The standard way that Solr builds the index is with an inverted index. This style bui ...
- UIImage加载方式
前言 关于本地图片UIImage的加载问题,还是需要注意的.不同的加载处理方式,在效率和性能上还是有差异的. 今天,我们来讲讲UIImage的加载应该选择什么样的API来加载! 两种API 这两种AP ...