|* 10 | INDEX RANGE SCAN | TRANSACTION_DETAIL_REF_TRANSAC | 25 | | | 1 (0)| 00:00:01 |
| 11 | VIEW | V_ASSET_CARD_0900 | 280K| 2744M| | 45781 (1)| 00:09:10 |
|* 12 | HASH JOIN | | 280K| 257M| 141M| 45781 (1)| 00:09:10 |
|* 13 | HASH JOIN | | 274K| 137M| 27M| 12222 (1)| 00:02:27 |
| 14 | TABLE ACCESS FULL | GG_ASSET_VALUE_0900 | 292K| 24M| | 910 (2)| 00:00:11 |
| 15 | TABLE ACCESS FULL | GG_ASSET_CARD_0900 | 274K| 114M| | 4073 (1)| 00:00:49 |
| 16 | TABLE ACCESS FULL | AM_ASSET_0900 | 756K| 315M| | 10464 (1)| 00:02:06 |
| 17 | TABLE ACCESS BY INDEX ROWID | AM_ASSET_CLASSIFY | 1 | 76 | | 1 (0)| 00:00:01 |
|* 18 | 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)
5 - access("A"."CARD_ID"="B"."CARD_ID")
8 - access("T"."TRANSACTION_ID"='0101109514')
10 - access("B"."TRANSACTION_ID"='0101109514')
12 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")
13 - 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("A"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
统计信息
----------------------------------------------------------
218 recursive calls
0 db block gets
70112 consistent gets
26412 physical reads
348 redo size
38174 bytes sent via SQL*Net to client
480 bytes received via SQL*Net from client
15 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
200 rows processed
第一次诊断：起初觉得应该是索引的集群因子的问题，检查了下，差不多。
第二次诊断：感觉是环境、参数不一样引起，开始试验。
使用视图v$sql和v$sql_plan、dbms_xplan.display_cursor查出sql真实的执行计划。
select distinct s.SQL_ID, s.HASH_VALUE, s.CHILD_NUMBER, s.SQL_TEXT
from v$sql s, v$sql_plan p
where s.SQL_ID = p.SQL_ID
and p.PLAN_HASH_VALUE = '3643758043';
select * from table(dbms_xplan.display_cursor(150270666, 0, 'advanced'));
性能慢的数据库：
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
OPT_PARAM('_complex_view_merging' 'false')
ALL_ROWS
............省略............
*/
性能快的数据库：
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
ALL_ROWS
............省略............
*/
看到两个执行的大纲有点不同，于是到两个数据库中查这个_complex_view_merging这个隐含参数，性能慢的数据库设置为false,性能快的数据库的设置则为true。
SQL语句中是有视图的，莫非这个隐含参数有问题，按字面的意思是复杂视图的合并，抱着试一试的心情调整了下这个参数：
alter session set "_complex_view_merging" = true;
结果非常快，0.6s。
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