试图找出Oracle插入性能缓慢的根本原因。我运行完全相同的SQL两次 - 两次从Oracle表中选择1000行并插回到同一个表中。第一次INSERT运行76秒。第二个INSERT（相同的命令）在＆lt; 1秒。很想听听关于前者可能会发生什么的任何想法。
插入MY_TABLE SELECT * from MY_TABLE WHERE ROWNUM＆lt; = 1000;
这不是一个解析问题，1行INSERT（ROWNUM＆lt; = 1）在first-1000-row-insert之前运行，并且运行速度非常快。
如果有任何跟踪数据有帮助，请告诉我。
（编辑：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 ║
╚════════════════════════════════════════════════╩══════════════╩═══════════════╝`
答案 0 :(得分：3)
两者之间的差异似乎主要是由于物理读数的差异。这意味着当您运行第一个INSERT语句时，SELECT所需的块不在缓存中，必须从磁盘读取。当您再次运行该语句时，您需要的块仍然在缓存中，因此您只需从RAM中读取它们。显然，从RAM读取比从磁盘读取要快得多。
话虽这么说，很难想象从磁盘（file io wait time从76秒的北部到北部，从磁盘读取1000行数据（总共约16 MB）真的需要76秒1秒，physical read bytes从16 MB到150 kb）。这是一个相当疯狂的I / O速度，这意味着底层磁盘子系统存在某种问题。