数据库执行计划慢导致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
转载于:https://www.cnblogs.com/feiyun8616/p/7054778.html
数据库执行计划慢导致I/O 慢相关推荐
- SQL执行计划错误导致临时表空间不足
故障现象:临时表空间不足的问题已经报错过3次,客户也烦了,前两次都是同事添加5G的数据文件,目前已经达到40G,占用临时表空间主要是distinct 和group by 以及Union all 表数据 ...
- 【数据库】 - postgresql数据库执行计划
数据库 - 执行计划 1. 执行计划命令 explain 2. 命令参数 analyze:选项为TRUE 会实际执行SQL,并获得相应的查询计划,默认为FALSE buffers:buffers必须跟 ...
- Mysql 数据库执行计划 EXPLAIN SELECT * FROM
文章目录 EXPLAIN SELECT * FROM 是干嘛用的 ? EXPLAIN SELECT * FROM 各个字段的含义 1. id: 2.select_type: 3. table: 4.t ...
- 执行计划变化导致CPU负载高的问题分析 (r8笔记第20天)
前几天碰到一个CPU负载较高的问题.从系统层面来看,情况不是很严重,但是从应用的角度来说,已经感觉到很慢了.因为前端的调用频率还是比较高.所以会把这个问题放大. Elapsed Time (s) CP ...
- 达梦数据库优化器执行计划解读
说明: 1.达梦数据库执行计划 一条SQL语句在数据库中的执行过程或者访问路径的描述,通过执行计划,可以知道优化器对sql进行了哪些处理,使用了哪些方式去执行sql.执行计划看起来就像一棵树,执行过程 ...
- 来来来!一次搞定各种数据库 SQL 执行计划:MySQL、Oracle
执行计划(execution plan,也叫查询计划或者解释计划)是数据库执行 SQL 语句的具体步骤,例如通过索引还是全表扫描访问表中的数据,连接查询的实现方式和连接的顺序等.如果 SQL 语句性能 ...
- SQL Server 执行计划缓存
原文:SQL Server 执行计划缓存 标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储 ...
- sqlserver 删除字段_SQL Server 执行计划缓存
标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之 ...
- sql server运算符_SQL Server执行计划中SELECT运算符的主要概念
sql server运算符 One of the main responsibilities of a database administrator is query tuning and troub ...
最新文章
- vue中的浏览量_vue中前进刷新、后退缓存用户浏览数据和浏览位置的实践
- 区分大小屏幕_第一个Python程序——在屏幕上输出文本
- 如何在Flutter上优雅地序列化一个对象
- 参数设置_变频器基本参数设置
- 12. GD32F103C8T6入门教程-定时器-3路pwm输出
- 腾讯电脑管家离线安装包_这个良心小工具,让你电脑流畅1倍,干掉流氓软件...
- 【用户】create_user_with_sshkey.sh
- 计算机网络从使用对象上划分为,计算机网络练习题卷1-2章.doc
- linux crw权限,linux中crw brw lrw等等文件属性是什么
- WPF Deactivated和Activated简单使用
- 微信平台开发的基本步骤讲解
- 软件设计模式从何而来?------“抄袭来的” 设计模式
- CST微波工作室学习笔记2 主要特点
- #### Kafka Rebalance ####
- 不义联盟网站无法连接服务器,不义联盟:人间之神无法连接服务器如何解决
- 【论文阅读 Journal of Financial Economics】Surprise election for Trump connections
- 7-5 两点成线 (10 分) JAVA PTA
- Linux查看日志命令(4种常见方式)
- 公司招聘专员爆头痛哭,求职者再拒绝我的邀请我就要。。。
- 给网赚从业者的几点建议