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

There are recovery occasions when setting FAST_START_PARALLEL_ROLLBACK to FALSE shows faster Instance Recovery (SMON is doing the Instance Recovery)
*FAST_START_PARALLEL_ROLLBACK * is a supported instance level parameter.

Hemant K Chitale

On Thu, Jan 10, 2019 at 2:40 PM DOUG KUSHNER <dougk5_at_cox.net> wrote:

> 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> 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