11g получить недопустимый неверный rowid через v$logminer_content

Я использовал logminer для получения данных об изменениях из archivelog, но получил неверный идентификатор строки 'AAAAAAAAAAAAAAAAAA'. Как это могло случиться. Это просто операция вставки.

  • скопировать каталог begin sys.dbms_logmnr_d.build(options => dbms_logmnr_d.STORE_IN_REDO_LOGS); end; /

  • добавить файл журнала begin sys.dbms_logmnr.add_logfile(LogFileName => '/arch/archlog/SZO1ABS9/ARC0000286133_0846017616.0001', Options => sys.dbms_logmnr.NEW); end; /

  • начать логмнр begin sys.dbms_logmnr.start_logmnr(Options => sys.dbms_logmnr.DICT_FROM_REDO_LOGS + sys.dbms_logmnr.COMMITTED_DATA_ONLY); end; /

  • получить результат select scn,start_scn,commit_scn,timestamp,operation,row_id,sql_redo,sql_undo from v$logmnr_contents where row_id = 'AAAAAAAAAAAAAAAAAA' and scn = '7590067871061';

0 ответов

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

Я не уверен, в чем основная причина, но я разработал два подхода, чтобы исправить это.

  1. На этапе постобработки я исправил эти идентификаторы строк, выполнив новый запрос, чтобы получить значение pkey таблицы через MINE_VALUE, затем вы можете использовать это для запроса таблицы через ее pkey для идентификатора строки.

  2. Если у вас включен ретроспективный режим, это исправление, по-видимому, уже сделано. Если вы посмотрите на ту же транзакцию в FLASHBACK_TRANSACTION_QUERY или запрос версий в таблице, вы увидите правильный ROWID, а не "AAAA..".

Другие вопросы по тегам