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_at_aya.yale.edu
On 10/26/05, Strickland, Mark <mark.strickland_at_cingular.com> 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
>
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 26 2005 - 17:29:13 CDT
