Здравствуйте! Есть процедура, которая делает парсинг сложного XML-документа и использует многотабличную вставку с помощью INSERT ALL в одну главную и несколько подчиненных таблиц. В этой процедуре несколько подзапросов и условие, от которого зависит, будет запись вставляться в главную таблицу или одну из подчиненных. Есть общий сиквенс, который генерирует ID-шники для записей в этих таблицах. Использовать сиквенс в подзапросах запрещено, но если для него сделать функцию-обёртку, то это ограничение обходится. Но если провести тест производительности по методу Тома Кайта, с использованием пакета runstats, то выявляются не совсем желательные моменты. По сравнению с первым методом разбора, когда для парсинга главного элемента использовалась одна процедура, а для парсинга вложенных элементов из неё вызывались вложенные процедуры, возрастает время работы, количество защелок и другие параметры: file io wait time, cache table scan latch, session pga memory. Я могу предположить, что увеличение накладных расходов связано с тем, что из-за необходимости применять функцию-обертку возросло количество переключений контекста с SQL на PL/SQL и обратно.
На одном из блогов я встречал метод, где предполагалось предварительно генерить значения сиквенса в коллекцию. Но метод довольно недоработанный и оставляет множество вопросов, а автор давно уже забил на свой блог.
Вопрос в следующем: кто сталкивался с такой проблемой и как её решал?

Elic , время работы возрастает на 6%, количество защёлок на 30%. Мне поэтому и интересно, кто-то использовал сиквенс в обертке, а если использовал, то как-то кэшировал значения сиквенса?

-2- , в функции граблей никаких не закопано, она просто возвращает значение сиквенса. Предполагаю, что грабли - во множественном переключении контекста.

Я и этот вариант пробовал, напрямую nextval вызывал в секции VALUES. Но он странно себя ведет, для моих целей неприемлемо. Одно и то же значение сиквенса записывается в качестве ID и в главную, и в дочерние таблицы. В дочерних таблицах есть собственно ID документа и PARENT_ID, равный ID родительского документа. Этот способ иерархию документов нарушает. Так что надо какой-то вариант другой. Может, кто-то кэшировал значений сиквенса в коллекции?

Хоть и достаточно времени прошло, отпишусь) Все советы принял к сведению. Провел серию экспериментов. В том числе создавал для дочерних таблиц триггеры на вставку, но впоследствии отказался от этой идеи, т.к. логика работы размазывается по нескольким объектам БД. Сейчас пакет работает на продуктиве, есть уже заполненные таблицы, и поэтому переходить на использование для дочерних таблиц своих последовательностей конкретно в данном случае будет сложновато, т.к. дочерних таблиц много. Для каждого сиквенса нужно будет высчитывать стартовое значение, причем своё. Хотя в целом идея довольно неплоха и первоначально я так и хотел сделать - для таблиц первого уровня вложенности одна последовательность, для таблиц второго уровня - другая и т.д. Поэтому было решено обойтись малой кровью и применить тот совет, который предложил MazoHist , только в упрощенном виде. Точнее, воспользоваться свойствами самого сиквенса.