pl/sql developer 分析的執行計劃不可信
本來要測試一個功能的並行處理能力
select v_time,
round(WANGJIANYINGDA_NUM1 / WANGJIANYINGDA_NUM2, 2)
WANGJIANYINGDA_NUM1,
WANGJIANYINGDA_NUM2
from (SELECT /*+ PARALLEL(ZXCDR_ii, 4) */ SUBSTR(IAM_DATE, 1, 13) as v_time,
COUNT(case
when anm_date is null then
1
end) AS WANGJIANYINGDA_NUM1,
COUNT(1) AS WANGJIANYINGDA_NUM2
FROM ZXCDR_ii t
WHERE t.iam_date between
to_date('2009-04-08 10:00:00', 'yyyy-mm-dd hh24:mi:ss') and
to_date('2009-04-08 19:00:00', 'yyyy-mm-dd hh24:mi:ss') and
OPC IN ('11-FF-19', '11-FF-42')
AND DPC IN ('11-0D-37', '11-27-45')
AND process_flg = 0
group by SUBSTR(IAM_DATE, 1, 13));
指定並行處理,
SELECT STATEMENT, GOAL = ALL_ROWS 7 7 1 65
SORT GROUP BY 7 7 1 65
SORT GROUP BY 7 7 1 65
PARTITION RANGE ALL
INLIST ITERATOR
TABLE ACCESS BY LOCAL INDEX ROWID HLHT ZXCDR_II 3 3 1 65
INDEX RANGE SCAN HLHT IDX_OPC 2 2 6659 "T"."OPC"='11-FF-19' OR "T"."OPC"='11-FF-42'
但結果總是不對.但自己檢查表的並行度,使用的索引idx_opc並行度,都沒有問題.
[@more@]想不明白為什麼.
只好開啟sql_trace ,看看系統的內部處理,
透過分析oracle的trace結果,如下:
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=65)
1 0 SORT* (GROUP BY) (Cost=7 Card=1 Bytes=65) :Q692001
2 1 SORT* (GROUP BY) (Cost=7 Card=1 Bytes=65) :Q692000
3 2 PARTITION RANGE* (ALL) :Q692000
4 3 INLIST ITERATOR* :Q692000
5 4 TABLE ACCESS* (BY LOCAL INDEX ROWID) OF 'ZXCDR_II' (Cost=3 Card=1 Byte :Q692000
s=65)
6 5 INDEX* (RANGE SCAN) OF 'IDX_OPC' (NON-UNIQUE) (Cost=2 Card=6659) :Q692000
1 PARALLEL_TO_SERIAL SELECT /*+ CIV_GB */ A1.C0,COUNT(SYS_OP_CSR(
A1.C1,0)),COUNT(SYS_OP_CSR(A1.C1,1)) FROM :Q
692000 A1 GROUP BY A1.C0
2 PARALLEL_TO_PARALLEL SELECT /*+ PIV_GB */ SUBSTR(A1.C3,1,13) C0,S
YS_OP_MSR(COUNT(*),COUNT(CASE WHEN A1.C4 IS
NULL THEN 1 END )) C1 FROM (SELECT /*+ NO_E
XPAND INDEX(A2 "IDX_OPC") */ A2.ROWID C0,A2.
"OPC" C1,A2."DPC" C2,A2."IAM_DATE" C3,A2."AN
M_DATE" C4,A2."PROCESS_FLG" C5 FROM "ZXCDR_I
I" PX_GRANULE(0, PARTITION, DYNAMIC) A2 WHE
RE (A2."OPC"='11-FF-19' OR A2."OPC"='11-FF-4
2') AND A2."IAM_DATE">=TO_DATE('2009-04-08 1
0:00:00', 'yyyy-mm-dd hh24:mi:ss') AND A2."I
AM_DATE"<=TO_DATE('2009-04-08 19:00:00', 'yy
yy-mm-dd hh24:mi:ss') AND (A2."DPC"='11-0D-3
7' OR A2."DPC"='11-27-45') AND A2."PROCESS_F
LG"=0) A1 GROUP BY SUBSTR(A1.C3,1,13)
3 PARALLEL_COMBINED_WITH_PARENT
4 PARALLEL_COMBINED_WITH_PARENT
5 PARALLEL_COMBINED_WITH_PARENT
6 PARALLEL_COMBINED_WITH_PARENT
這才發現,實際上的執行結果,在資料庫端並沒有錯.而是
PL/SQL DEVELOPER工具顯示的有問題.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/197458/viewspace-1020273/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 使用PL/SQL檢視執行計劃SQL
- SQL執行計劃分析SQL
- PL/SQL Developer顯示行號SQLDeveloper
- 執行計劃不穩定的原因分析
- PL/SQl Developer使用SQLDeveloper
- PL/SQL Developer 使用SQLDeveloper
- SQL的執行計劃SQL
- Oracle檢視正在執行的SQL以及執行計劃分析OracleSQL
- MySQL——通過EXPLAIN分析SQL的執行計劃MySqlAI
- sql 執行計劃SQL
- pl/sql developer使用技巧SQLDeveloper
- 為什麼該SQL的執行計劃不走索引???SQL索引
- 分析執行計劃優化SQLORACLE的執行計劃(轉)優化SQLOracle
- Oracle sql執行計劃OracleSQL
- SQL Server執行計劃SQLServer
- 分析執行計劃最佳化SQLORACLE的執行計劃(轉)SQLOracle
- 通過分析SQL語句的執行計劃優化SQL 二SQL優化
- 【sql調優之執行計劃】獲取執行計劃SQL
- sql的執行計劃 詳解SQL
- PL/SQL Developer 連線 OracleSQLDeveloperOracle
- pl sql developer 8.0 register codeSQLDeveloper
- PL/SQL執行動態SQLSQL
- explain執行計劃分析AI
- PL/SQL Profiler 和SQL Developer 報表SQLDeveloper
- Oracle中檢視已執行sql的執行計劃OracleSQL
- NOTE: cannot fetch plan for SQL_ID_在plsql developer無法獲取sql執行計劃SQLDeveloper
- 檢視Oracle SQL執行計劃方法比較、分析OracleSQL
- 通過分析SQL語句的執行計劃優化SQL(總結)SQL優化
- 通過分析SQL語句的執行計劃優化SQL語句SQL優化
- 獲取SQL執行計劃SQL
- SQL 執行計劃案例1SQL
- 剖析SQL Server執行計劃SQLServer
- 檢視sql執行計劃SQL
- SqlServer的執行計劃如何分析?SQLServer
- 使用SQL_TEACE的跟蹤檔案分析執行計劃SQL
- 執行truncate在pl/sqlSQL
- 如何檢視SQL的執行計劃SQL
- 檢視SQL的執行計劃方法SQL