Sure that is the way I would typically do it, but in this case I have an application that is running 8000 batch processes per day, redo is very consistent for most of the 24 hours. I asked myself what is the simplest way to figure out which objects likely generate all of this redo. Monitoring sesstat is not going to be the most efficient and accurate method in this case. As it turns out the results (based on the SQL I posted) show the F0911 (JDE Oneworld GL Ledger) table likely produces at least 70-80% of the redo. During the batch job tuning process I will focus on tuning jobs that effect this table. There are also a ridiculous # of indexes on this table, over 120 columns involved in all of the indexes, I am sure many are redundant. Since redo log contention is one of the primary issues with this database I should see some dramatic improvements once a few of the jobs are tuned.
- Ethan -----Original Message----- Sent: Friday, February 21, 2003 11:24 AM To: Multiple recipients of list ORACLE-L Hi, The simpler approach is to check the user level redo (or session level redo) using the v$sysstat,sesstat views and you can find the programmes associated with those huge (!) redo. Dumping the redologs and analyzing is just complex when you have a simple solution ;) ===== Have a nice day !! ------------------------------------------------------------ Best Regards, K Gopalakrishnan, Bangalore, INDIA. -- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Post, Ethan 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).
