Mark, I recently had a similar situation with a non-undo tablespace. I did not offline drop the datafiles first; I just did alter tablespace small_data offline temporary;, then dropped the tablespace including contents and datafiles. Of course, the fact that this is an undo tablespace may be complicating matters, but that approach was successful for me. -- Paul Baumgartel paul.baumgartel@xxxxxxxxxxxx On 10/26/05, Strickland, Mark <mark.strickland@xxxxxxxxxxxx> wrote: > > I've opened a TAR, but I wanted to also solicit ideas from the list. I > inherited a database that has an old undo tablespace "UNDO2" that had a > datafile that has needed recovery since August 9th. I don't have archived > logs going back that far. The tablespace isn't being used. A new undo > tablespace called "UNDO" was created sometime back and is being used. The > database has been shutdown and restarted successfully since the problem > started. Every night when the tablespaces are put in backup mode, errors are > thrown in the alert log for the undo2 tablespace because the file that > needs recovery is offline. The tablespace has offline undo segments. They > don't show a status of needing recovery. I researched it in Metalink and > believed that I could offline drop the datafiles in that old tablespace and > then drop the tablespace. I was able to execute the alter database offline > drop statements successfully, but when I tried to drop the tablespace, I got > an ORA-00600. Anybody got any ideas? > Mark Strickland > Seattle, WA >