В общем на один Materialized View лог было несколько Materialized View, наверное некоторые из них были некорректно дропнуты, в общем не могу их найти, что бы обновить. Если они где то и существуют, то последний раз обновлялись три года назад, и, неважно если станут нерабочими. Как почистить от лишних записей распухший Materialized View лог с минимальными затратами нервов)?

aamazur,

Дело в том, что все МП которые видны выборкой

select * from DBA_SNAPSHOT_LOGS
where master like 'TB'

где 'TB' название таблицы, по которой создан лог - они все существуют, обновляются и имеют последние данные.

Тем не менее в самом логе MLOG$_TB несколько млн лишних записей, с датой SNAPTIME$$ много лет назад. Я б хотела остановить обновление существующих МП и одной командой почистить лог, не убивая его, потому что боюсь за существующие МП.

DBMS_MVIEW.PURGE_MVIEW_FROM_LOG предполагает знание SNAPSHOT_ID или имени МП. А я понятия не имею к какому МП эти записи.

В общем там 4 МП на один на разные сервера, все рабочие.
Обновляются все через короткие периоды - 5-10 мин, все обновления корректные.

А записи в самом логе за 4 года. Я вот думаю можно ли сделать хотя б что то типа
DELETE MLOG$_TB where SNAPTIME$$ <sysdate-100 ?
А потом MOVE MLOG$_TB ?

aamazur,
Время поджимало, пришлось дропнуть Mlog)
Но ради интереса, хронология была такова - в dba_registered_mviews обнаружилось materialized view явно по этой таблице, судя по названию, с MVIEW_SITE, который уже перестал существовать и CAN_USE_LOG - yes, MVIEW_ID=0
В общем я его разрегистрировала. Это наверное его записи. Того линка и МП давно нет.
DBMS_MVIEW.PURGE_MVIEW_FROM_LOG естественно применить не получилось, к чему? Попробовала поудалять руками но DML операции даже на небольших объемах тормозили работу, дропнула и все, хотя пришлось создавать заново МП, и были проблемы. А вы б что сделали если у вас так много записей в млоге осталось, что б сохранить МП? Теперь то я конечно буду за ними следить, но просто из интереса...