Poor RMAN SBT Restore Performance: RMAN does not parallelize despite allocating >1 Channel
(Doc ID 433335.1)
Last updated on OCTOBER 31, 2016
Applies to:Oracle Database - Enterprise Edition - Version 10.1.0.2 to 10.2.0.4 [Release 10.1 to 10.2]
Information in this document applies to any platform.
***Checked for relevance on 16-Apr-2014***
RMAN 10gR2 restore and recover using TAPE incremental level 1 backups does NOT apply the
incrementals in parallel. Despite having allocated multiple channels RMAN only uses a single
channel for the restore hence the RECOVER phase takes much longer to complete. This is changed
behaviour from 9i where the restore always used all allocated channels .
This issue may occur during full database restore also.
RMAN debug trace shows that we:
a. validate each backuppiece to be restored in turn:
Media:0a01032f:42d58c3d:7290:0006[[M00306L3] E7-oracle8_188] attributes=0 msca=0 [14:22:12.813](val_pieces)
DBGPLSQL: channel TAPE_CHAN_1: validated handle:P30<P30_1252:621459123>.incr1
Media:0a01032f:42d58c3d:7290:0006[[M00306L3] E7-oracle8_188] attributes=0 msca=0 [14:22:12.847](val_pieces)
b. Then we generate one jobstep PER incremental backuppiece to be restored:
DBGPLSQL: 2 STEP id=2 status=NOT STARTED devtype=SBT_TAPE instid=1
DBGPLSQL: 3 STEP id=3 status=NOT STARTED devtype=DISK instid=1
DBGPLSQL: 4 STEP id=4 status=NOT STARTED devtype=SBT_TAPE bs.stamp=621459144 step_size=0 Bytes
DBGPLSQL: 5 STEP id=5 status=NOT STARTED devtype=SBT_TAPE bs.stamp=621459177 step_size=0 Bytes
DBGPLSQL: 12 STEP id=12 status=NOT STARTED devtype=SBT_TAPE bs.stamp=621459387 step_size=0 Bytes
c. But we are only able to run one step at a time:
run step 4, trying anyway (krmqgns)
DBGMISC: channel TAPE_CHAN_2 could not lock media [0a01032f:42d58c3d:7290:
0006[[M00306L3] E7-oracle8_188]] [14:22:12.912] (krmqgns)
Each channel in turn attempts to run steps 4-12 but fails with "could not lock media".
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.|