09-28-2018 02:42 AM
Need help, can we run RMAN restore in multiple stream to make it faster.?
I have found one technote but not completely understood.
Solved! Go to Solution.
10-01-2018 03:11 AM
09-28-2018 03:37 AM
The restore method depends on how the backup was done.
The TN you found is related to Proxy (snapshot) backups.
Detailed info in NetBackup for Oracle Administrator's Guide
See if this post helps at all:
09-28-2018 05:43 AM
Thanks for the helpful information. so, we need to put media multiplexing to 1 in orcale policy so that each stream will go to diferent medias?
09-28-2018 05:55 AM
If you have multiple streams/channels writing to the same tape, then only one restore job can read from the tape.
09-28-2018 05:59 AM
I just found this TN:
How MPX_RESTORE_DELAY can be used to improve restore performance on a NetBackup Oracle Recovery Manager backup that was multiplexed
See if it helps?
09-30-2018 10:08 PM
I have gone through the TN but not cleared that how much value we can put in MPX_RESTORE_DELAY.
10-01-2018 12:59 AM
The value depends on what is happening in your environment and how rman restores are initiated by dba's.
What do you see in terms of Oracle restore jobs appearing in Job Monitor?
Is the default of 30 seconds enough?
How long can you afford for bprd to wait for multiple requests?
So, while 30 seconds is probably not enough, you may want to consider a delay between 2 and 5 minutes (120 and 300) - bearing in mind that jobs will only go active once no more requests from the client was received within the timeout period.
Let us look at an example of 120 (2 minutes):
First request is received from client. bprd waits for more requests.
1 minute later, another request is received. bprd adds this request to the queue.
90 seconds later, another request comes in and is added to the queue.
For the next 2 minutes, no more requests have been received.
bprd adds these 3 requests to the same restore operation.
So, 4.5 minutes went passed where nothing was activated.
30 seconds later, another request is received. This is now added to a new queue and the 2-minute count-down starts again for the new set of jobs.
The timeout countdown is restarted each time a new request is received.
While the default MPX_RESTORE_DELAY value of 30 sec is probably too small, a value of 300 (5 min) may be too big because of time that accumulates with each 'wait' between requests.
10-01-2018 02:17 AM
Hi Marianne, thanks for explaining in detail..
one doubt in your example you took 120 (2 mins)
So, bprd waits for all request until 2 mins over and then execute ?
Or once all requests came then bprd will not take any request for another 2 mins?
10-01-2018 03:11 AM
10-01-2018 03:22 AM
IMHO this discussion is becoming unnecessarily complex. In Oracle restore context, when you have for example 3 multiplexes on a tape, then you issue for restore:
allocate channel t1...;
allocate channel t2...;
allocate channel t3...;
Thus all individual streams are created by RMAN at almost the same point of time (there could be max tens of second), so there is no need to speculate about MPX_RESTORE_DELAY impact.
10-02-2018 12:22 PM
simple rule of thumb - you cannot use more streams to restore than used to back up.
If you need to restore using X drives, use X child jobs during the backups.
Lets make it more difficult - I duplicate to tape. If I restore using TAPE, I have contention issues because the duplications DO NOT put the images on tape exactly like they were created on my data domain. It happens ALL the time, that images end up on the same tape. I use six streams to restore, and I find I have almost always one tape waiting because the images are on a tape already in use.
So - I actually use X+1 streams to back up, because I assume I will restore using X+1 and 1 will be idle waiting for a tape.
All this is out the window if you are on disk with images, no tape contention. you are back to the initial scenerio
During backups, you also can use a value to set how many pieces per image - I use 1, but you can use more to increase backup speed. This will impact restores as well, since these groups are not sequential.