2012-02-17 57 views
2

我有针对11g数据库运行的SQL * Loader脚本。
我正在使用11g版本的SQL * Loader。SQL * Loader有时会永久挂起

我遇到了一个问题,即在插入最后一条记录后,但在将最终提交计数打印到命令窗口之前以及打印到日志文件之前,SQL * Loader挂起。

这对我们局域网上的数据库似乎工作正常,但在局域网外的数据库上运行时会挂在这里。

如果我手动杀死进程,所有记录都会成功加载到数据库中。

在.bat文件:

sqlldr CONTROL='SOME_TABLE.ctl' log='logs/SOME_TABLE.log' bad='bad/SOME_TABLE.bad' skip=1 

在.CTL文件:

OPTIONS(direct=true, rows=20000) 
load data 
infile 'data/SOME_TABLE.csv' 
append 
into table SOME_TABLE 
fields terminated by ',' 
OPTIONALLY ENCLOSED BY '"' AND '"' 
trailing nullcols (
    FIELD01  CHAR(38), 
    FIELD02  CHAR(500), 
    FIELD03  CHAR(34), 
    FIELD04  CHAR(1), 
    FIELD05  CHAR(1), 
    FIELD06  CHAR(10), 
    FIELD07  CHAR(2), 
    FIELD08  CHAR(5), 
    FIELD09  CHAR(2), 
    FIELD10  CHAR(5), 
    FIELD11  CHAR(5), 
    FIELD12  CHAR(4), 
    FIELD13  CHAR(2), 
    FIELD14  CHAR(9), 
    FIELD15  CHAR(9), 
    FIELD16  TIMESTAMP  "YYYY-MM-DD HH24:MI:SS.FF6", 
    FIELD17  TIMESTAMP  "YYYY-MM-DD HH24:MI:SS.FF6", 
    FIELD18  CHAR(38), 
    FIELD19  CHAR(2), 
    FIELD20  TIMESTAMP  "YYYY-MM-DD HH24:MI:SS.FF6", 
    FIELD21  CHAR(2), 
    FIELD22  CHAR(38), 
    FIELD23  DATE   "MM/DD/YYYY", 
    FIELD24  CHAR(15), 
    FIELD25  DATE   "MM/DD/YYYY", 
    FIELD26  CHAR(15), 
    FIELD27  CHAR(3), 
    FIELD28  CHAR(5), 
    FIELD29  CHAR(4), 
    FIELD30  CHAR(10), 
    FIELD31  CHAR(10), 
    FIELD32  CHAR(1), 
    FIELD33  CHAR(4), 
    FIELD34  CHAR(1), 
    FIELD35  CHAR(1), 
    FIELD36  CHAR(1) 
) 

表DDL:

-------------------------------------------------------- 
-- DDL for Table SOME_TABLE 
-------------------------------------------------------- 
CREATE TABLE SOME_TABLE (
    FIELD01  NUMBER(*,0)   NOT NULL, 
    FIELD02  FLOAT(126)   NOT NULL, 
    FIELD03  VARCHAR2(34)   NULL, 
    FIELD04  CHAR(1)     NULL, 
    FIELD05  CHAR(1)     NULL, 
    FIELD06  CHAR(10)    NULL, 
    FIELD07  CHAR(2)     NULL, 
    FIELD08  CHAR(5)     NULL, 
    FIELD09  CHAR(2)     NULL, 
    FIELD10  CHAR(5)     NULL, 
    FIELD11  CHAR(5)     NULL, 
    FIELD12  CHAR(4)     NULL, 
    FIELD13  CHAR(2)     NULL, 
    FIELD14  CHAR(9)     NULL, 
    FIELD15  CHAR(9)     NULL, 
    FIELD16  TIMESTAMP(6)  NOT NULL, 
    FIELD17  TIMESTAMP(6)  NOT NULL, 
    FIELD18  NUMBER(*,0)    NULL, 
    FIELD19  CHAR(2)     NULL, 
    FIELD20  TIMESTAMP(6)   NULL, 
    FIELD21  CHAR(2)     NULL, 
    FIELD22  NUMBER(*,0)    NULL, 
    FIELD23  DATE     NULL, 
    FIELD24  VARCHAR(15)    NULL, 
    FIELD25  DATE     NULL, 
    FIELD26  VARCHAR(15)    NULL, 
    FIELD27  CHAR(3)     NULL, 
    FIELD28  CHAR(5)     NULL, 
    FIELD29  CHAR(4)     NULL, 
    FIELD30  VARCHAR2(10)   NULL, 
    FIELD31  VARCHAR2(10)   NULL, 
    FIELD32  CHAR(1)     NULL, 
    FIELD33  CHAR(4)     NULL, 
    FIELD34  CHAR(1)     NULL, 
    FIELD35  CHAR(1)     NULL, 
    FIELD36  CHAR(1)     NULL 
) 
    NOLOGGING 
    NOCOMPRESS 
    TABLESPACE RAW_DATA_01_TS 
    PCTFREE 10 
    INITRANS 1 
    MAXTRANS 255 
    STORAGE (
       INITIAL   64K 
       BUFFER_POOL  DEFAULT 
       ) 
PARTITION BY RANGE(FIELD16) INTERVAL(NUMTODSINTERVAL(10, 'MINUTE')) (
    PARTITION SOME_TABLE_201001010000 VALUES LESS THAN (TO_DATE('2010-01-01 00:00', 'YYYY-MM-DD HH24:MI')) 
); 

预计:

SQL*Loader: Release 11.2.0.1.0 - Production on Fri Feb 17 10:36:14 2012 

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 

Load completed - logical record count 252593. 

实际:

SQL*Loader: Release 11.2.0.1.0 - Production on Fri Feb 17 10:36:14 2012 

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 
+0

设置DIRECT = FALSE似乎已解决了悬挂问题。现在我只需要知道为什么当DIRECT = TRUE被使用时挂起。它对我们的本地数据库工作正常,但对于远程数据库中的最大数据库挂起。 – ScrappyDev 2012-02-22 13:54:07

+0

在谈到数据库操作时,网络延迟相当重要。本地局域网上的数据库运行速度远远超过远程位置。 – Nick 2012-05-13 16:10:05

回答

0

我怀疑这是与DIRECT=TRUE。 Oracle必须在流程结束时重新验证索引和约束。如果你的桌子很大,这可能会很长。

+0

这张表上没有任何索引或约束。除非你说分区有隐藏索引? – ScrappyDev 2012-02-20 23:27:18

+0

@scrappythenell:也许不是......你是否尝试过删除DIRECT = TRUE并测量持续时间? – Benoit 2012-02-21 06:06:57

+0

设置DIRECT = FALSE似乎已解决了悬挂问题。现在我只需要知道为什么当使用'DIRECT = TRUE'时挂起。 – ScrappyDev 2012-02-22 13:52:18