数据库执行计划慢导致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

时间: 2024-07-30 03:23:40

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

Hive语法层面优化之五分析执行计划追踪导致数据倾斜的原因

count(distinct key)案例 explain select count(distinct session_id) from trackinfo where ds=' 2013-07-21' ; STAGE DEPENDENCIES: Stage-1 is a root stage Stage-0 is a root stage STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: trackinfo T

通过重新生成执行计划解决绑定变量执行计划偏差导致SQL执行时间过长

基本要素(时间.用户.问题) 用户11g环境下有段SQL语句在程序中执行效率非常差,但是在plsql中执行却很快,通过查看执行计划,发现使用了不同的索引导致,程序中执行的如下: PLSQL中执行的效果如下: 可以看到差别,使用门诊费用记录_IX_登记时间索引是在plsql中的执行计划,使用门诊费用记录_UQ_NO的是程序中的执行计划,两者SQL是完全相同的,唯一却别就是前者使用了绑定变量,后者是直接带参数值执行. 问题分析 问题很明显,由于绑定变量生成的执行计划与实际有偏差,11g本来有个绑定变

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

parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的SQL(或者存储过程中使用了参数化)写法,如果存在数据分布不均匀的情况下,正常情况下生成的执行计划,在传入在分布数据较多的参数的情况下,重用了正常参数生成的执行计划,而这种缓存的执行计划并非适合当前参数的一种情况. 这种情况,在实际业务中,出现的频率还是比较高的,因为存储过程一般都是采用参数化的写法

SQL Server 执行计划缓存

原文:SQL Server 执行计划缓存 标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之前先要了解一些基础知识,所以文章前面会讲一些概念,学起来会比较枯燥,但是这些基础知识非常重要. 目录 概述 基础概念 怎样缓存执行计划 SQL Server自动删除执行计划 重新编译执行计划 测试 执行计划相关系统视图 手动清空缓存执行计划 测试索引更改对执

执行计划的重用

当查询被提交时,SQL Server检查过程缓冲中匹配的执行计划,如果没有找到,SQL Server执行查询编译和优化以生成新的执行计划. 如果执行计划存在于缓冲中,它在私有的执行上下文中重用,这节约了CPU的编译和优化周期. 具有不同过滤条件的相同查询提交到SQL Server时,如: SELECT * FROM Person WHERE Id = 1 当这个查询被提交时,优化器创建一个执行计划并将其存储在过程缓冲中以被将来重用.如果这个查询使用不同的过滤条件,如:WHERE Id = 2重新

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

简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因此,完整的过程如图1所示. 图1.将计划缓存考虑在内的过程 图1中我们可以看到,其中有一步需要在缓存中找到计划的过程.因此不难猜出,只要是这一类查

Oracle 11g 执行计划管理概述

以下内容来源于:http://www.51cto.com/art/200806/76223.htm 35.2  执行计划管理 35.2.1  概述 同一SQL语句的执行计划可能因为优化器的版本.优化统计.优化参数.系统设置的不同而不同.而SQL语句的执行计划自动改变,通常情况下会带来性能提升,但是在某些情况下可能导致系统性能的下降.在11g之前,DBA使用存储大纲(Stored Outline)和SQL 概要(Profile)来固定某些SQL语句的执行计划,防止因为系统自动更改执行计划而导致的性

MySql的执行计划

一.什么是数据库执行计划: MySQL执行计划是sql语句经过查询优化器后,查询优化器会根据用户的sql语句所包含的字段和内容数量等统计信息,选择出一个执行效率最优(MySQL系统认为最优)的执行计划,然后根据执行计划,调用存储引擎提供的接口,获取数据.执行计划,简单的来说,是SQL在数据库中执行时的表现情况,通常用于SQL性能分析,优化等场景. 二.执行计划的查看方法: 使用explain关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的,分析你的查询语句或是

统计信息不准导致执行计划出错跑不出结果,优化后只要1分钟

一天查看数据库长会话,发现1个sql跑得很慢,1个多小时不出结果,花了点时间把它给优化了. 优化前: SELECT 20131023, "A2"."ORG_ID", COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE" WHEN 'DP' THEN "A2"."RES_CODE" END, 'nls_sort=''BINARY''')), COUNT(D