Long time ago I implemented those algorithms in queries ... (I believe there were at-least 2 different algos presented on this list) ... I have now moved to a simpler technique ... it may or may not work for you. Following assumptions are made 1. We analyze all tables everyday (it is just us okay ... so deal with it). 2. Use dbms_stats exclusively 3. We use LMT with autoallocate (ducking and running as fast as I can) Then it is easy ... every day I export the stats to a stats table with a statid of the format yyyymmdd. Then all it takes is a join with dba_segments to get tablespace information, and using analytics I can see a pattern of allocated blocks for tables and indexes. Based on the pattern, I extrapolate for next 30/60/90 days and request space. All our datafiles are and will be 4GB (don't know why) and yes, we are sushi people (like RAW spaces, not cooked). Although not accurate, it gives me a good idea on when I'd need more space for tablespaces. All it takes then is an email to unix group, and presto ... space is available in 24 hours. My take is not to wait 5 minutes before it fails by writing a finely tuned program ... I'd like to be warned at-least a week before. HTHS & YMMV Raj ===== Best Regards Raj --------------------------------------------------------- select mandatory_disclaimer from company_requirements; __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ---------------------------------------------------------------- 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 -----------------------------------------------------------------