ну, бесспорно, в рамках подхода использования temp таблиц — необходимо. Давайте ещё DBMS_LOB прикрутим — тоже в рамках подхода будет необходимо. А то что он тут не нужен — какая разница?
Ок. Просто «лес» то тут то там всплывает как неописанные детали, которые влияют на ирхитектуру того, что написано в статье. Я даю комментарии исходи из того что читаю, и в этом контексте ещё много чего можно улучшить было. Может под вашу бизнес задачу и не подходит, но тогда не объективно ожидать, что ваши читатели знают Ваш контекст задачи.
Согласен, такая проблема есть. Но вероятность отката транзакции присваивания порядкового номера документа (по сути переведение состояния документа в нашем случае была настолько мизерна, что этим можно было пренебречь — хуже было от удалений документов. Приходилось добавлять механизм «сбора дырок» и потом повторного использования пропущенных номеров.
Голословно. Брали и прикручивали. Единственное что — с nocache. И вполне себе решение получалось. Проблемы только если удалили строку потом. Тогда, да, конечно, приходится делать «сборщики дырок» итд, но это отдельная тема.
Ок, вопрос формулировки, суть это не отменяет, что из-за этого утверждения вы добавили ненужные затраты ресурсов в статье про улучшение производитлеьности вставки.
Хм. Любопытно. Это какие другие более эффективные способы в например ERP-alike системе, вы предложите в многопользовательской системе, с конкурирующими 100+ пользователями. Действительно интересно. Если должна быть простая сквозная нумерация (кодирование через «личный номер пользователя»_«дата»_«номер док-та» и прочие подобные неприменимы).
3.2.2 — ошибочное утверждение. Отсюда и весь сыр-бор.
Не надо в bulk вызывать хранимку. Надо в джаве сформировать массив с данными, которые вы хотите вставить и один раз вызвать хранимку, передав на вход массив. В хранимке в bulk-режиме вставить из этого массива в целевую таблицу.
Ваш PS правильный. Именно так и стоило бы сделать.
ой-ой-ой (убегает испуганно). refresh on commit MV не надо (тем более без MV log full refresh на таблице из сотен миллионов строк явно быстро работать не будет, а с MV log-aми, вставка будет тормозить ещё больше!!).
Ну обработка — отдельная тема. Если хотите и есть вопросы, можем в Q&A обсудить проблемы, которые у вас с обработкой возникли. Но тут то мы обсуждали способы максимально быстрой заливки данных… а в этом контексте zhekappp прав — direct path load (write) самый быстрый метод. sqlldr — достаточно нелохой стандартный интерфейс для быстрой bulk-заливки данных.
100%
Либо через библиотеки, через тот же OCI можно заливать данные в режиме direct path write… но и в том и в другом случае от индексов и констрейнтов прийдётся отказаться :)
Ну… если бы вы ваши же показания датчиков выстраивали в строгий хронологический ряд по этой колонке, думаю вы по-другому говорили бы. Ну и с других колоколень пример — бухгалтерский учёт, номера входящих / исходящих документов; номерация документов строгой отчётности итд итп :)
Просто в RAC-е будет влиять на порядки больше, а в этом случае — на единицы процентов (один поток). При очень большом количестве потоков заливаемых данных, упомянутая система в целом вызывает целый ряд дополнительных вопросов, если честно, но они выходят за пределы этой статьи, я полагаю.
На счёт nocache — в исходнике у ТС nocache не упомянут, а по дефолту, кажется было cache 20 (могу сильно ошибаться).
1) PS: кстати, время на запись в сам temp tablespace всё-равно никуда не девается.
2) Ок. Тогда об этом стоило упомянуть в статье, если вы её посвящали инструментам оптимизации по вставке.
6) Тогда действительно «грешны» :)
7) в общем подумайте. index-ы это действительно дорого. На вашей структуре данных, если убрать констрейнты и индексы, я бы ожидал прирост производительности вставки в разы. Делаю ставки, на глаз, на приблизительно 5 раз при действительно массовой вставке (учитывая что у вас грубо 10000 строк в секунду, то только за день у вас около 800 млн строк… тут есть о чём задуматься).
Кстати, а таблицы секционированы? Индексы локальные или глобальные?
8) В данном — да. Но, я полагаю, мы рассматриваем некоторую систему, которая непрерывно получает данные с датчиков? Хотя, конечно, в статье об этом не сказано, но я как то на автомате применил свой опыт. Если мы снимаем 8000 значений, сохраняем их и забываем… то в общем то можно не сильно и беспокоится о производительности ) Просто в буфер всё сохранили, а потом неспешно записали.
1) ну смотря что и как сделаете. Если не выполните все условия, то, конечно, работать не будет. Список необходимых требований там всё таки действительно имеется.
3.1) Хм так может не генерируйте лишнее чтобы потом его не фильтровать? Зачем сначала записывать, чтобы потом фильтровать это? Снова таки — потери по той же производительности в самом факте лишней записи + в дорогих джойнах
3.2) Про Temp — просто моя субъективность основывается на многих годах разработки разных систем на БД, включая ETL-подобные. А в данном случае ещё и просто здравым смыслом, который говорит что вы делаете лишний шаг, который не добавляет никакой пользы. Только теряете на лишнюю запись в temp, а потом чтение из него. Из статьи так и не понятно зачем вы притулили temp таблицу. То что она расходует меньше ресурсов, ещё не повод её использовать. Ведь от того, что LOB эффективнее чем RAW вы не стали использовать ни один из этих типов, правда? Зачем же вы применили temp таблицу? Даже если вы хотите всё-же соединять ваш набор данных с другими таблицами (что при хорошей архитектуре системы тоже будет излишне, уверен), то можно всё равно сразу запустить вошедшую PL/SQL table вместо этой temp таблицы, и в SQL привести его к таблице и с ним работать напрямую.
В любом случае только лишний набор записей / чтения.
Не надо в bulk вызывать хранимку. Надо в джаве сформировать массив с данными, которые вы хотите вставить и один раз вызвать хранимку, передав на вход массив. В хранимке в bulk-режиме вставить из этого массива в целевую таблицу.
Ваш PS правильный. Именно так и стоило бы сделать.
Либо через библиотеки, через тот же OCI можно заливать данные в режиме direct path write… но и в том и в другом случае от индексов и констрейнтов прийдётся отказаться :)
На счёт nocache — в исходнике у ТС nocache не упомянут, а по дефолту, кажется было cache 20 (могу сильно ошибаться).
2) Ок. Тогда об этом стоило упомянуть в статье, если вы её посвящали инструментам оптимизации по вставке.
6) Тогда действительно «грешны» :)
7) в общем подумайте. index-ы это действительно дорого. На вашей структуре данных, если убрать констрейнты и индексы, я бы ожидал прирост производительности вставки в разы. Делаю ставки, на глаз, на приблизительно 5 раз при действительно массовой вставке (учитывая что у вас грубо 10000 строк в секунду, то только за день у вас около 800 млн строк… тут есть о чём задуматься).
Кстати, а таблицы секционированы? Индексы локальные или глобальные?
8) В данном — да. Но, я полагаю, мы рассматриваем некоторую систему, которая непрерывно получает данные с датчиков? Хотя, конечно, в статье об этом не сказано, но я как то на автомате применил свой опыт. Если мы снимаем 8000 значений, сохраняем их и забываем… то в общем то можно не сильно и беспокоится о производительности ) Просто в буфер всё сохранили, а потом неспешно записали.
3.1) Хм так может не генерируйте лишнее чтобы потом его не фильтровать? Зачем сначала записывать, чтобы потом фильтровать это? Снова таки — потери по той же производительности в самом факте лишней записи + в дорогих джойнах
3.2) Про Temp — просто моя субъективность основывается на многих годах разработки разных систем на БД, включая ETL-подобные. А в данном случае ещё и просто здравым смыслом, который говорит что вы делаете лишний шаг, который не добавляет никакой пользы. Только теряете на лишнюю запись в temp, а потом чтение из него. Из статьи так и не понятно зачем вы притулили temp таблицу. То что она расходует меньше ресурсов, ещё не повод её использовать. Ведь от того, что LOB эффективнее чем RAW вы не стали использовать ни один из этих типов, правда? Зачем же вы применили temp таблицу? Даже если вы хотите всё-же соединять ваш набор данных с другими таблицами (что при хорошей архитектуре системы тоже будет излишне, уверен), то можно всё равно сразу запустить вошедшую PL/SQL table вместо этой temp таблицы, и в SQL привести его к таблице и с ним работать напрямую.
В любом случае только лишний набор записей / чтения.