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).