SQL調整優化與10053跟蹤分析一例(zt)
關於Oracle效能優化.
SQL語句調整優化與10053跟蹤分析一例
平臺:windows 2000
DB:Oracle 9.0.1.1.1
概述
本文介紹瞭如何使用first_rows提示調整sql語句,並通過10053跟蹤檔案的分析對不同的優化模式下CBO如何選擇執行計劃作了簡要的介紹。
過程
首先我們看看需要調整的檢視,其定義為:
create or replace view vw_hyb_tbgrjbxx
as
select t1.*,t2.yzbz,t2.grbh_new
from tb_grjbxx t1,hyb_yzbz t2
where t1.grbh = t2.grbh
/
通過grbh進行表連線。兩張表在列grbh上均建有唯一索引,在執行查詢前均已對錶作了分析。
Sql>analyze table tb_grjbxx compute stastistics for table for all indexes;
Sql>analyze table hyb_yzbz compute stastistics for table for all indexes;
前臺查詢語句:
sql>select *From VW_HYB_TBGRJBXX where dwbh = '341004' and yzbz = '0’;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=449 Card=466 Bytes=1
15102)
1 0 HASH JOIN (Cost=449 Card=466 Bytes=115102)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TB_GRJBXX' (Cost=19 Ca
rd=466 Bytes=106714)
3 2 INDEX (RANGE SCAN) OF 'IDX_TB_GRJBXX_DWBH' (NON-UNIQUE
) (Cost=7 Card=466)
4 1 TABLE ACCESS (FULL) OF 'HYB_YZBZ' (Cost=397 Card=129156
Bytes=2324808)
Statistics
----------------------------------------------------------
124 recursive calls
5 db block gets
2717 consistent gets
2695 physical reads
0 redo size
3568 bytes sent via SQL*Net to client
372 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
根據執行計劃,我們看到,表連線使用了HA join,在表HYB_YZBZ上執行了全表掃描。從統計資訊可以看到有2695物理讀取。
下面我們分別加hint /*+first_rows*/和/*+all_rows*/來看看:
1. 加first_rows
sql>select /*+first_rows*/ *From VW_HYB_TBGRJBXX where dwbh = '34100’ and yzbz = ‘0’;
已用時間: 00: 00: 00.02
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=485 Card=4
66 Bytes=115102)
1 0 NESTED LOOPS (Cost=485 Card=466 Bytes=115102)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TB_GRJBXX' (Cost=19 Ca
rd=466 Bytes=106714)
3 2 INDEX (RANGE SCAN) OF 'IDX_TB_GRJBXX_DWBH' (NON-UNIQUE
) (Cost=7 Card=466)
4 1 TABLE ACCESS (BY INDEX ROWID) OF 'HYB_YZBZ' (Cost=1 Card
=129281 Bytes=2327058)
5 4 INDEX (UNIQUE SCAN) OF 'SYS_C004851' (UNIQUE) (Cost=1
Card=129281)
Statistics
----------------------------------------------------------
7 recursive calls
0 db block gets
2449 consistent gets
0 physical reads
0 redo size
3568 bytes sent via SQL*Net to client
372 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
執行計劃選擇了NL Join,而不是HA Join,在表HYB_YZBZ使用了索引。從統計資訊上來看,物理讀取和緩衝區讀取的數目均為0,調整收到很好的效果。
2. 加all_rows
sql>select /*+all_rows*/ *From VW_HYB_TBGRJBXX where dwbh = '34100’ and yzbz = ‘0’;
已用時間: 00: 00: 04.06
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: ALL_ROWS (Cost=455 Card=466
Bytes=115102)
1 0 HASH JOIN (Cost=455 Card=466 Bytes=115102)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TB_GRJBXX' (Cost=19 Ca
rd=466 Bytes=106714)
3 2 INDEX (RANGE SCAN) OF 'IDX_TB_GRJBXX_DWBH' (NON-UNIQUE
) (Cost=7 Card=466)
4 1 TABLE ACCESS (FULL) OF 'HYB_YZBZ' (Cost=403 Card=129281
Bytes=2327058)
Statistics
----------------------------------------------------------
0 recursive calls
5 db block gets
2719 consistent gets
2574 physical reads
0 redo size
3568 bytes sent via SQL*Net to client
372 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
可以看到,執行計劃與優化器模式為Choose時一致,從表象上可以認為,在執行該查詢時CBO錯誤的選擇了ALL_ROWS而不是FIRST_ROWS(其實這是一個繆論,不管是使用CHOOSE還是ALL_ROWS都是使用COST最小的計劃)。通過改變檢視定義:
create or replace view vw_hyb_tbgrjbxx
as
select /*+first_rows*/ t1.*,t2.yzbz,t2.grbh_new
from tb_grjbxx t1,hyb_yzbz t2
where t1.grbh = t2.grbh
/
把全表掃描變為通過索引訪問,完成該sql語句的調整。
下面我們通過10053跟蹤的分析可以知道CBO到底是如何選擇執行計劃的。
sidb > ALTER SESSION SET EVENTS '10053 trace name context forever, level 1';
會話已更改。
-- 依次執行以下語句:
Sql>select *From VW_HYB_TBGRJBXX where dwbh = '34100’ and yzbz = ‘0’;
Sql>select /*+frist_rows*/ *From VW_HYB_TBGRJBXX where dwbh = '34100’ and yzbz = ‘0’;
Sql>select /*+all_rows*/ *From VW_HYB_TBGRJBXX where dwbh = '34100’ and yzbz = ‘0’;
下面我們來看看生成的跟蹤檔案。
跟蹤檔案中,PARAMETERS USED BY THE OPTIMIZER、BASE STATISTICAL INFORMATION、都是一致的,如下所示:
***************************************
BASE STATISTICAL INFORMATION
***********************
Table stats Table: HYB_YZBZ Alias: T2
TOTAL :: CDN: 258561 NBLKS: 2654 TABLE_SCAN_CST: 403 AVG_ROW_LEN: 33
Column: GRBH Col#: 1 Table: HYB_YZBZ Alias: T2
NDV: 258312 NULLS: 0 DENS: 3.8713e-006
-- Index stats
INDEX NAME: IDX_HYB_YZBZ_DWBH COL#: 4
TOTAL :: LVLS: 2 #LB: 2512 #DK: 555 LB/K: 4 DB/K: 5 CLUF: 2777
INDEX NAME: IDX_HYB_YZBZ_GRBH_NEW COL#: 3
TOTAL :: LVLS: 2 #LB: 788 #DK: 86097 LB/K: 1 DB/K: 1 CLUF: 38877
INDEX NAME: SYS_C004851 COL#: 1
TOTAL :: LVLS: 2 #LB: 1639 #DK: 258561 LB/K: 1 DB/K: 1 CLUF: 5007
***********************
Table stats Table: TB_GRJBXX Alias: T1
TOTAL :: CDN: 258313 NBLKS: 17631 TABLE_SCAN_CST: 2677 AVG_ROW_LEN: 229
Column: GRBH Col#: 1 Table: TB_GRJBXX Alias: T1
NDV: 258313 NULLS: 0 DENS: 3.8713e-006
Column: GRBH Col#: 1 Table: TB_GRJBXX Alias: T1
NDV: 258313 NULLS: 0 DENS: 3.8713e-006
-- Index stats
INDEX NAME: IDX_TB_GRJBXX_DWBH COL#: 2
TOTAL :: LVLS: 2 #LB: 2599 #DK: 546 LB/K: 4 DB/K: 31 CLUF: 17063
INDEX NAME: IDX_TB_GRJBXX_GMSFHM COL#: 3
TOTAL :: LVLS: 2 #LB: 2997 #DK: 221668 LB/K: 1 DB/K: 1 CLUF: 215999
INDEX NAME: IDX_TB_GRJBXX_XM COL#: 6
TOTAL :: LVLS: 2 #LB: 2982 #DK: 176560 LB/K: 1 DB/K: 1 CLUF: 241229
INDEX NAME: SYS_C006085 COL#: 1
TOTAL :: LVLS: 2 #LB: 1548 #DK: 242702 LB/K: 1 DB/K: 1 CLUF: 18109
_OPTIMIZER_PERCENT_PARALLEL = 0
***************************************
SINGLE TABLE ACCESS PATH
Column: DWBH Col#: 2 Table: TB_GRJBXX Alias: T1
NDV: 554 NULLS: 0 DENS: 1.8051e-003
TABLE: TB_GRJBXX ORIG CDN: 258313 ROUNDED CDN: 466 CMPTD CDN: 466
Access path: tsc Resc: 2677 Resp: 2677
Access path: index (equal)
Index: IDX_TB_GRJBXX_DWBH
TABLE: TB_GRJBXX
RSC_CPU: 0 RSC_IO: 38
IX_SEL: 0.0000e+000 TB_SEL: 1.8051e-003
Access path: index (equal)
Index: IDX_TB_GRJBXX_DWBH
TABLE: TB_GRJBXX
RSC_CPU: 0 RSC_IO: 7
IX_SEL: 1.8051e-003 TB_SEL: 1.8051e-003
BEST_CST: 19.00 PATH: 4 Degree: 1
***************************************
SINGLE TABLE ACCESS PATH
Column: YZBZ Col#: 2 Table: HYB_YZBZ Alias: T2
NDV: 2 NULLS: 0 DENS: 5.0000e-001
TABLE: HYB_YZBZ ORIG CDN: 258561 ROUNDED CDN: 129281 CMPTD CDN: 129281
Access path: tsc Resc: 403 Resp: 403
Access path: index (no sta/stp keys)
Index: IDX_HYB_YZBZ_DWBH
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 2514
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: IDX_HYB_YZBZ_GRBH_NEW
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 790
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: SYS_C004851
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 1641
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: IDX_HYB_YZBZ_DWBH
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 2514
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: IDX_HYB_YZBZ_GRBH_NEW
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 790
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: SYS_C004851
TABLE: HYB_YZBZ
RSC_CPU: 0 RSC_IO: 1641
IX_SEL: 1.0000e+000 TB_SEL: 1.0000e+000
Access path: index (no sta/stp keys)
Index: IDX_HYB_YZBZ_GRBH_NEW
TABLE: HYB_YZBZ<
http://blog.itpub.net/post/11/2813
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-84524/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- histogram與10053(zt)Histogram
- SQL Server 2005效能調整二(zt)SQLServer
- MYSQL sql執行過程的一些跟蹤分析(二.mysql優化器追蹤分析)MySql優化
- SQL優化器探討(zt)SQL優化
- [20200326]dbms_monitor跟蹤與SQL語句分析.txtSQL
- SQLServer進行SQL跟蹤SQLServer
- SQL Server 2005效能調整一(zt)SQLServer
- Nginx的優化調整方面Nginx優化
- Oracle資料庫跟蹤SQLOracle資料庫SQL
- sybase優化概述(zt)優化
- Oracle 高效能SQL引擎剖析--SQL優化與調優機制詳解OracleSQL優化
- swoole優化核心引數調整優化
- 備份的優化和調整優化
- outline優化一例優化
- 效能調優——SQL最佳化SQL
- MYSQL sql執行過程的一些跟蹤分析(一)MySql
- SYBASE優化總結(zt)優化
- Mysql慢SQL分析及優化MySql優化
- 【效能調優】效能測試、分析與調優基礎
- [原始碼分析] OpenTracing之跟蹤Redis原始碼Redis
- 演算法分析__遞迴跟蹤演算法遞迴
- Nginx安全優化與效能調優Nginx優化
- Git跟蹤與提交檔案Git
- APT組織跟蹤與溯源APT
- SQL Access Advisor(zt)SQL
- TiDB 查詢優化及調優系列(四)查詢執行計劃的調整及優化原理TiDB優化
- 【SQL】關於Oracle12c SQL調整中一些變化SQLOracle
- 一個非侵入式跟蹤分析程式
- 轉:使用 Tkprof 分析 ORACLE 跟蹤檔案Oracle
- Oracle執行語句跟蹤 使用sql trace實現語句追蹤OracleSQL
- 生財有跡 | 您專屬的資產跟蹤與分析工具
- TiDB 效能分析&效能調優&優化實踐大全TiDB優化
- MySQL調優篇 | SQL調優實戰(5)MySql
- Microsoft SQL Server 2005中查詢優化器使用的統計資訊二(zt)ROSSQLServer優化
- Microsoft SQL Server 2005中查詢優化器使用的統計資訊一(zt)ROSSQLServer優化
- Microsoft SQL Server 2005中查詢優化器使用的統計資訊三(zt)ROSSQLServer優化
- 程式分析與優化 - 6 迴圈優化優化
- 如何收集Oracle程式中的SQL跟蹤資訊KUOracleSQL
- 淺談JVM整體架構與調優引數JVM架構