Что то херня, что то херня если посмотреть как устроены matview логи в оракле, то там в snaptime$$ изначально ставится время, которое довольно далеко в будущем от текущего момента (4000 год чтоли), а никак не текущее время (тут с определением текущего времени не все гладко в плане того, что время вставки в лог - так себе якорь, и время фиксации изменений тоже так себе), а потом записи из лога либо удаляются (если один консюмер), либо snaptime$$ выставляется в дату запуска джоба (если несколько консюмеров), поэтому запрос типа "дай мне что добавилось с последнего запуска" работает более-менее вменяемо.

Если же смотреть на задачу в более общем виде, то идея типа "мы приложение менять не хотим, да и что-то забыть можем, поэтому давайте создадим лог на таблицы, который будем разбирать" - она откровенно так себе, потому что ну очень сильно попахивает ETL/ELT, что в абсолютном большинстве случаев получится какая-то неподдерживаемая хрень, почему так будет:
- если посмотреть на вакансии по ETL/ELT, то там можно невооруженным взглядом заметить, что у них у всех довольно общий паттерн: нужно знать какую-то более-менее распространенную систему, SQL и какие-то скриптовые ЯП начиная от петона и заканчивая шелом, т.е. в целом практика такая, что ETL/ELT обычно строят из говна и палок.
- в бизнес-приложении мы работаем с бизнес-сущностями, а не с таблицами, ровно также если говорить о messaging, то там тоже бизнес события ходят, а в решении "на тригерах" мы сначала бизнес-сущности превращаем в таблицы, а потом из таблицы пытаемся получить бизнес-событие, и при этом утверждаем, что так типа надежно, не нужно ломать текущее приложение и пр., на самом же деле получится так, что чтобы из лога сформировать бизнес-событие, придется в ETL/ELT-поделку воткнуть бизнес-логику, а потом еще придется за этой поделкой следить постоянно - а там вместо вменяемой доменной модели будет какой-то говнокод

Исходя из вышесказанного куда лучше немного разломать приложение на хибере чем прикручивать откровенные костыли.