Hello,
We regularly run restores of Oracle databases which have been backed up
using Netbackup 3.4.1 and SQL-Backtrack.
The restores are always run on a media server.
The restores seem to have slowed down significantly over recent months.
When the environment was first setup, restores would take about 1.5 times
as long as the backup took. Now they take typically 4 times as long as the
backup took, or even up to 7 or 8 times.
I have noticed two things:
1. When restores are submitted to the queue, they may take several minutes
to become active, even though tape drives are available. During this time,
bprd processes on the master server go crazy, using up to 100% of a CPU.
There will be as many bprd requests active as there are restores in the
queue, all using over 95% CPU (the master has 6 CPUs). Eventually they
become active and the bprd processes on the master go away. Typically a
database restore might be restoring 150 images, so if each of these is
queued for one minute, that's a considerable delay. This delay for jobs
going from queued to active does not seem to occur for backups, only these
restores.
2. Once the restores eventually start, they regularly stall for varying
periods of time. While they are stalled, I see the following messages in
the bptm log on the media server....
process_brm_message: no pending messages from bpbrm
There is no tape activity happening at the time. The appropriate tapes are
loaded and ready, but there is no head movement occuring.
I can't see any processes using high CPU or doing a lot of IO on either the
master or media server while these messages occur.
This message appears every second, then a "CONTINUE RESTORE" message
appears and the restore starts moving again.
This pause might last a few seconds or a few minutes.
Here is an overview of the enviornment. Master and media servers are HPUX
11, Netbackup is 3.4.1, SQL-Backtrack is at the latest level (??), tape
hardware is Storagetek 9840 connected via SAN and shared with SSO. We write
3 streams per tape, and use 2 tape drives concurrently (6 streams total).
If anyone has any suggestions it would be greatly appreciated.
*********************************************************************************
Important Note
This email (including any attachments) contains information which is
confidential and may be subject to legal privilege. If you are not
the intended recipient you must not use, distribute or copy this
email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this
email are not necessarily the views of AXA. Thank you.
*********************************************************************************
|
