我想在同一时间与甲骨文插入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