Jared, It sure is nice to be missed. I'll make sure my secretary calls you about my future vacation plans...:)
You've nailed the problem. Autoextend, automatic undo and high undo retention is a recipe for high disk usage. The aum algorithm is such that preference is given to extending over reuse (especially since expire time propogation is a problem). In order to find the length of the longest transaction, reference the v$undostat.maxquerylen value. Beware as there are known bugs with this view, so examine the output carefully to make sure it makes sense. Daniel Fink Jared Still wrote: > The data file(s) for your undo tablespace is likely set > as autoextend with an unlimited size. > > Run the attached script to check it. > > If so, you can use this to put a limit on it: > > alter database datafile '<your file name>' autoextend on next 200m > maxsize 2000m; > > Adjust the numbers for your system. > > You should probably investigate why it continues to grow so large. > > I haven't yet converted our production databases to UNDO, having > only recently migrated to 9i, so I don't have any useful advice > past this. > > There are others that will be able to offer more for this. ( Dan > Fink, where are you? This might even get Kirti to take a break > from his book for a few minutes ) > > HTH > > Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Daniel Fink 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).
