just_vladimirЭто то, чего бы очень хотелось избежать ... Просто удивляет, почему в MySQL и PostgreSQL соответствующий API предусмотрен в рамках jdbc драйвера, а в Oracle он запрятан во внешнюю утилиту...

Вообще-то, JDBC это стандарт.
Хотелось бы увидеть ссылку на ту страницу __стандарта__ где это описано.

maytonjust_vladimirэффективно загрузить файл (прочитать Apache Commons CSV, потом вставить через addBatch/executeBatch, выполняя insert с хинтом /* +append */)
Ты вообще понимешь как работает хинт "+append" ?

А что не так ?

Если верить I-net'у addBatch / executeBatch в Oracle JDBC порождают нормальный Bulk insert вызов SQL. Т.ч. весь пакет будет выполнен одной командой, соответственно append (если я правильно понимаю) уменьшит нагрузку на Redo и аллокацию. Если I-net не врет. Лично я бы доки Oracle перечитал.

Другое дело, что кроме плюсов, append и минусы имеет. Огромные. Использованием append очень легко всю систему убить (наблюдал такое на реальной задаче в ERP системе)

just_vladimirПодождите, подождите....

Тогда зачем вообще упоминать JDBC всуе )))

just_vladimirВ общем задача стандартная и распространенная, есть csv файл, который нужно максимально эффективно протолкнуть в БД.

Ну Oracle дает 100500 способов это сделать. Зачем для решения этой задачи вообще Java ?

Я могу назвать 100500 причин почему это делать не нужно. Но лучше это обсуждать за пивом, а не на Инет форуме.

just_vladimirВ общем задача стандартная и распространенная...

Ровно так же, как стандартная и распространеная задача - форматирования диска. А PostgreSQL и MySQL полный отстой, т.к. такой команды в JDBC не сделали )))

maytonВ твоей постановке хинт append будет бесполезен.
Почему? В какой постановке и что значит полезен?

Direct patch load, из плюсов, как минимум должно redo log уменьшится. Ну и минусов в реальной жизни полно. Т.ч. я бы не злоупотреблял.

p.s. вроде не offtopic, напрямую с вопросом автора связано.

AFAIK

Я бы сформулировал проблему в двух пунктах:

1) Приведет ли addBatch / executeBatch в Oracle JDBC к полноценному Array / bulk insert'у.
Т.е. к передаче по сети и вставки всего пакета данных ОДНОЙ командой.

Вроде да.
http://oracle-internals.blogspot.ru/2012/09/plsql-bulk-insert-jdbc-batchexecute.html

2) Приведет ли использование хинта append в команде insert к direct path load'у ?

В Inet-е встречается утверждение, что direct path только для конструкции INSERT from SELECT.

Посмотрел доку, в http://docs.oracle.com/cd/B10501_01/server.920/a96540/statements_913a.htm#2063932 про это ни слово /но полно других ограничений/.

В подфоруму Oracle утверждается, что есть некая терминологическая путаница. Bulk insert как обозначение для конкретной конструкции PL/SQL - при которой direct path НЕ работает. И bulk insert просто применительно к методу вставки многих данных за раз в SQL.

Т.е. "bulk insert PL/SQL" директом не бывает, нужен INSERT from SELECT

Но в SQL, просто INSERT /*+append*/ VALUES () вполне себе работает. Иначе как direct path load с клиента запускать?

повторюсь

В последние несколько лет периодически всплывает. При этом в "баянистом" виде (((

Но с другой стороны, тема важная /интеграция, обмен данных, performance/, нужная и наверное не простая /раз всплывает/

maytonв скобках замечу что точно также как и в PGSQL, MySQL

Не совсем. CSV к SQL никакого отношения не имеет, поэтому в Oracle решается внешними утилитами. В Postgres это зачем-то реализовано на уровне ядра СУБД.

Если кто считает по другому - просьба ссылку на стандарт ANSI SQL описывающий команды работы с CSV

1)
Oracle JDBC нормально поддерживает array / bulk операции при insert. В том числе, поддерживает direct path load. Хотя в одной из прошлых тем, термин direct path load от Oracle участниками трактовался не однозначно.

Что, и теоретически, и практически, позволяет на СТАНДАРТНОМ JDBC обеспечить функциональность и производительно близкую к специальным инструментам (sqlloader)

http://www.sql.ru/forum/1245207/java-i-api-directpath-oracle

2)
Postgre SQL array / bulk операции на вставку поддерживает через одно место. Максимум, может сцепить все команды в одну строчку. (вроде как и MySQL).

Поэтому, для массовой вставки команда INSERT в PgSQL не годится как класс. Приходится использовать команду COPY, которая, командой SQL (в нормальном смысле этого слова) НЕ ЯВЛЯЕТСЯ.

И специально для команды COPY изобретать "велосипед" как ей скармливать данные.

Замечу, что при этом, создав сей велосипед, авторы не удосужились написать форматеры/парсеры для типов данных поддерживаемых PgSQL. И, даже, не описали форматы. В документации PgSQL для команды COPY в binary режиме просто написано - возьмите исходный код на C и посмотрите в нашем исходном коде )))

В общем, из за убожества PgSQL изобретен "велосипед":

a) Команда COPY реализована на уровне ядра СУБД. Что, понятно, ни в каких стандартах SQL нет и любому стандарту SQL противоречит
b) В драйверах сделан велосипед, позволяющий использовать велосипед из СУБД. Что, опять таки, никакого отношения к JDBC не имеет.

В общем, от криворукости сотворили [мат вырезан] "дырочку" которая никаким образом к "задача стандартная и распространенная" не относится.

Еще одна такая криворукость PgSQL - тип text / binary. То есть, она тоже может показаться удобной "дырочкой" ))) например не имеет ограничения 4000 как varchar2 в Oracle. Пока, в этой дырочке, что нибудь не застрянет (((

Note: жизненная мудрость. Есть что нибудь в дырочку не впихивается, это пол беды, всегда есть вазелин. А вот если там что нибудь застревает - это уже серьезно. Т.ч. перед тем как запихивать что нибудь сложно впихуемое, лучше подумать.

Vladimir Baskakovсвязывал последовательно и экзекьютил раз за разом.

Экзекьютить можно целиком пакет. В оптимале, весь пакет данных из многих строк БД пойдет на сервер одним сетевым round trip'ом.

Первая ссылка из google (внимательно читать комментарии под статьей!):

http://betteratoracle.com/notes/25-array-batch-inserts-with-jdbc