當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

数据库执行计划慢导致I/O 慢

發布時間：2025/3/20 数据库 16 豆豆

生活随笔收集整理的這篇文章主要介紹了数据库执行计划慢导致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
--------------------------------------------------------------------------------

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

| 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 |

|* 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 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 慢的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： 2D缩放
下一篇： linux cmake编译源码,linu