Using Log Miner to find reason for extremely large archive logs.

Question

Hello everyone,
I have an Oracle 10g RAC database that sometimes generates extremely large number archive logs. The database is in ARCHIVELOG mode.
The usual volume of archive logs per day after compression is about 5GB, sometimes that spikes to 15GB and I cannot understand why.
I am looking at gathering statistics based on the inflated redo logs via LogMiner.
Looking at the structure of V$LOGMNR_CONTENTS - there are columns with promising names such as REDO_LENGTH, REDO_OFFSET, UNDO_LENGTH, UNDO_OFFSET.
However all these columns are deprecated. http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1154.htm
Is there a way of identifying operations that generate large redo logs?
The documentation for LogMiner has some example user sessions but none show how to generate statistics on the connection between redo logs and sql statements.
I see nothing that can help me in the following views:
V$LOGMNR_DICTIONARY, V$LOGMNR_DICTIONARY_LOAD, V$LOGMNR_LATCH,V$LOGMNR_LOGS, V$LOGMNR_PARAMETERS, V$LOGMNR_PROCESS, V$LOGMNR_SESSION
These views plus the following columns sound somewhat promising:
V$LOGMNR_CONTENTS -> RBABLK, RBABYTE, UBAFIL, UBABLK, UBAREC, UBASQN, ABS_FILE#, REL_FILE#, DATA_BLK#, DATA_OBJ#, DATA_OBJD#
V$LOGMNR_STATS -> NAME , VALUE
However I found nothing in the documentation on how to use them. (esp. not in Database reference, Database Utilities - the main documents I looked into). What should I read? Any strategies or ideas?
Kind regards:
al_shopov

Answer 1

To find sessions generating lots of redo, you can use either of the following
methods. Both methods examine the amount of undo generated. When a transaction
generates undo, it will automatically generate redo as well.
The methods are:
1) Query V$SESS_IO. This view contains the column BLOCK_CHANGES which indicates
how much blocks have been changed by the session. High values indicate a
session generating lots of redo.
The query you can use is:
SELECT s.sid, s.serial#, s.username, s.program,
i.block_changes
FROM v$session s, v$sess_io i
WHERE s.sid = i.sid
ORDER BY 5 desc, 1, 2, 3, 4;
Run the query multiple times and examine the delta between each occurrence
of BLOCK_CHANGES. Large deltas indicate high redo generation by the session.
2) Query V$TRANSACTION. This view contains information about the amount of
undo blocks and undo records accessed by the transaction (as found in the
USED_UBLK and USED_UREC columns).
The query you can use is:
SELECT s.sid, s.serial#, s.username, s.program,
t.used_ublk, t.used_urec
FROM v$session s, v$transaction t
WHERE s.taddr = t.addr
ORDER BY 5 desc, 6 desc, 1, 2, 3, 4;
Run the query multiple times and examine the delta between each occurrence
of USED_UBLK and USED_UREC. Large deltas indicate high redo generation by
the session.
hth
Kezie