Обновлена ​​база данных с 11.2.0.3.0 до 12.1.0.2.0. Медленный импорт журнала

Мы обновили нашу базу данных с 11.2.0.3.0 до 12.1.0.2.0 в PROD в выходные 18/19 июня 2016 г.

SELECT * FROM v$version;

Информация о версии:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
CORE    12.1.0.2.0    Production
TNS for Solaris: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production

Мы используем Oracle Release 12.1.3.

Мы также применили патчи процессора и др. (13942692, 18813637, 12404574, 15969020, 18835102, 21612876, 17889841, 12598630, 18991480, 22465286, 22614470, 16289505, 180396286, 22614470, 16289505, 180396286, 22614470, 16289505, 180396286, 22614470, 16289505, 18030396286.

Во время тестирования мы столкнулись с проблемой низкой производительности задания GLLEZL «Импорт журнала».

Мы обнаружили, что когда импорт журнала выполняется медленно (например, для журнала Web ADI из 19 000 строк задание «Web ADI — импорт журнала» занимает 2,5 часа по сравнению с парой минут в версии Database 11).

Для других работ, например. когда мы загружаем данные в GL_INTERFACE и запускаем стандартную «Программу - Импорт журнала», например. журнал на 120 000 строк, работа никогда не завершается.

Я поднял запрос на обслуживание, и мы получили быстрое решение, состоящее в том, чтобы отменить длительное задание, а затем выполнить эту команду:

exec fnd_stats.gather_table_stats('GL','GL_INTERFACE',100)  

Затем, когда мы повторно запускаем импорт журнала, он работает быстро.

Странно то, что мы можем запустить эту команду и повторно запустить Jnl Import, и проблема будет устранена для этого экземпляра.

В следующий раз, когда мы запустим большую работу, она снова застрянет.

Мы рассмотрели это примечание:

R12: Повышение производительности импорта главной книги и журнала (идентификатор документа 858725.1)

У нас также было другое исправление от Oracle, которое заключалось в следующем:

1. Отменить нежелательный индекс в сегменте 1 нашего бухгалтерского Flexfield

2. Запустите «Программа - Оптимизатор» с обоими параметрами, установленными на «Да».

3. Запустите «Сбор статистики схемы» для схемы GL с 25 в качестве расчетного значения в процентах.

Но это не решило проблему — нам все еще нужно каждый раз запускать исправление вручную.

Мы также теперь планируем «Программа — Оптимизатор» с обоими параметрами, установленными на «Да», на ежедневной основе, а полный сбор статистики схемы выполняется еженедельно в 25 для всех схем.

Oracle все еще пытается решить эту проблему, но я подумал, что спрошу здесь, если у кого-то еще были подобные проблемы.