Re: After cloning RAC to non-RAC, ORA-1548 when attempting to drop UNDOTBS2

Possibly, at some time before the clone, instance 1 was using undo_tablespace='UNDOTBS2' so had a transaction in that Undo tablespace.

But the DUPLICATE would have done a clean OPEN so there should not be an active transaction. Do you see the transaction in V$TRANSACTION ?

Hemant K Chitale

On Wed, Jan 9, 2019 at 1:02 PM DOUG KUSHNER <dougk5_at_cox.net> wrote:

> Could use some guidance as this cloning issue has me baffled.
>
> After cloning an 11.2.0.4 2-node RAC to non-RAC database (ASM to ACFS)
> using RMAN DUPLICATE from backup, UNDOTBS2 cannot be dropped due to a
> rollback segment that is partly available. It is not possible to rollback,
> since the transaction is ACTIVE with DEAD flag. There are no partly
> available rollback segments in the source database, the cloning was
> performed with cluster_database=FALSE, undo_tablespace=UNDOTBS1 and
> recovery was successful on the clone, so unsure what went wrong. Several
> different RAC databases are being cloned using this process and only one of
> them consistently has this issue.
>
> This is primarily a nuisance, since the clone is just a staging database
> with a lifespan of a few weeks between refreshes. Despite not being able to
> drop the unneeded undo tablespace, can still disable thread 2 and drop the
> thread 2 redo logs.
>
> Looking for troubleshooting advice or ideas on how the cloning process
> could be corrupting this unused undo tablespace.
>
> Regards,
>
> Doug
>

--
http://www.freelists.org/webpage/oracle-l