oracle的complex,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

本文原创发布php中文网，转载请注明出处，感谢您的尊重！