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@xxxxxxxxx>
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@xxxxxxx
mailto:dougk5@xxxxxxx ;> 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
>
