Задание загрузчика SQL * неожиданно завершается и вызывает блокировку таблицы с помощью NOWAIT - PullRequest
Новая
       30

Задание загрузчика SQL * неожиданно завершается и вызывает блокировку таблицы с помощью NOWAIT

0 голосов
/ 08 июля 2011

У меня есть еженедельный отчет, который я запускаю, где мне нужно загрузить около 48 журналов с примерно 750 тыс. Строк данных в каждом журнале. Чтобы облегчить это, мы использовали задание Java, которое запускает SQL * Loader как внешний процесс (используя ProcessBuilder), один за другим. Однако в последнее время этот процесс ненормально завершается во время загрузки, что вызывает блокировку таблицы и в основном приводит к остановке процесса до тех пор, пока мы не сможем открыть заявку с командой БД, чтобы убить зависший сеанс. Возможно, есть лучший способ обработать этот процесс загрузки, чем использование SQL * Loader, или я могу внести некоторые изменения в управляющий файл или командную строку, чтобы предотвратить смерть от ужасной смерти?

В начале процесса я усекаю таблицу, в которую загружаю, и затем запускаю эту командную строку со следующим управляющим файлом:

КОМАНДНАЯ ЛИНИЯ: 

C:\Oracle\ora92\BIN\SQLLDR.EXE userid=ID/PASS@DB_ID load=10000000 rows=100000 DIRECT=TRUE SKIP_INDEX_MAINTENANCE=TRUE control=ControlFile.ctl data=logfile.log

ФАЙЛ УПРАВЛЕНИЯ: 

UNRECOVERABLE
Load DATA
INFILE *
Append
PRESERVE BLANKS
INTO TABLE MY_REPORT_TABLE
FIELDS TERMINATED BY ","
(
filler_field1 FILLER char(16),
filler_field2 FILLER char(16),
time TIMESTAMP 'MMDDYYYY-HH24MISSFF3' ENCLOSED BY '"',
partne ENCLOSED BY '"',
trans ENCLOSED BY '"',
vendor ENCLOSED BY '"' "SUBSTR(:vendor, 1, 1)",
filler_field4 FILLER ENCLOSED BY '"',
cache_hit_count,
cache_get_count,
wiz_trans_count,
wiz_req_size,
wiz_res_size,
wiz_trans_time,
dc_trans_time,
hostname ENCLOSED BY '"',
trans_list CHAR(2048) ENCLOSED BY '"' "SUBSTR(:trans_list, 1, 256)",
timeouts,
success ENCLOSED BY '"'
)

После завершения загрузки всех журналов я перестраиваю индексы в таблице и затем запускаю процесс отчета. Кажется, что теперь он просто умирает от случайных логов, при повторном запуске процесса каждый раз он будет завершаться неудачей.

Причинами UNRECOVERABLE и SKIP_INDEX_MAINTENANCE являются ускорение загрузки. Как бы то ни было, загрузка журнала может занять 7-12 минут, еще хуже, если они не включены. В целом, процесс от начала до конца занимает около 18 часов.

Ответы [ 2 ]

0 голосов
/ 08 июля 2011

100000 довольно мало, но уточните у своего администратора базы данных, достаточно ли отмены для всех этих вставок ... попросите их контролировать его во время выполнения процесса

Также что-нибудь в logfile.log? Также попросите своего администратора базы данных проверить наличие alert.log

С уважением,

0 голосов
/ 08 июля 2011

Что вы имеете в виду «умирая»?Есть ли что-нибудь в журнале?

Если вам нужно заставить администраторов баз данных завершить сеанс, это означает, что сеанс базы данных все еще активен.Если это так, это либо загрузка, ожидание или откат после ошибки.Узнайте из администраторов баз данных, что он делает.Если он откатывается, вы должны дать этому завершиться, чтобы ошибка могла быть возвращена.

Я бы посмотрел на внешние таблицы, а не на загрузчик SQL.Эти файлы должны быть доступны на сервере БД, но это упрощает работу с SQL, что может означать лучшую обработку ошибок.

...