Tom Kyte at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4635285328580 brought to my attention that lack of some information (such as DML) LogMiner can get in 10g is related to in-memory undo. Indeed, my test confirms that this is due to 10g's IMU, which does not exist in 9i and works for small transactions in 10g. The following is a test on 9.2.0.8. SQL> create table testsuplm (x int); Table created. SQL> insert into testsuplm values (1); 1 row created. SQL> commit; Commit complete. SQL> select object_id from user_objects where object_name = 'TESTSUPLM'; OBJECT_ID ---------- 6132 I assume there's no logfile switch between the above SQLs and the following SQL: SQL> select member from v$logfile where group# = (select group# from v$log where status = 'CURRENT'); MEMBER -------------------------------------------------------------------------- /u02/oracle/oradata/testbtt/redo01.log I could add dictionary info here with: exec sys.dbms_logmnr_d.build(options=>sys.dbms_logmnr_d.store_in_redo_logs) or exec sys.dbms_logmnr_d.build('mydict.ora', '/tmp') then later exec sys.dbms_logmnr.start_logmnr(dictfilename=>'/tmp/mydict.ora') but for this quick and dirty test, ignore that. SQL> exec sys.dbms_logmnr.add_logfile('/u02/oracle/oradata/testbtt/redo01.log') PL/SQL procedure successfully completed. SQL> exec sys.dbms_logmnr.start_logmnr PL/SQL procedure successfully completed. SQL> select sql_redo from v$logmnr_contents where data_obj# = 6132; SQL_REDO ----------------------------------------------------------------------------------------------- create table testsuplm (x int); insert into "UNKNOWN"."OBJ# 6132"("COL 1") values (HEXTORAW('c102')); SQL> exec sys.dbms_logmnr.end_logmnr PL/SQL procedure successfully completed. Then I ran the above test in 10.2.0.1 and 10.2.0.4. The first time, the "insert" SQL did *not* appear in v$logmnr_contents. There're two ways to not use in-memory undo in 10g. To guarantee it's not used, I did: SQL> alter session set "_in_memory_undo" = false; Session altered. Then the test was tried again (make sure you use a different table or switch logfile to avoid interference from the previous SQLs). The "insert" SQL *was* shown. Supplemental logging, as homeworld80 said, also worked as expected (the command I used is "alter database add supplemental log data"). According to Note:428167.1, "turning supplemental logging on disables IMU", regardless the value of parameter _in_memory_undo. Interestingly, the second time I tested, still in 10.2.0.4, with a new table, the "insert" SQL did appear. Absolutely nothing was changed. I assume the in-memory undo was flushed by Oracle. This flushing cannot be controlled with any command. (See also ./IMU.txt) I have not tested a large transaction, which supposedly will disable in-memory undo; after all, IMU is only for small undo so it can be kept in memory. I don't know how big is big. By the way, even if the transaction is small and no supplemental logging is enabled, recursive DML SQLs appear in v$logmnr_contents, probably because _recursive_imu_transactions is false. In 11gR2, but not 11gR1, the above test shows the "insert" SQL in v$logmnr_contents even if supplemental logging is not enabled (and _in_memory_undo is true, which is default).