Комрады,

Есть RAC 12.1.0.2, в теории все изменения осуществляются на экземпляре 1 (inst_id=1), на экземпляре 2 работают только отчеты и изменений данных на нем (inst_id=2) не производится (кроме записи в GTT). Однако, периодически, inst1 запрашивает блоки данных из inst2 (CacheFusion).
На inst2, v$segstat и AWR отчеты свидетельствуют об сегментах с write IO operations на таблицах и индексах.

Внимание вопрос :)
Как отследить какой именно процесс изменяет данные на inst2?

Это точно не пользовательский DML. Похоже на что-то системное.

tru55,
Буду пробовать LogMiner, но давно его не юзал, нужно освежить.

2 andrey_anonymous
Из системных задач только сбор статистики включен, он работает ночью и не должен изменять пользовательские данные.
Да, основное подозрение delayed block cleanout.
Еще странный модуль работает KTSJ, вроде segment maintanence, инфы по нему не много.

2 SY откуда ты так уверен?
Конечно за все сто не уверен, но не должны. Мониторю ASH, ничего подозрительного не вижу.
Они подключаются по сервису который работает только на второй ноде. Параллельность мы не используем и я ее не вижу в ASH.
И да отчеты должны работать на standby, но из-за бага связанного с индексами в GTT, пока использовать standby не можем.

Вообще я не уверен как работает delayed block cleanout если изменения были сделаны на иснт1 а читает данные инст2. Кто будет делать очистку? И будет ли remastering блока.

Logminer ничего не нашел за последние пол часа, искал по table_name, data_obj#, sql_redo, sql_undo.
Тот же период AWR, segments by db block changes and segments by physical writes, показывает изменения в сегментах индексов и таблиц.
Вот думаю покажет ли logminer delayed block cleanout, поидее если блок изменился, то он должен попасть в redo.