2012-02-17 92 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