Несогласованные результаты Oracle LogMiner

Question

Я работаю над решением на основе LogMiner для регистрации изменений, и я обнаружил то, что кажется либо необычным набором ожиданий при попытке добыть события повтора, относящиеся к операциям CLOB или BLOB.

В моем случае использования я вставил запись в таблицу, содержащую 3 поля CLOB, где одно из значений полей CLOB небольшое, а два других поля CLOB должны быть установлены с использованием операций LOB_WRITE.

Когда я устанавливаю начальный диапазон SCN LogMiner, который начинается до и заканчивается после фиксации транзакции, я получаю полные ожидаемые строки в V$LOGMNR_CONTENTS, которые:

      0a00070084220000 37717288 START
0a00070084220000 37717288 INSERT
0a00070084220000 37717312 SEL_LOB_LOCATOR
0a00070084220000 37717312 LOB_WRITE (several of these as expected)
0a00070084220000 37717331 SEL_LOB_LOCATOR
0a00070084220000 37717331 LOB_WRITE (several of these as expected)
0a00070084220000 37717332 INSERT (sets the smaller clob data values)
0a00070084220000 37717334 COMMIT

Необычный бит возникает при запуске сеанса майнинга с определенными диапазонами начала / конца SCN.

Например, когда я добываю с 37717239 по 37717289, я ожидал, что LogMiner предоставит в таблице как the, так и the; однако только START операция присутствовала.

Кроме того, когда я добывал с 37717290 до 37717340, я ожидал, что LogMiner предоставит все SEL_LOB_LOCATOR, LOB_WRITE, и последующие и; однако только последующие INSERT а также COMMIT были представлены.

Единственное, что я могу сделать из этого, это то, что LogMiner, похоже, испытывает проблемы, когда вы разделяете транзакцию, в которой определенные события повтора представляют различные синтетические операции, поскольку они относятся к LOB-операциям, и, следовательно, единственный способ, которым я действительно всегда мог реконструировать серию. of events было выполнено с 37717288 вперед, чтобы заставить LogMiner иметь доступ ко всей области транзакции, когда он материализует строки в представлении содержимого.

Почему LogMiner так себя ведет? Почему это не материализуется правильно при разделении транзакции на диапазоны SCN, которые я представил выше?

Answer 1

Для Logminer любая отдельная команда атомарна по определению. В этом случае он начинается с 37717288 и заканчивается на 37717332. Его нельзя разделить. Если вы спросите какой-либо диапазон, который его разделяет, Logminer не будет получать его специально (поэтому у вас не будет частичных результатов одной команды).

Это также верно для больших команд, отличных от больших объектов, таких как DDL, которые генерируют множество внутренних команд (например, изменить таблицу, изменить значение столбца по умолчанию)

Кроме того, обратите внимание, что получение значений LOB из Logminer ненадежно. просто поиграйте со значениями, и вы увидите, что они очень непоследовательны. (У меня есть где-то тесты, чтобы доказать это, поэтому, если вам интересно, я могу их предоставить)