In this case, there was definitely a performance problem to be solved. I've been working through performance issues slowing and deliberately, but performance really bottomed out after a hardware upgrade. One report went from 4 minutes to 38 minutes and the nightly batch processes were taking 36% percent longer to complete. So we turned prefetch off on one production database and thus far results look good. The sys admins are reporting that the io load on the box looks dramatically better, user reports are running as they should and the nightly batch run met their completion deadline for the first time in at least a year. The immediate crisis is over, but the process continues ... Robyn On Fri, 27 Aug 2004 13:27:46 -0400, Mark W. Farnham <mwf@xxxxxxxx> wrote: > Read this carefully lest you think I'm disagreeing with Cary, when in fact > I'm agreeing but warning you to check which workload you need to optimize. > > If you're answering an expressed user need for something to be faster, > you'll know the answer to the question, but if you're just playing with the > carburetor to get a little more rubber to burn off the line, then, well, > your choice on this won't really matter. ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------