我想在同一時間與甲骨文插入1000行甲骨文插入1000行同時
例子:
INSERT INTO MSG(AUTHOR)
SELECT AUTHOR FROM oldDB.MSGLOG
該插入走的是一條很長的時間,但如果我用ROWNUM限制它< = 1000它會馬上插入,所以我想創建一個導入,通過我的X行數,並在時間插入1000。
感謝
我想在同一時間與甲骨文插入1000行甲骨文插入1000行同時
例子:
INSERT INTO MSG(AUTHOR)
SELECT AUTHOR FROM oldDB.MSGLOG
該插入走的是一條很長的時間,但如果我用ROWNUM限制它< = 1000它會馬上插入,所以我想創建一個導入,通過我的X行數,並在時間插入1000。
感謝
這是相當令人懷疑,這真的會提高性能,特別是考慮到SELECT
語句的簡單性。這必須是對錶格或author
上的索引進行全面掃描。如果該掃描速度較慢,則診斷潛在問題要好得多,而不是嘗試解決該問題(例如,可能oldDB.MsgLog
在高位標記下面有多個空白塊,這會迫使全表掃描讀取更多塊比絕對必要)。
如果你真的想多寫一些冗長和低效率的PL/SQL來完成任務,不過,你當然可以
DECLARE
TYPE tbl_authors IS TABLE OF msg.author%TYPE;
l_authors tbl_authors;
CURSOR author_cursor
IS SELECT author
FROM oldDB.MsgLog;
BEGIN
OPEN author_cursor;
LOOP
FETCH author_cursor
BULK COLLECT INTO l_authors
LIMIT 1000;
EXIT WHEN l_authors.count = 0;
FORALL i IN 1..l_authors.count
INSERT INTO msg(author)
VALUES(l_authors(i));
END LOOP;
END;
我的select語句更復雜,我只是簡化了。謝謝 –
@SeanKeane - 如果PL/SQL方法更快,這強烈暗示SELECT語句的查詢計劃不正確。如果查詢計劃不正確,則強烈暗示基礎表上的統計信息不正確。如果統計數據不正確,修復基礎統計數據比解決問題更合適,因爲它不可避免地會影響許多不同的查詢。 –
以一杆做的(不知道你的ENV的東西,但基於上述)嘗試插入/ * + append * /或創建表msg作爲來自oldDB.msglog的選擇作者。 – tbone