4

我正在使用 C# .NET 4.0 应用程序，它使用 ODP.NET 11.2.0.2.0 和 Oracle 11g 数据库。该应用程序预加载了一些带有数据的查找表，并且由于大多数的记录少于 20 条，因此脚本运行得非常快。但是，其中一个脚本有 802 条记录，并且需要 248.671 秒来插入记录，对于这样的少量数据以及宣传大量数据的快速操作的数据库来说，这似乎是多余的。

所以我想知道，有没有比当前编写脚本的方式更快的方式通过脚本插入数据？

插入的表定义如下：

CREATE TABLE FileIds
(
     Id                 NUMERIC(38)                         NOT NULL
    ,Name               NVARCHAR2(50)   DEFAULT 'Unknown'   NOT NULL 
    ,FileTypeGroupId    NUMERIC(38)                         NOT NULL
    ,CONSTRAINT FK_FileIds_FileTypeGroups FOREIGN KEY ( FileTypeGroupId ) REFERENCES FileTypeGroups ( Id )
)

要插入的脚本如下所示：

BEGIN
    INSERT ALL
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1152,5)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1197,10)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1200,6)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1143,3)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1189,9)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1109,7)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1166,4)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (0,8)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1149,2)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1400,1)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1330,11)
        INTO FileIds ( Id, FileTypeGroupId ) VALUES (1000,0)
        -- 790 Records removed for example purposes.
        SELECT * FROM DUAL;
    COMMIT;
END;

外键中引用的 FileTypeGroups 表是在加载 FileIds 表之前预加载的。没有与 FileIds 表关联的序列或触发器，并且到目前为止还没有为该表创建索引。

4

1 回答 1

5

问题

解析时间可能会随着某些类型的语句呈指数增长，尤其是INSERT ALL. 例如：

--Clear any cached statements, so we can consistently reproduce the problem.
alter system flush shared_pool;
alter session set sql_trace = true;

--100 rows
INSERT ALL
    INTO FileIds(Id,FileTypeGroupId) VALUES(1, 1)
    ...
    repeat 100 times
    ...
select * from dual;

--500 rows
INSERT ALL
    INTO FileIds(Id,FileTypeGroupId) VALUES(1, 1)
    ...
    repeat 500 times
    ...
select * from dual;

alter session set sql_trace = false;

通过 tkprof 运行跟踪文件，您可以看到大量行的 Parse 时间急剧增加。例如：

100 行：

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.06       0.05          0          1          0           0
Execute      1      0.00       0.00          0        100        303         100
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.06       0.05          0        101        303         100

500 行：

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1     14.72      14.55          0          0          0           0
Execute      1      0.01       0.02          0        502       1518         500
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2     14.74      14.58          0        502       1518         500

解决方案

  1. 把你的大陈述分成几个小陈述。很难找到最佳尺寸。在某些版本的 Oracle 中，会导致问题的行数非常多。我通常会选择大约 100 行 - 足以获得分组语句的大部分好处，但又足够低以避免解析错误。或者...
  2. 试试这个insert into ... select ... from dual union all ...方法。它通常运行得更快，尽管它的解析性能也可能随着大小而显着下降。
  3. 升级甲骨文。解析性能在较新版本中有所提高。我无法再在 12.2 版中重现此问题。

警告

不要从中吸取错误的教训。如果您担心 SQL 性能，那么在 99% 的情况下，您最好将相似的事物组合在一起，而不是将它们分开。你以正确的方式做事，你只是遇到了一个奇怪的错误。（我搜索了 My Oracle Support，但找不到官方的错误。）

于 2012-07-26T05:42:07.313 回答