Oracle 10g的隐含参数_complex_view_merging引发的性能问题
今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差
今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差不多。
在数据库1上执行0.01s。
SQL> SELECT A.*,
2 B.INCREASE_ID,
3 B.TRANSACTION_ID,
4 B.LINK_CARD_ID,
5 B.VALIDATE_FLAG,
6 B.ASSET_VALUE_SHARING,
7 B.RELATED_DEVICE_ID,
8 B.PARENT_CARD_CODE,
9 B.PROJECT_VALUE,
10 B.DELETE_FLAG,
11 B.DEPRECIATION_ADJUST_VALUE,
12 T.TRANSACTION_MODE_CODE,
13 T.TRANSACTION_NO,
14 T.TRANSACTION_FROM,
15 T.FROM_MODEL,
16 (SELECT T.FULL_PATH
17 FROM AM_TECH_OBJECT_NODE_0900 T
18 WHERE T.TECH_OBJECT_ID = A.DEVICE_ID
19 AND T.NODE_TYPE = 2
20 AND ROWNUM = 1) AS FULL_PATH,
21 AAC.FULL_NAME CLASSIFY_FULL_PATH
22 FROM V_ASSET_CARD_0900 A,
23 GG_ASSET_INCREASE_ITEM B,
24 GG_ASSET_TRANSACTION T,
25 AM_ASSET_CLASSIFY AAC
26 WHERE A.CARD_ID = B.CARD_ID
27 AND B.TRANSACTION_ID = T.TRANSACTION_ID
28 AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)
29 AND B.TRANSACTION_ID = '0101109514';
已用时间: 00: 00: 00.01
执行计划
----------------------------------------------------------
Plan hash value: 3643758043
-------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 21 | 24129 | 167 (0)| 00:00:03 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID | AM_TECH_OBJECT_NODE_0900 | 1 | 73 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | IDX_TECH_NODE_ID_0900 | 1 | | 3 (0)| 00:00:01 |
| 4 | NESTED LOOPS OUTER | | 21 | 24129 | 167 (0)| 00:00:03 |
| 5 | NESTED LOOPS | | 21 | 22533 | 146 (0)| 00:00:02 |
| 6 | NESTED LOOPS | | 20 | 12700 | 106 (0)| 00:00:02 |
| 7 | NESTED LOOPS | | 20 | 10900 | 46 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 20 | 2000 | 6 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION | 1 | 42 | 2 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | PK_GG_ASSET_TRANSACTION | 1 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM | 20 | 1160 | 4 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | TRANSACTION_DETAIL_REF_TRANSAC | 20 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | GG_ASSET_CARD_0900 | 1 | 445 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PK_GG_ASSET_CARD_0303 | 1 | | 1 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | GG_ASSET_VALUE_0900 | 1 | 90 | 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | ID_FAV_CARD_VALIDITY_0303 | 1 | | 2 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | AM_ASSET_0900 | 1 | 438 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | PK_AM_ASSET_0900 | 1 | | 1 (0)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | AM_ASSET_CLASSIFY | 1 | 76 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | PK_AM_ASSET_CLASSIFY | 1 | | 0 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM=1)
3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)
10 - access("T"."TRANSACTION_ID"='0101109514')
12 - access("B"."TRANSACTION_ID"='0101109514')
14 - access("GG_ASSET_CARD"."CARD_ID"="B"."CARD_ID")
16 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND
"GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")
18 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")
20 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
统计信息
----------------------------------------------------------
8 recursive calls
0 db block gets
28 consistent gets
0 physical reads
0 redo size
12384 bytes sent via SQL*Net to client
338 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed