• Загружаем данные в Oracle
    0
    Можно в студию, сам запрос / код на котором выпадает? То что большей частью выпадает на металинке на ORA-600 [6704] — это ошибки при SELECT FOR UPDATE, но это не ваш случай, а также на партиционированые таблицы, что снова таки, в основном — не ваш случай.
  • Загружаем данные в Oracle
    0
    1) Сорри, глубоко анализировать трейсы некогда, но что броислось в глаза, это фул сканы таблиц из которых (по моему пониманию выших данных) должно выниматься сравнительно мало строк. Либо они настолько маленькие, что одним multiblock read-ом вычитывается вся таблица, либо на справочных таблицах индексов добавиьт не помешало бы.

    2) зачем dynamic sampling? Лучше соберите или постройте / импортируйте нормальную статистику по объектам.

    3) Из «collection»:

    > MERGE JOIN CARTESIAN

    ойойой! не знаю что вы там делаете, но чуйкой чую что-то не то.

    … Больше не копал, сорри. Но у меня усиленное чувство, смотря на PL/SQL код что там ещё очень много чего можно переписать сильно оптимальнее, убрав / переделав процесс. Но это будет больше логическая / архитектурная оптимизация, чем техническая. Но она, как раз, как правило даёт больше пользы :)
  • Загружаем данные в Oracle
    0
    Хм. Код стал уже действительно достаточно навороченный и проблемы с производительностью могут быть очень во многих местах.
    Очень удивило что bulk работает в вашем случае в два раза медленнее чем temporary. Интересно было бы покопать почему…
  • Загружаем данные в Oracle
    0
    Ну, в общем-то, с этим всем никто не спорит. Просто в RAC-система это конкурирование видно особо ярко.
    А в одноинстасевой системе, причём в примере — вставка в один поток, этот самый датаблок с большой вероятностью оказывается в database buffer cache, потому проблема не столь ярка (что не отменяет описанного обращения в seq$). Подтверждение чего мы и увидели на цифрах
  • Загружаем данные в Oracle
    0
    Действительно занимательная презентация, спасибо. Неплохо собраны возможности по настройке с административной стороны. Ещё бы комментарии хорошего лектора бы по ней послушать…
  • Загружаем данные в Oracle
    0
    В целом согласен. Наверное за сложным техническим оракл вопросом, на который я не нашёл бы ответа ни в интернете ни среди коллег, я бы пошёл таки на sql.ru… или на otn.oracle.com.
    Но, как-то, по большей части вопросы возникают не чисто по oracle (большинство вопросов по оракл что могут возникнуть уже отвечены где-либо, стоит лишь погуглить), а на стыке технологий, создании хорошей архитектуры в целом итд… и вот в этом плане sql.ru уже вопрос… формат не тот. Всё-таки это уже ближе к каким-то статьям-обсуждениям, не находишь?
  • Загружаем данные в Oracle
    +1
    external tables работают на механизме sqlldr. его вам уже предлагали. (вариант с exteranl tables на data pump не вспоминаю ибо вообще не в тему).

    попробовать можете, конечно. Если добъетесь direct path write (снова уже обсуждали), то может и получите определённые преимущества… но есть и много недостатков.
    1) вы говорили что вы планировали использовать одновременно несколько потоков для заливки. Это уже поставит под вопрос direct path write, и, в идеале, потребует некоторой переработки текущей архитектуры (на ваше усмотрение, конечно, но всё же).
    2) sqlldr / ext table потребует предварительно выгрузить ваши данные в файл, а потом их загрузить — а это ещё один промежуточный буфер (причём на жёстком диске, а не в оперативке!!!), что явно не скажется положительно на производительности.

    Исходя из этих размышлений я против sqlldr.
  • Cтудентов-айтишников принуждают трудиться на сборке PlayStation 4
    +1
    Подтверждаю. Та же ситуация. Но на первом курсе было немного стрёмно подписывать бумагу, где я соглашался отработать 3 года там куда пошлют на неизвестно каких условиях либо компенсировать цену моего обучения.
  • Cтудентов-айтишников принуждают трудиться на сборке PlayStation 4
    +2
    Ну, нас в КПИ так и заставили на первом курсе такую бумагу подписать. Со словами — не нравится — не подписывайте — на бюджет есть ещё много желающих. Правда по выходу никто никого не распределял, более того, для поддержания статистики обязали принести справку из какой-либо конторы, что она принимает тебя как молодого специалиста и собирается тебе платить ЗП согластно конторского штатного расписания. Посколько я уже имел работу в то время, то меня это не напрягло — директор прочитав внимательно бумажку проштамповал и сказал «наконец ты не будешь с работы в свой универ бегать»
  • Загружаем данные в Oracle
    0
    Если бы ещё был механизм который бы там заодно отсеивал совсем уж рьяных хамов… (За что мне и нравится хабр- думаю пояснять не нужно).
  • Загружаем данные в Oracle
    +1
    Мне там некомфортно. Все какие-то аггресивные, по сути говорят мало, а хамства и высокомерия — много. Если бы при этом хотя бы подробно говорили что имеют в виду — ок, а так, как только задаёшь сложный вопрос — никого нету. А по простым «чего с глупостями своими вылез»… Так о чём говорить то?
  • Загружаем данные в Oracle
    0
    Форум? Это ты про sql.ru что-ли?
  • Загружаем данные в Oracle
    0
  • Загружаем данные в Oracle
    0
    Спасибо
  • Загружаем данные в Oracle
    0
    Да.
  • Загружаем данные в Oracle
    0
    1. Понял, спасибо. Согласен, можно и так. Правда я OR конструкции очень не люблю. Надо на план получившегося смотреть. Как бы не получилось что оракл это всё равно превратил в union all. Но с insert all тоже может иногда быть не сахар. Надо сравнивать.
    2. ок, в любом случае пишите, уже любопытно понаблюдать до чего это всё докатится.
  • Загружаем данные в Oracle
    0
    Привет. Вот и xtender подключился. В тредах везде те-же лица :)

    Нет, это другое. В этом месте я предлагал заменить два
    insert into hist_table select temp_table /*… там ещё куча одинаковых join*/;
    insert into hist_table select temp_table /*… там ещё куча одинаковых join*/;
    Одним
    insert all
    into hist_table (cols) values (values)
    into hist_table (cols) values (some other values)
    select * from temp_table /*… там ещё куча одинаковых join*/;

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