I did some testing on this a year or so ago... If it were a simple range partitioned table, you should be able to drop the individual partitions that reside in these tablespaces and then drop the tablespace... I'm not sure if you can do this with the subpartitioned table... The method Jonathan describes should also work but takes a little longer... As a matter of fact, it is the ONLY way I have found to cleanup a partitioned IOT residing in a corrupt tablespace... Tim Jonathan Lewis wrote: >I haven't tested this idea, but it might work. > > Identify the partitions that are in the lost datafiles. > > Create empty tables of the same structure in > some on-line files. > > For each problem partition, exchange the partition > with one of the new tables. > >The lost datafiles now contain nothing but simple tables >so you should be able to drop the tablespace. > >I know I did something like this once when I was testing >disaster recovery scenarios with partitioned tables in 8.1.6, >and I was a little surprised (and relieved) at the way I could >change data dictionary definitions even when the objects >referenced were in destroyed data files. > > ---------------------------------------------------------------- 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 -----------------------------------------------------------------