Introduction
Last
week, one of my clients experienced an issue with Oracle LogMiner after a table
structure change. The generated SQL appeared to be incorrectly reconstructed,
raising concerns about possible corruption in the LogMiner output.
Before
looking at the incident, it is useful to briefly understand what Oracle
LogMiner does. LogMiner is an Oracle database utility that allows DBAs and
applications to analyze redo and archived redo logs and reconstruct the
database changes recorded in them. It is commonly used for troubleshooting,
auditing, data recovery, and CDC (Change Data Capture) solutions.
In
this case, the affected CDC environment was using LogMiner to capture changes
from the database. The problem appeared after a deployment modified the
following table:
USER.TRANSACTIONThe
table changed from 21 columns to 32 columns, with 11 new columns added.
The
first important clue came from the Oracle alert log, which showed a significant
increase in parsing errors around the same time:
The table's LAST_DDL_TIME was also:
These timestamps helped connect the application problem with the table structure change.
The investigation then focused on how LogMiner was obtaining its dictionary information and how it handled redo generated before and after the structural change. This ultimately led us to the root cause and the appropriate solution.
