After seeing the original post and replies, I checked out the analyzer at oraperf.com, as I am having performance problems for the first time since becoming a DBA for our student information system. Over time, we've gone from 7.3.4 to 8.1.7.3 64-bit, from sequent to Sun Solaris, from 800-1200 users...underlying application changes (more database packages and procedures), and never really been tuned! I think our server upgrades have masked the database tuning issues, until we get a busy period, then it shows!
Anyway, the analyzer had some recommendations I put in place this weekend (my only opportunity to bounce the db) and I will be evaluating the impact these changes on performance next week...however, one recommendation that puzzles me is to make my redo logs 9765 MB! I have two groups of 20. Last weekend I doubled their size from 50 to 100 MB, but 9765 MB?! I am getting errors in the alert log that indicate slow archiving of redo logs, "Failed to archive..." but them a minute or so later it is archived. This change made no difference in the number of Failures reported. I am hoping the log_buffer change recommended by the oraperf analyzer will help, but can anyone comment on that redo log size recommendation? I ran a variety of statspack reports through and all said the same thing! Thanks, Debi > short answer: yes > > oraperf is written/run by Anjo Kolk, father of the tuning by wait event > methodology. I would tend to trust his suggestions for tuning > opportunities. Would I not also investigate on my own? No. I know my > apps, he doesn't unless he's come onsite. But oraperf can give me some > generic guidelines and places to start looking > > > --- Greg Moore <[EMAIL PROTECTED]> wrote: > > > the YAPP analyzer at www.oraperf.com anyways.. > > > > The last part of the oraperf report has suggestions for items to > > investigate > > and tune. Is oraperf really good at spotting the key tuning > > opportunities? > > > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > -- > > Author: Greg Moore > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > > San Diego, California -- Public Internet access / Mailing > > Lists > > -------------------------------------------------------------------- > > 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). > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Rachel Carmichael > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
