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

First of all, thanks to Hermant and Mladen for your assistance. This cloning process takes a few hours to run, so it is tedious to debug. I ran it again earlier today and discovered that is is performing about 1.5M blocks of parallel media recovery on UNDOTBS1 for hours after RMAN DUPLICATE has successfully completed. There are high PX Deq: Txn Recovery Start waits, and no apparent way to force single-threaded recovery which in my experience can be much faster.

I also noticed that undo_retention on the source is fairly high (54000). There may have been recovery running on UNDOTBS2 as well which prevented it from being dropped immediately after RMAN DUPLICATE had completed. A couple of hours later, UNDOTBS2 no longer had a partly available rollback segment and was dropped successfully, while at the same time recovery on UNDOTBS1 was still underway.

I still don't have a solution, but am beginning to get a better understanding of the problem.

Doug

> On January 9, 2019 at 12:54 AM Hemant K Chitale <hemantkchitale_at_gmail.com> wrote:
>
> 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 mailto: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