【发布时间】：2014-02-14 15:03:59
【问题描述】：
试图找出 Oracle 插入性能缓慢的根本原因。我两次运行完全相同的 SQL - 两次都从 Oracle 表中选择 1000 行并插入回同一个表中。第一个 INSERT 在 76 秒内运行。第二个 INSERT（相同的命令）在
INSERT INTO MY_TABLE SELECT * FROM MY_TABLE WHERE ROWNUM
这不是解析问题，INSERT of 1 row (ROWNUM
如果有任何可以帮助的跟踪数据，请告诉我。
（编辑：Gah！-探索了 meta.stackoverflow，找到了将这些数据从 Excel 格式化为 ASCII-Art 的建议，按照建议将结果放在代码标签之间......并且仍然得到了这个乱七八糟的混乱，所有换行符都被删除了...... .. META-HELP 请有人告诉我如何将其格式化为不删除换行符的可读表格！）
╔════════════════════════════════════════════════╦══════════════╦═══════════════╗
║ StatName ║ First Insert ║ Second Insert ║
╠════════════════════════════════════════════════╬══════════════╬═══════════════╣
║ active txn count during cleanout ║ 17 ║ 18 ║
║ buffer is not pinned count ║ 8 ║ 0 ║
║ buffer is pinned count ║ 0 ║ 0 ║
║ bytes received via SQL*Net from client ║ 145 ║ 145 ║
║ bytes sent via SQL*Net to client ║ 79 ║ 79 ║
║ calls to get snapshot scn: kcmgss ║ 4 ║ 1 ║
║ calls to kcmgas ║ 4 ║ 16 ║
║ calls to kcmgcs ║ 49 ║ 50 ║
║ cell physical IO interconnect bytes ║ 16080896 ║ 147456 ║
║ change write time ║ 0 ║ 1 ║
║ cleanout - number of ktugct calls ║ 17 ║ 18 ║
║ consistent gets ║ 71 ║ 68 ║
║ consistent gets - examination ║ 17 ║ 18 ║
║ consistent gets from cache ║ 71 ║ 68 ║
║ consistent gets from cache (fastpath) ║ 50 ║ 50 ║
║ CPU used by this session ║ 17 ║ 3 ║
║ CPU used when call started ║ 0 ║ 0 ║
║ cursor authentications ║ 0 ║ 1 ║
║ db block changes ║ 2131 ║ 2124 ║
║ db block gets ║ 5166 ║ 5160 ║
║ db block gets from cache ║ 5166 ║ 5160 ║
║ db block gets from cache (fastpath) ║ 1035 ║ 1037 ║
║ DB time ║ 7787 ║ 104 ║
║ deferred (CURRENT) block cleanout applications ║ 2 ║ 0 ║
║ enqueue releases ║ 22 ║ 0 ║
║ enqueue requests ║ 25 ║ 0 ║
║ execute count ║ 3 ║ 1 ║
║ file io wait time ║ 76571222 ║ 1010237 ║
║ free buffer inspected ║ 3026 ║ 64 ║
║ free buffer requested ║ 1979 ║ 34 ║
║ Heap Segment Array Inserts ║ 35 ║ 35 ║
║ hot buffers moved to head of LRU ║ 631 ║ 2 ║
║ HSC Heap Segment Block Changes ║ 35 ║ 35 ║
║ IMU Flushes ║ 1 ║ 0 ║
║ index scans kdiixs1 ║ 0 ║ 0 ║
║ logical read bytes from cache ║ 42901504 ║ 42827776 ║
║ logons cumulative ║ 0 ║ 0 ║
║ logons current ║ 0 ║ 0 ║
║ no work - consistent read gets ║ 22 ║ 18 ║
║ non-idle wait count ║ 1732 ║ 19 ║
║ non-idle wait time ║ 7776 ║ 101 ║
║ opened cursors cumulative ║ 3 ║ 1 ║
║ opened cursors current ║ 0 ║ 0 ║
║ parse count (hard) ║ 1 ║ 0 ║
║ parse count (total) ║ 2 ║ 1 ║
║ physical read bytes ║ 16080896 ║ 147456 ║
║ physical read IO requests ║ 1836 ║ 18 ║
║ physical read total bytes ║ 16080896 ║ 147456 ║
║ physical read total IO requests ║ 1836 ║ 18 ║
║ physical read total multi block requests ║ 1 ║ 0 ║
║ physical reads ║ 1963 ║ 18 ║
║ physical reads cache ║ 1963 ║ 18 ║
║ physical reads cache prefetch ║ 253 ║ 0 ║
║ prefetch clients - default ║ 1 ║ 1 ║
║ process last non-idle time ║ 0 ║ 0 ║
║ recursive calls ║ 15 ║ 0 ║
║ recursive cpu usage ║ 0 ║ 0 ║
║ redo entries ║ 1079 ║ 1073 ║
║ redo ordering marks ║ 4 ║ 16 ║
║ redo size ║ 463216 ║ 453624 ║
║ redo subscn max counts ║ 18 ║ 16 ║
║ Requests to/from client ║ 1 ║ 1 ║
║ session connect time ║ 0 ║ 0 ║
║ session cursor cache count ║ 2 ║ 0 ║
║ session cursor cache hits ║ 1 ║ 0 ║
║ session logical reads ║ 5237 ║ 5228 ║
║ session pga memory ║ 393216 ║ 0 ║
║ session pga memory max ║ 393216 ║ 0 ║
║ session uga memory ║ 0 ║ 0 ║
║ session uga memory max ║ 0 ║ 0 ║
║ shared hash latch upgrades - no wait ║ 0 ║ 0 ║
║ sorts (memory) ║ 0 ║ 0 ║
║ sorts (rows) ║ 0 ║ 0 ║
║ SQL*Net roundtrips to/from client ║ 1 ║ 1 ║
║ table fetch by rowid ║ 4 ║ 0 ║
║ table scan blocks gotten ║ 18 ║ 18 ║
║ table scan rows gotten ║ 1017 ║ 1017 ║
║ table scans (long tables) ║ 1 ║ 1 ║
║ table scans (short tables) ║ 0 ║ 0 ║
║ undo change vector size ║ 127384 ║ 126740 ║
║ user calls ║ 2 ║ 2 ║
║ user I/O wait time ║ 7776 ║ 101 ║
║ workarea executions - optimal ║ 0 ║ 0 ║
╚════════════════════════════════════════════════╩══════════════╩═══════════════╝`
【问题讨论】：
-
您确定是 INSERT 需要时间，而不是第一次运行的 SELECT 吗？你试过只运行 SELECT 部分，看看发生了什么
-
是的——绝对是 INSERT。能够通过 2 步重现效果：1）将 1k 行推送到边表 2）将行从边表推送到主表...确认 #1 非常快，#2 非常非常慢...以下接下来在贾斯汀的回答中，可能有更多细节
标签： sql performance oracle oracle11g