SY,

Посмотрел на logminer.

Как им определить источник дополнительных размеров redo не нашел.

Количество DML в единицу времени можно и другим способом посмотреть.

И про поля BLOB logminer ничего не рассказывает.

flexgen,

авторникто не заметит если ты найдешь и решишь проблему. А вот если твое решение приведет к другим проблемам - вот тут сразу все увидят. Оно тебе надо?
Очень жизненно.

В топике нигде не сказано, что приложение стало работать хуже.
Времена отклика, пропускная способность ОК.

После перехода на 12.2 проблемы зафиксированы на БД:
в 3 раза выросло количество REDO, как следствие больше места и времени на синхронизацию с резервом

увеличилось количество parses, причем у запросов, у которых раньше не было parses и в основном к системным таблицам

увеличилось количество дочерних курсоров

От поддержки, пока, толку мало

Ниже текст ответа Оракла из SR:

OracleThis is expected as you are generating a higher amount of redo and block changes and as consequence the database slows down.
You have a lot of DML (insert, delete, update) and this generates a lot of redo.
You can see as well log file sync waits appearing and your number of log switches/hour raises to 23. log file sync slows down the database as well.
You need to find out what sessions are generating most of the redo and tune accordingly.
Please check the following note:
How to identify the causes of High Redo Generation ( Doc ID 2265722.1 )
Here you can find the session generating most of the redo:
SQL: How to Find Sessions Generating Lots of Redo or Archive logs ( Doc ID 167492.1 )

Те же DML, что генерили redo ДО перехода, продолжают генерить redo ПОСЛЕ.
Только суммарный размер redo увеличился примерно в З раза. См первое сообщение.