1. Грузи свой файл в BLOB (STORE AS SECUREFILE в Oracle 11g)
для уверенности можешь считать MD5 этого файла, считать MD5 BLOBа и сравнивать.
Потом из BLOBa растаскивай в нужную таблицу одной транзакцией.
Стартовать проверку MD5 и ратаскивание может триггер на таблицу с BLOBом типа AFTER INSERT

2. Создай внешнюю таблицу (external table ... ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER ...)...), загружай данные через нее одной транзакцией,
анализируй наличие bad-файла, используй PREPROCESSOR

3. Другие варианты думай, камрад

askkas,

А что же это за файл такой у тебя могучий, камрад?
Сам его генегишь или получаешь от кого-то, кто его генерит?

SYА с DB сервера файл доступен? Если да, то можно external table c reject limit 0 .
Да, точно! Это оно! Спасибо, камрад! :)

askkasА файлик - это ежедневный отчет, который формируется другой программой и в другом формате - локально. Результаты вычислений планируется хранить на сервере.
Загрузку етого одного (?) файла раз в день делать надо? Или как?

Ету программу ты можешь модернизировать так, чтобы в самом конце была строчка вида


Тут 5123456 - ето число строк которые нужно загрузить из твоего файла
То есть ты еще как-то должен при формировании их посчитать

Ну, или руками добавлять такую строку сможешь?

SYИзя КацманЕту программу ты можешь модернизировать так, чтобы в самом конце была строчка вида

А что это даст? У SQL*Loader буфер не резиновый, посему как наполнится так и будет commit. Посему все равно нужна staging table. Это типичная ETL задача. Грузи в staging table. Анализируй SQL*Loader лог. Нет ошибок, запускай следующий шаг - insert из staging table в основную.Ето даст возможность последнюю строчку загружать в другую таблицу,
у которой будет триггер, который выполнит всю необходимую обработку

То есть:
1. Если в позициях 1:11 не содержится MY_FILE_END, грузим данные в staging table 1
2. Если в позициях 1:11 содержится MY_FILE_END, грузим ету строку в staging table 2
3. Запускается триггер AFTER INSERT FOR EACH ROW, имеющийся у staging table 2
Етот триггер проверяет число загруженных строк
- если оно совпадает с указанным в строке MY_FILE_END 5123456,
то данные из staging table 1 переписываются в target table
- если оно НЕ совпадает с указанным в строке MY_FILE_END 5123456,
то данные из staging table 1 НЕ переписываются в target table,
а в таблицу лога загрузки записывается информация о возникшей коллизии

Изя КацманSYпропущено...

А что это даст? У SQL*Loader буфер не резиновый, посему как наполнится так и будет commit. Посему все равно нужна staging table. Это типичная ETL задача. Грузи в staging table. Анализируй SQL*Loader лог. Нет ошибок, запускай следующий шаг - insert из staging table в основную.Ето даст возможность последнюю строчку загружать в другую таблицу,
у которой будет триггер, который выполнит всю необходимую обработку
Недостаток етого подхода в том, что придется выставить для SQL*Loader параметр ROWS=1
Тогда COMMIT будет после каждой строки и всё сработает штатно
Но COMMIT после каждой строки, выполненный 50 млн. раз может сильно повысить нагрузку на БД
А как иначе сделать, чтобы триггер, имеющийся у staging table 2, получил консистентное состояние staging table 1 я не знаю

Хотя вроде бы оно все равно должно получиться,
даже если COMMIT будет через произвольное число строк.
Нет?