Ethan, > monitoring is active and my stats are up to date I should be able to > multiply the total number of updates, inserts and commits by > the average row > size and get a rough % of what objects are generating the most redo.
Note that the amount of redo does not depend on the average row size. It depends on the amount of _change_ (+ some overhead). This argument might skew the situation towards a table that has a large row size but that does not have that many updates... > I am sure there are a number of other factors I need to > consider, any ideas > what they are? > * Should I weight inserts, updates and deletes? > * ?? > > The goal is to identify the objects, then identify the jobs > that work on > those objects and see if I can reduce redo. I suspect a lot > of this redo is > being generated because of some poor design issues. What you _do_ need to do is to use this SQL to detect the SIDs performing redo: select sid, name, value from v$statname n, v$sesstat v where v.statistic# = n.statistic# and name like 'redo size' and value > 100000 order by value desc You can then look at V$OPEN_CURSORS for those SIDs... John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 I don't know what the future holds for me, but I do know who holds my future! ** The opinions and statements above are entirely my own and not those of my employer or clients ** -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).