为啥 Oraoop 1.6 在分配内存块之前要等待 1.5 分钟？
Posted
技术标签:
【中文标题】为啥 Oraoop 1.6 在分配内存块之前要等待 1.5 分钟？【英文标题】：Why does Oraoop 1.6 wait 1.5 minutes before allocating memory chunks?为什么 Oraoop 1.6 在分配内存块之前要等待 1.5 分钟？ 【发布时间】：2015-01-14 07:16:55 【问题描述】：使用 SQOOP 1.4.4 和 Oraoop 1.6，无论表的行数/列数如何，我们总是需要等待 1.5 分钟以上。使用--verbose 不会透露更多信息。 SQOOP 命令没有覆盖任何 -D 变量。
这是命令的输出：
15/01/14 02:08:13 INFO oraoop.OracleConnectionFactory: Initializing Oracle session with SQL : alter session set tracefile_identifier=oraoop
15/01/14 02:09:48 INFO oraoop.OraOopDataDrivenDBInputFormat: The table being imported by sqoop has 320 blocks that have been divided into 5 chunks which will be processed in 5 splits. The chunks will be allocated to the splits using the method : ROUNDROBIN
我们发现此查询占用了大部分或全部时间：
SELECT data_object_id, file_id, relative_fno, file_batch,
MIN (start_block_id) start_block_id, MAX (end_block_id) end_block_id,
SUM (blocks) blocks
FROM (SELECT o.data_object_id, e.file_id, e.relative_fno,
e.block_id start_block_id,
e.block_id + e.blocks - 1 end_block_id, e.blocks,
CEIL
( SUM (e.blocks) OVER (PARTITION BY o.data_object_id, e.file_id ORDER BY e.block_id ASC)
/ ( SUM (e.blocks) OVER (PARTITION BY o.data_object_id, e.file_id)
/ :numchunks
)
) file_batch
FROM dba_extents e, dba_objects o, dba_tab_subpartitions tsp
WHERE o.owner = :owner
AND o.object_name = :object_name
AND e.owner = :owner
AND e.segment_name = :object_name
AND o.owner = e.owner
AND o.object_name = e.segment_name
AND ( o.subobject_name = e.partition_name
OR (o.subobject_name IS NULL AND e.partition_name IS NULL)
)
AND o.owner = tsp.table_owner(+)
AND o.object_name = tsp.table_name(+)
AND o.subobject_name = tsp.subpartition_name(+))
GROUP BY data_object_id, file_id, relative_fno, file_batch
ORDER BY data_object_id, file_id, relative_fno, file_batch
以下是计划：
----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 2383 (100)| |
| 1 | SORT GROUP BY | | 3 | 246 | 2383 (2)| 00:00:34 |
| 2 | VIEW | | 3 | 246 | 2382 (2)| 00:00:34 |
| 3 | WINDOW SORT | | 3 | 804 | 2382 (2)| 00:00:34 |
|* 4 | FILTER | | | | | |
|* 5 | HASH JOIN | | 3 | 804 | 2381 (2)| 00:00:34 |
|* 6 | HASH JOIN OUTER | | 2 | 298 | 53 (2)| 00:00:01 |
| 7 | VIEW | DBA_OBJECTS | 2 | 226 | 6 (0)| 00:00:01 |
| 8 | UNION-ALL | | | | | |
|* 9 | FILTER | | | | | |
|* 10 | FILTER | | | | | |
| 11 | NESTED LOOPS | | 1 | 86 | 5 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 64 | 4 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | I_USER1 | 1 | | 0 (0)| |
|* 15 | TABLE ACCESS BY INDEX ROWID | OBJ$ | 1 | 49 | 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | I_OBJ5 | 1 | | 2 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | I_USER2 | 1 | 22 | 1 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 30 | 2 (0)| 00:00:01 |
|* 19 | INDEX SKIP SCAN | I_USER2 | 1 | 20 | 1 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | I_OBJ4 | 1 | 10 | 1 (0)| 00:00:01 |
|* 21 | FILTER | | | | | |
| 22 | NESTED LOOPS | | 1 | 45 | 1 (0)| 00:00:01 |
| 23 | TABLE ACCESS BY INDEX ROWID | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | I_USER1 | 1 | | 0 (0)| |
|* 25 | INDEX RANGE SCAN | I_LINK1 | 1 | 30 | 0 (0)| |
| 26 | VIEW | DBA_TAB_SUBPARTITIONS | 9 | 324 | 47 (3)| 00:00:01 |
|* 27 | FILTER | | | | | |
| 28 | NESTED LOOPS OUTER | | 9 | 1215 | 47 (3)| 00:00:01 |
| 29 | NESTED LOOPS | | 8 | 984 | 39 (3)| 00:00:01 |
| 30 | NESTED LOOPS | | 8 | 912 | 31 (4)| 00:00:01 |
| 31 | NESTED LOOPS | | 8 | 888 | 23 (5)| 00:00:01 |
| 32 | NESTED LOOPS OUTER | | 8 | 776 | 7 (15)| 00:00:01 |
|* 33 | HASH JOIN | | 8 | 728 | 7 (15)| 00:00:01 |
| 34 | NESTED LOOPS | | | | | |
| 35 | NESTED LOOPS | | 8 | 632 | 4 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | 1 | 54 | 2 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | I_USER1 | 1 | | 0 (0)| |
|* 39 | INDEX RANGE SCAN | I_OBJ2 | 1 | 39 | 1 (0)| 00:00:01 |
|* 40 | INDEX RANGE SCAN | I_TABSUBPART_POBJSUBPART$ | 11 | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | TABSUBPART$ | 11 | 275 | 2 (0)| 00:00:01 |
| 42 | TABLE ACCESS FULL | TABCOMPART$ | 61 | 732 | 2 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | I_DEFERRED_STG1 | 1 | 6 | 0 (0)| |
|* 44 | TABLE ACCESS BY INDEX ROWID | OBJ$ | 1 | 14 | 2 (0)| 00:00:01 |
|* 45 | INDEX RANGE SCAN | I_OBJ1 | 1 | | 1 (0)| 00:00:01 |
| 46 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
|* 48 | TABLE ACCESS CLUSTER | TAB$ | 1 | 9 | 1 (0)| 00:00:01 |
|* 49 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | 0 (0)| |
| 50 | TABLE ACCESS CLUSTER | SEG$ | 1 | 12 | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
| 52 | VIEW | DBA_EXTENTS | 140 | 16660 | 2328 (2)| 00:00:33 |
| 53 | UNION-ALL | | | | | |
|* 54 | FILTER | | | | | |
| 55 | NESTED LOOPS | | 1 | 177 | 896 (0)| 00:00:13 |
| 56 | NESTED LOOPS | | 1 | 89 | 28 (0)| 00:00:01 |
| 57 | TABLE ACCESS FULL | UET$ | 1 | 78 | 28 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 11 | 0 (0)| |
|* 59 | INDEX UNIQUE SCAN | I_FILE2 | 1 | | 0 (0)| |
| 60 | VIEW | SYS_DBA_SEGS | 1 | 88 | 868 (0)| 00:00:13 |
| 61 | UNION ALL PUSHED PREDICATE | | | | | |
|* 62 | FILTER | | | | | |
| 63 | NESTED LOOPS | | 1 | 99 | 860 (0)| 00:00:13 |
|* 64 | FILTER | | | | | |
| 65 | NESTED LOOPS OUTER | | 1 | 84 | 844 (0)| 00:00:12 |
| 66 | MERGE JOIN CARTESIAN | | 1 | 69 | 843 (0)| 00:00:12 |
| 67 | NESTED LOOPS | | 1 | 31 | 2 (0)| 00:00:01 |
| 68 | NESTED LOOPS | | 1 | 10 | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 7 | 0 (0)| |
| 70 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
|* 72 | TABLE ACCESS CLUSTER | SEG$ | 1 | 21 | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
| 74 | BUFFER SORT | | 3 | 114 | 842 (0)| 00:00:12 |
|* 75 | INDEX SKIP SCAN | I_OBJ5 | 3 | 114 | 841 (0)| 00:00:12 |
| 76 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 77 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
|* 78 | VIEW | SYS_OBJECTS | 3 | 45 | 16 (0)| 00:00:01 |
| 79 | UNION ALL PUSHED PREDICATE | | | | | |
|* 80 | TABLE ACCESS CLUSTER | TAB$ | 1 | 25 | 2 (0)| 00:00:01 |
|* 81 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | 1 (0)| 00:00:01 |
|* 82 | TABLE ACCESS BY INDEX ROWID | TABPART$ | 1 | 18 | 2 (0)| 00:00:01 |
|* 83 | INDEX UNIQUE SCAN | I_TABPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
|* 84 | TABLE ACCESS CLUSTER | CLU$ | 1 | 14 | 2 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | 1 (0)| 00:00:01 |
|* 86 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 21 | 2 (0)| 00:00:01 |
|* 87 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
|* 88 | TABLE ACCESS BY INDEX ROWID | INDPART$ | 1 | 18 | 2 (0)| 00:00:01 |
|* 89 | INDEX UNIQUE SCAN | I_INDPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
|* 90 | TABLE ACCESS BY INDEX ROWID | LOB$ | 1 | 20 | 2 (0)| 00:00:01 |
|* 91 | INDEX UNIQUE SCAN | I_LOB2 | 1 | | 1 (0)| 00:00:01 |
|* 92 | TABLE ACCESS BY INDEX ROWID | TABSUBPART$ | 1 | 19 | 1 (0)| 00:00:01 |
|* 93 | INDEX UNIQUE SCAN | I_TABSUBPART$_OBJ$ | 1 | | 0 (0)| |
|* 94 | TABLE ACCESS BY INDEX ROWID | INDSUBPART$ | 1 | 19 | 2 (0)| 00:00:01 |
|* 95 | INDEX UNIQUE SCAN | I_INDSUBPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
|* 96 | TABLE ACCESS BY INDEX ROWID | LOBFRAG$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 97 | INDEX UNIQUE SCAN | I_LOBFRAG$_FRAGOBJ$ | 1 | | 0 (0)| |
|* 98 | FILTER | | | | | |
|* 99 | FILTER | | | | | |
| 100 | NESTED LOOPS OUTER | | 1 | 77 | 4 (0)| 00:00:01 |
| 101 | NESTED LOOPS | | 1 | 62 | 3 (0)| 00:00:01 |
| 102 | NESTED LOOPS | | 1 | 37 | 2 (0)| 00:00:01 |
| 103 | NESTED LOOPS | | 1 | 10 | 1 (0)| 00:00:01 |
|*104 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 7 | 0 (0)| |
| 105 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|*106 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
|*107 | TABLE ACCESS BY INDEX ROWID | UNDO$ | 1 | 27 | 1 (0)| 00:00:01 |
|*108 | INDEX RANGE SCAN | I_UNDO2 | 1 | | 0 (0)| |
|*109 | TABLE ACCESS CLUSTER | SEG$ | 1 | 25 | 1 (0)| 00:00:01 |
|*110 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
| 111 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|*112 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
|*113 | FILTER | | | | | |
|*114 | FILTER | | | | | |
| 115 | NESTED LOOPS OUTER | | 1 | 54 | 4 (0)| 00:00:01 |
| 116 | NESTED LOOPS | | 1 | 39 | 3 (0)| 00:00:01 |
| 117 | NESTED LOOPS | | 1 | 14 | 2 (0)| 00:00:01 |
| 118 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 11 | 1 (0)| 00:00:01 |
|*119 | INDEX UNIQUE SCAN | I_FILE2 | 1 | | 0 (0)| |
| 120 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|*121 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
|*122 | TABLE ACCESS CLUSTER | SEG$ | 1 | 25 | 1 (0)| 00:00:01 |
|*123 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
| 124 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|*125 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
|*126 | FILTER | | | | | |
|*127 | HASH JOIN | | 139 | 24603 | 1431 (2)| 00:00:21 |
|*128 | HASH JOIN | | 238 | 23562 | 1406 (1)| 00:00:20 |
| 129 | VIEW | SYS_DBA_SEGS | 37 | 3256 | 1403 (0)| 00:00:20 |
| 130 | UNION-ALL | | | | | |
|*131 | FILTER | | | | | |
| 132 | NESTED LOOPS | | 35 | 3465 | 1015 (1)| 00:00:15 |
| 133 | NESTED LOOPS | | 35 | 3360 | 979 (0)| 00:00:14 |
| 134 | NESTED LOOPS | | 35 | 3115 | 979 (0)| 00:00:14 |
| 135 | NESTED LOOPS | | 119 | 8092 | 860 (0)| 00:00:13 |
|*136 | FILTER | | | | | |
| 137 | NESTED LOOPS OUTER | | 1 | 53 | 844 (0)| 00:00:12 |
|*138 | INDEX SKIP SCAN | I_OBJ5 | 3 | 114 | 841 (0)| 00:00:12 |
| 139 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|*140 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
|*141 | VIEW | SYS_OBJECTS | 3 | 45 | 16 (0)| 00:00:01 |
| 142 | UNION ALL PUSHED PREDICATE | | | | | |
|*143 | TABLE ACCESS CLUSTER | TAB$ | 1 | 25 | 2 (0)| 00:00:01 |
|*144 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | 1 (0)| 00:00:01 |
| 145 | TABLE ACCESS BY INDEX ROWID| TABPART$ | 1 | 18 | 2 (0)| 00:00:01 |
|*146 | INDEX UNIQUE SCAN | I_TABPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
| 147 | TABLE ACCESS CLUSTER | CLU$ | 1 | 14 | 2 (0)| 00:00:01 |
|*148 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | 1 (0)| 00:00:01 |
|*149 | TABLE ACCESS BY INDEX ROWID| IND$ | 1 | 21 | 2 (0)| 00:00:01 |
|*150 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
| 151 | TABLE ACCESS BY INDEX ROWID| INDPART$ | 1 | 18 | 2 (0)| 00:00:01 |
|*152 | INDEX UNIQUE SCAN | I_INDPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
|*153 | TABLE ACCESS BY INDEX ROWID| LOB$ | 1 | 20 | 2 (0)| 00:00:01 |
|*154 | INDEX UNIQUE SCAN | I_LOB2 | 1 | | 1 (0)| 00:00:01 |
| 155 | TABLE ACCESS BY INDEX ROWID| TABSUBPART$ | 1 | 19 | 1 (0)| 00:00:01 |
|*156 | INDEX UNIQUE SCAN | I_TABSUBPART$_OBJ$ | 1 | | 0 (0)| |
| 157 | TABLE ACCESS BY INDEX ROWID| INDSUBPART$ | 1 | 19 | 2 (0)| 00:00:01 |
|*158 | INDEX UNIQUE SCAN | I_INDSUBPART_OBJ$ | 1 | | 1 (0)| 00:00:01 |
| 159 | TABLE ACCESS BY INDEX ROWID| LOBFRAG$ | 1 | 16 | 1 (0)| 00:00:01 |
|*160 | INDEX UNIQUE SCAN | I_LOBFRAG$_FRAGOBJ$ | 1 | | 0 (0)| |
|*161 | TABLE ACCESS CLUSTER | SEG$ | 1 | 21 | 1 (0)| 00:00:01 |
|*162 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
|*163 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 7 | 0 (0)| |
| 164 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|*165 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
|*166 | FILTER | | | | | |
|*167 | FILTER | | | | | |
| 168 | NESTED LOOPS OUTER | | 1 | 77 | 5 (0)| 00:00:01 |
| 169 | NESTED LOOPS | | 1 | 62 | 4 (0)| 00:00:01 |
| 170 | NESTED LOOPS | | 1 | 59 | 3 (0)| 00:00:01 |
| 171 | NESTED LOOPS | | 1 | 34 | 2 (0)| 00:00:01 |
|*172 | TABLE ACCESS BY INDEX ROWID | UNDO$ | 1 | 27 | 2 (0)| 00:00:01 |
|*173 | INDEX RANGE SCAN | I_UNDO2 | 1 | | 1 (0)| 00:00:01 |
|*174 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 7 | 0 (0)| |
|*175 | TABLE ACCESS CLUSTER | SEG$ | 1 | 25 | 1 (0)| 00:00:01 |
|*176 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | 0 (0)| |
| 177 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|*178 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
| 179 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|*180 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
|*181 | FILTER | | | | | |
|*182 | FILTER | | | | | |
| 183 | NESTED LOOPS OUTER | | 1 | 54 | 384 (0)| 00:00:06 |
| 184 | NESTED LOOPS | | 1 | 39 | 383 (0)| 00:00:06 |
| 185 | NESTED LOOPS | | 1 | 36 | 382 (0)| 00:00:06 |
| 186 | TABLE ACCESS FULL | FILE$ | 290 | 3190 | 2 (0)| 00:00:01 |
|*187 | TABLE ACCESS CLUSTER | SEG$ | 1 | 25 | 2 (0)| 00:00:01 |
|*188 | INDEX RANGE SCAN | I_FILE#_BLOCK# | 1 | | 1 (0)| 00:00:01 |
| 189 | TABLE ACCESS CLUSTER | TS$ | 1 | 3 | 1 (0)| 00:00:01 |
|*190 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| |
| 191 | TABLE ACCESS CLUSTER | USER$ | 1 | 15 | 1 (0)| 00:00:01 |
|*192 | INDEX UNIQUE SCAN | I_USER# | 1 | | 0 (0)| |
| 193 | TABLE ACCESS FULL | FILE$ | 290 | 3190 | 2 (0)| 00:00:01 |
| 194 | FIXED TABLE FULL | X$KTFBUE | 100K| 7617K| 24 (100)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------------
有没有办法调整或覆盖这个查询？有没有其他方法可以提高这个命令的速度？
【问题讨论】：
【参考方案1】：确保您拥有相关表的最新优化器统计信息。解释计划中有很多“行 = 1”通常表示计划不好。运行这两个语句来收集统计信息：
begin
dbms_stats.gather_dictionary_stats;
dbms_stats.gather_fixed_objects_stats;
end;
/
如果这样可以解决问题，请与 DBA 合作以确保至少定期运行 gather_dictionary_stats（默认情况下应该如此）。
如果可能，修改 SQOOP 以删除这些冗余谓词可能会有所帮助：
AND o.owner = e.owner
AND o.object_name = e.segment_name
在我的数据库中，删除这两个条件显着改变了计划。
如果统计信息没有帮助，并且您无法修改查询，请尝试使用 SQL Tuning Advisor 来推荐修复计划的方法。
declare
v_task_name varchar2(30);
begin
v_task_name := dbms_sqltune.create_tuning_task(sql_id => 'f9nqqh167x884');
dbms_sqltune.execute_tuning_task(task_name=> v_task_name);
dbms_output.put_line('Task Name: '||v_task_name);
end;
/
select dbms_sqltune.report_tuning_task('TASK_609') from dual;
在我的系统上，它建议创建一个配置文件。配置文件为优化器提供了许多有用的信息，例如“此连接返回的行数确实比估计的多 200%”。
...
-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------
1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
A potentially better execution plan was found for this statement.
Recommendation (estimated benefit: 84.03%)
------------------------------------------
- Consider accepting the recommended SQL profile.
execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_609',
task_owner => 'JHELLER', replace => TRUE);
...
【讨论】：
我不知道在没有补丁的情况下修改查询的方法 - 如果我弄错了，有人可以纠正我吗？此外，它已经使用了绑定变量。 收集统计数据有帮助吗？在开始搞乱执行计划之前，您肯定想先尝试一下。此外，如果它使用绑定变量，您可以在计划中发布它吗？它是否使用:owner 而不是 'FOO' 之类的东西？以上是关于为啥 Oraoop 1.6 在分配内存块之前要等待 1.5 分钟？的主要内容，如果未能解决你的问题，请参考以下文章