LogMiner Redo SQL w/o WHERE-clause

[Chris Cranford]

We recently received a report about a redo SQL statement mined via
LogMiner that had no where clause, i.e.:

     update "SCHEMA"."TABLE" set "COLA" = 'VAL1', "COLB" = 'VAL2';

Initially, my theory was a bulk update on a large number of rows might
have been why.  The table in question here has over 96 million rows. 
I've tested with a bulk update of a 1 million row data-set and I observe
a LogMiner DML entry for each of the 1 million rows modified, so I'm now
not entirely sure bulk operations are the root-cause.  Milo / Andrey or
anyone else with more awareness of the intricate nuances of LogMiner
than I, can you think of any reason why we would see a LogMiner redo SQL
generated like this?

Thanks!
Chris

[Milo van der Zee]

Hello Chris,

I have seen that as well and what I think is happening is that the log file disappeared under the miner. I used to see this frequently but now I have the archives available for a much longer period the problem has gone.

What I still see is DELETE statements deleting rows based on ROWIDs. My assumption is that those are just internal deletes and actually also show up as normal deletes. I was not able to reproduce the behaviour.

MAG,

Milo

Op do 4 mrt. 2021 om 20:10 schreef Chris Cranford <cran...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/debezium/626ce23e-c266-f5bd-e859-b7fbfbcbe11b%40gmail.com.

[Chris Cranford]

Hi Milo -

Thanks for getting back to me so quickly! 

That's actually interesting that LogMiner would do that.  So if a redo log transitions to an archive log mid mining, could this also occur in your opinion?  I'm wondering then if we shouldn't consider situations where an UPDATE has no WHERE-clause to force the current mining session to halt & to re-evaluate logs & restart.  With your DELETE scenario, I haven't seen that as of yet myself but I thought INTERNAL operations are already flagged differently in the LogMiner contents view from non-INTERNAL operations, correct?

Thanks,
Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/debezium/CAO5pNXLvrk-%3DsfdGXs-%3DQrSoS8tiwihRC8DjV36X0-8TMyT3rg%40mail.gmail.com.

[Milo van der Zee]

Hello Chris,

Might indeed be a good indication that the log file is gone or transitioned. But I'm not sure this is the cause. Just what I derived from my log files. This scenario is quite easy to test.

I do actually always check if the WHERE statement is complete and show a warning if not.

Maybe my SELECT on the log is not correct and I need to filter out some kind of internal messages. I'll check that.

MAG,

Milo

Op do 4 mrt. 2021 om 21:37 schreef Chris Cranford <cran...@gmail.com>:

[Ignatenko, Andrey]

this happens when supplemental log was not set

To view this discussion on the web visit https://groups.google.com/d/msgid/debezium/CAO5pNX%2BdnHjcK1h8LY7DXprBSranE5JHLsegA1eQTuGzUg8YvA%40mail.gmail.com.

--

Andrey Ignatenko
Staff Engineer
tel: +15102675105 /// mobile: /// email: andrey.i...@navis.com
Navis LLC /// 55 Harrison Street, Suite 600 Oakland CA 94607 UNITED STATES
www.navis.com




CONFIDENTIAL – Information in this email, including any attachments, is confidential, may be legally privileged and may contain proprietary information. If you are not the intended recipient, please immediately notify the sender by reply email and then delete this email message and any attachments. You should not copy, use or disclose to any other person this message or any attachments. Thank you.

[Ignatenko, Andrey]

I've seen this when no supplemental logging was set

To view this discussion on the web visit https://groups.google.com/d/msgid/debezium/01c282e1-eecc-0d25-0a8f-85bf8df2cc29%40gmail.com.