SQL * Loader Hangs forever иногда

У меня есть SQL * Скрипты загрузчика Я бегу против базы данных 11g.
Я использую 11g версию SQL * Loader.SQL * Loader Hangs forever иногда

У меня возникла проблема, когда 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.

источник

2012-02-17 ScrappyDev

Установка DIRECT = FALSE, похоже, устраняет проблему подвески. Теперь мне просто нужно знать, почему он зависает, когда используется DIRECT = TRUE. Он отлично работает с нашей локальной базой данных, но зависает для самых больших в удаленных базах данных. – ScrappyDev

Сетевая латентность имеет значение, когда речь идет о операциях с базой данных. Базы данных в локальной локальной сети будут работать значительно быстрее, чем те, которые расположены удаленно. – Nick

Я подозреваю, что это связано с DIRECT=TRUE. Oracle должна пересмотреть индексы и ограничения в конце процесса. Если ваш стол очень большой, это может быть так же долго.

источник

2012-02-18 08:29:04 Benoit

В этой таблице нет никаких индексов или ограничений. Разве вы не говорите, что есть скрытые индексы для разбиения? – ScrappyDev

@scrappythenell: Возможно, нет ... вы пытались удалить DIRECT = TRUE и продолжительность измерения? – Benoit

Установка 'DIRECT = FALSE', похоже, устраняет проблему подвески. Теперь мне просто нужно знать, почему он зависает, когда используется 'DIRECT = TRUE'. – ScrappyDev

SQL * Loader Hangs forever иногда

ответ

Смежные вопросы