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