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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL——通過EXPLAIN分析SQL的執行計劃MySqlAI
- pl/sql developer的一個小問題SQLDeveloper
- Oracle sql執行計劃OracleSQL
- pl developerDeveloper
- 分析執行計劃優化SQLORACLE的執行計劃(轉)優化SQLOracle
- 如何檢視SQL的執行計劃SQL
- explain執行計劃分析AI
- PL/SQL Developer連線到Oracle 12cSQLDeveloperOracle
- 「Oracle」客戶端 PL/SQL DEVELOPER 安裝使用Oracle客戶端SQLDeveloper
- SqlServer的執行計劃如何分析?SQLServer
- Oracle SQL Profile固定執行計劃的方法OracleSQL
- PL/SQL Developer下載地址和漢化包地址SQLDeveloper
- PL/SQL Developer連線遠端Oracle資料庫SQLDeveloperOracle資料庫
- 5. Oracle連線和使用——5.2. PL/SQL DeveloperOracleSQLDeveloper
- DB2執行計劃分析DB2
- SQL執行計劃異常引起的效能問題SQL
- SQL執行計劃異常 引起的效能問題SQL
- 本地不安裝oracle,用PL/SQL Developer連線資料庫OracleSQLDeveloper資料庫
- SQLServer統計監控SQL執行計劃突變的方法SQLServer
- 執行計劃-1:獲取執行計劃
- (4) MySQL中EXPLAIN執行計劃分析MySqlAI
- mysql 執行計劃索引分析筆記MySql索引筆記
- Oracle資料庫關於SQL的執行計劃(轉)Oracle資料庫SQL
- 檢視SQL執行計劃的幾種常用方法YQSQL
- 在MySQL中使用explain查詢SQL的執行計劃MySqlAI
- Oracle檢視sql_id 的歷史執行計劃OracleSQL
- SQL優化案例-從執行計劃定位SQL問題(三)SQL優化
- 不會看 Explain執行計劃,勸你簡歷別寫熟悉 SQL優化AISQL優化
- 不會看 Explain 執行計劃,勸你簡歷別寫熟悉 SQL 優化AISQL優化
- 檢視一個正在執行的sql的執行計劃(explain for connection processlist_id)SQLAI
- pl/sql developer中關於TIMESTAMP顯示格式的疑問和學習SQLDeveloper
- 【執行計劃】Oracle獲取執行計劃的幾種方法Oracle
- SQL最佳化案例-從執行計劃定位SQL問題(三)SQL
- 不會看 Explain 執行計劃,勸你簡歷別寫熟悉 SQL 最佳化AISQL
- TiDB與MySQL的SQL差異及執行計劃簡析TiDBMySql
- .Oracle固定執行計劃之SQL PROFILE概要檔案OracleSQL
- PostgreSQL 查詢當前執行中sql的執行計劃——pg_show_plans模組SQL
- 達夢資料庫獲取SQL真實的執行計劃資料庫SQL
- 獲取oracle sql語句詳細些執行計劃OracleSQL