Можно в студию, сам запрос / код на котором выпадает? То что большей частью выпадает на металинке на ORA-600 [6704] — это ошибки при SELECT FOR UPDATE, но это не ваш случай, а также на партиционированые таблицы, что снова таки, в основном — не ваш случай.
1) Сорри, глубоко анализировать трейсы некогда, но что броислось в глаза, это фул сканы таблиц из которых (по моему пониманию выших данных) должно выниматься сравнительно мало строк. Либо они настолько маленькие, что одним multiblock read-ом вычитывается вся таблица, либо на справочных таблицах индексов добавиьт не помешало бы.
2) зачем dynamic sampling? Лучше соберите или постройте / импортируйте нормальную статистику по объектам.
3) Из «collection»:
> MERGE JOIN CARTESIAN
ойойой! не знаю что вы там делаете, но чуйкой чую что-то не то.
… Больше не копал, сорри. Но у меня усиленное чувство, смотря на PL/SQL код что там ещё очень много чего можно переписать сильно оптимальнее, убрав / переделав процесс. Но это будет больше логическая / архитектурная оптимизация, чем техническая. Но она, как раз, как правило даёт больше пользы :)
Хм. Код стал уже действительно достаточно навороченный и проблемы с производительностью могут быть очень во многих местах.
Очень удивило что bulk работает в вашем случае в два раза медленнее чем temporary. Интересно было бы покопать почему…
Ну, в общем-то, с этим всем никто не спорит. Просто в RAC-система это конкурирование видно особо ярко.
А в одноинстасевой системе, причём в примере — вставка в один поток, этот самый датаблок с большой вероятностью оказывается в database buffer cache, потому проблема не столь ярка (что не отменяет описанного обращения в seq$). Подтверждение чего мы и увидели на цифрах
Действительно занимательная презентация, спасибо. Неплохо собраны возможности по настройке с административной стороны. Ещё бы комментарии хорошего лектора бы по ней послушать…
В целом согласен. Наверное за сложным техническим оракл вопросом, на который я не нашёл бы ответа ни в интернете ни среди коллег, я бы пошёл таки на sql.ru… или на otn.oracle.com.
Но, как-то, по большей части вопросы возникают не чисто по oracle (большинство вопросов по оракл что могут возникнуть уже отвечены где-либо, стоит лишь погуглить), а на стыке технологий, создании хорошей архитектуры в целом итд… и вот в этом плане sql.ru уже вопрос… формат не тот. Всё-таки это уже ближе к каким-то статьям-обсуждениям, не находишь?
external tables работают на механизме sqlldr. его вам уже предлагали. (вариант с exteranl tables на data pump не вспоминаю ибо вообще не в тему).
попробовать можете, конечно. Если добъетесь direct path write (снова уже обсуждали), то может и получите определённые преимущества… но есть и много недостатков.
1) вы говорили что вы планировали использовать одновременно несколько потоков для заливки. Это уже поставит под вопрос direct path write, и, в идеале, потребует некоторой переработки текущей архитектуры (на ваше усмотрение, конечно, но всё же).
2) sqlldr / ext table потребует предварительно выгрузить ваши данные в файл, а потом их загрузить — а это ещё один промежуточный буфер (причём на жёстком диске, а не в оперативке!!!), что явно не скажется положительно на производительности.
Подтверждаю. Та же ситуация. Но на первом курсе было немного стрёмно подписывать бумагу, где я соглашался отработать 3 года там куда пошлют на неизвестно каких условиях либо компенсировать цену моего обучения.
Ну, нас в КПИ так и заставили на первом курсе такую бумагу подписать. Со словами — не нравится — не подписывайте — на бюджет есть ещё много желающих. Правда по выходу никто никого не распределял, более того, для поддержания статистики обязали принести справку из какой-либо конторы, что она принимает тебя как молодого специалиста и собирается тебе платить ЗП согластно конторского штатного расписания. Посколько я уже имел работу в то время, то меня это не напрягло — директор прочитав внимательно бумажку проштамповал и сказал «наконец ты не будешь с работы в свой универ бегать»
Мне там некомфортно. Все какие-то аггресивные, по сути говорят мало, а хамства и высокомерия — много. Если бы при этом хотя бы подробно говорили что имеют в виду — ок, а так, как только задаёшь сложный вопрос — никого нету. А по простым «чего с глупостями своими вылез»… Так о чём говорить то?
1. Понял, спасибо. Согласен, можно и так. Правда я OR конструкции очень не люблю. Надо на план получившегося смотреть. Как бы не получилось что оракл это всё равно превратил в union all. Но с insert all тоже может иногда быть не сахар. Надо сравнивать.
2. ок, в любом случае пишите, уже любопытно понаблюдать до чего это всё докатится.
Привет. Вот и 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 */ мы тоже обсуждали, просто в других ветках — читай выше.
1. Хм, тогда не понимаю я, что вы имеете в виду под «select-ы сливаются в один», не используя insert all
4. На таком объёме это пока не так интересно, честно :) Самое забавное с Вашим потоком данных начнётся когда вы включите вашу машинку на полную мощность и погоняете хотя-бы 10-30 минут (а лучше 10 дней подряд). Надеюсь до того момента вам не надоест толпа комментирующих и вы поделитесь опытом. Поток то данных у вас достаточно любопытный, самом интересно было бы с таким «поигарться». У меня на опыте на порядок меньше в секунду. Правда и железо тогда было не в пример сегодняшнему…
В пару PCTUSED 99 тоже можно попробовать поставить (хотя, вероятно не изменит картины).
А какие параметры физического хранения были до этого? Если таблица была не большая, может там initial покрывал наличие датаблоков, и до рекурсивных call-ов на выделение новых датаблоков не доходило?
Спасибо за статистику.
пара комментариев.
1. Видимо вы не поняли преимущества insert all. Даже в одну таблицу имеет смысл чтобы не выполнять повторно select которым формируется dataset.
4. Сколько строк при этом было в целевой таблице (читаем в индексе) b-level у индекса какой был? Надеюсь эксперимент проводили не с пустой таблицей?
2) зачем dynamic sampling? Лучше соберите или постройте / импортируйте нормальную статистику по объектам.
3) Из «collection»:
> MERGE JOIN CARTESIAN
ойойой! не знаю что вы там делаете, но чуйкой чую что-то не то.
… Больше не копал, сорри. Но у меня усиленное чувство, смотря на PL/SQL код что там ещё очень много чего можно переписать сильно оптимальнее, убрав / переделав процесс. Но это будет больше логическая / архитектурная оптимизация, чем техническая. Но она, как раз, как правило даёт больше пользы :)
Очень удивило что bulk работает в вашем случае в два раза медленнее чем temporary. Интересно было бы покопать почему…
А в одноинстасевой системе, причём в примере — вставка в один поток, этот самый датаблок с большой вероятностью оказывается в database buffer cache, потому проблема не столь ярка (что не отменяет описанного обращения в seq$). Подтверждение чего мы и увидели на цифрах
Но, как-то, по большей части вопросы возникают не чисто по oracle (большинство вопросов по оракл что могут возникнуть уже отвечены где-либо, стоит лишь погуглить), а на стыке технологий, создании хорошей архитектуры в целом итд… и вот в этом плане sql.ru уже вопрос… формат не тот. Всё-таки это уже ближе к каким-то статьям-обсуждениям, не находишь?
попробовать можете, конечно. Если добъетесь direct path write (снова уже обсуждали), то может и получите определённые преимущества… но есть и много недостатков.
1) вы говорили что вы планировали использовать одновременно несколько потоков для заливки. Это уже поставит под вопрос direct path write, и, в идеале, потребует некоторой переработки текущей архитектуры (на ваше усмотрение, конечно, но всё же).
2) sqlldr / ext table потребует предварительно выгрузить ваши данные в файл, а потом их загрузить — а это ещё один промежуточный буфер (причём на жёстком диске, а не в оперативке!!!), что явно не скажется положительно на производительности.
Исходя из этих размышлений я против sqlldr.
habrahabr.ru/post/196828/#comment_6831790
2. ок, в любом случае пишите, уже любопытно понаблюдать до чего это всё докатится.
Нет, это другое. В этом месте я предлагал заменить два
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 */ мы тоже обсуждали, просто в других ветках — читай выше.
4. На таком объёме это пока не так интересно, честно :) Самое забавное с Вашим потоком данных начнётся когда вы включите вашу машинку на полную мощность и погоняете хотя-бы 10-30 минут (а лучше 10 дней подряд). Надеюсь до того момента вам не надоест толпа комментирующих и вы поделитесь опытом. Поток то данных у вас достаточно любопытный, самом интересно было бы с таким «поигарться». У меня на опыте на порядок меньше в секунду. Правда и железо тогда было не в пример сегодняшнему…
А какие параметры физического хранения были до этого? Если таблица была не большая, может там initial покрывал наличие датаблоков, и до рекурсивных call-ов на выделение новых датаблоков не доходило?
пара комментариев.
1. Видимо вы не поняли преимущества insert all. Даже в одну таблицу имеет смысл чтобы не выполнять повторно select которым формируется dataset.
4. Сколько строк при этом было в целевой таблице (читаем в индексе) b-level у индекса какой был? Надеюсь эксперимент проводили не с пустой таблицей?