Thanks for the detailed info. I had thought that the multiplexing of Oracle
backups with other systems backups would improve backup throughput and not
*too* badly affect the Oracle restore. However I hadn't really thought of
the Oracle backup streams themselves being multiplexed onto the same tape,
which I can see would severely hamper restore.
regards, Phil
-----Original Message-----
From: Joost Mulders [mailto:mail AT j-mulders.demon DOT nl]
Sent: 28 March 2004 23:15
To: veritas-bu AT mailman.eng.auburn DOT edu; Philip.Weber AT egg DOT com
Subject: Re: [Veritas-bu] Oracle RMAN Backup Multiplexing at 4.5
Hi Phil,
Multiplexing Oracle backups does not improve backup performance and *can*
multiply restore time, so I wouldn't use it.
RMAN assumes that the output of a channel (a backup set) is stored on
different
media and it will backup and restore those backup sets in parallel. What
happens
if the backup sets are multiplexed on a single tape is best explained by an
example:
1. RMAN requests the data for channel 1 to the media manager and waits for
the
data to come in
2. NBU locates and mounts the tape. It finds the tape has multiplexed
backups
and waits MPX_RESTORE_DELAY seconds (default 30) for other restore
requests
coming out of the same read pass. This timer expires and NBU starts
sending
data.
3. RMAN receives the data for channel 1 and requests the data for channel
2.
4. NBU finds that the tape is busy and queues the request until channel 1
is finished.
So, MPX'ing 2 channels/sets on 1 tape doubles restore time. The scenario
above
is the sole reason why people have ridiculous long CLIENT_READ_TIMEOUT
settings
(like a hour or so) with Oracle: channel 2 must wait until 1 is finished.
To configure Oracle backups I use the following scenario:
1. Allocate as much channels as the bottleneck in the datapath from db
server
to tape can utilize:
100Mbit ethernet + DLT8000 w. compression: 1 channel
Gbit ethernet + DLT8000 w. compression: 4 channels
1Gbit SAN + w. LTO2 w. compression: 2 channels
etc. etc.
2. If necessary tune Oracle to deliver sufficient data for all channels.
I almost always see improvement with
set limit channel c1 maxopenfiles 1;
in the RMAN commandfile. For composing a backup set, RMAN does a
multiplexed read from up to (default) 16 datafiles in the hope that
these
datafiles are on different disks. If datafiles are on the same disk this
multiplexing just generates a lot of head movements. If the datafiles
are
on some form of RAID storage, the multiplexing thrashes cache and
disable
readahead algorithms.
Sorry for the long post ;-)
Best regards, Joost
>NBU 4.5 FP 4, Solaris 2.6 Master, Media & Clients. StorageTek L700 with
>DLT7000.
>
>Do people tend to multiplex Oracle RMAN backups? I'm on a drive to improve
>throughput of our solution, looking into tuning the buffers mainly, but I
>notice we aren't multiplexing Oracle backups whereas everything else is at
4
>MPX. I assume if multiplexed, restore performance will suffer, but to what
>degree? I have heard some scare stories here as explanations for why we
>aren't multiplexing (1.5 hour backup taking "all day" to restore) but
>suspect something else was causing them.
>
>Any feedback would be appreciated.
>
>thanks, Phil
>
>Phil Weber
>Egg Distributed Hosts - UNIX Systems Engineer
>Phone: 01384 26 4136
>Mobile:
>
>
>This private and confidential e-mail has been sent to you by Egg.
>The Egg group of companies includes Egg Banking plc
>(registered no. 2999842), Egg Financial Products Ltd (registered
>no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
>is authorised and regulated by the Financial Services Authority. Egg
>Investments Ltd. is entered in the FSA register under number 190518.
>
>Registered in England and Wales. Registered offices: 1 Waterhouse
>Square, 138-142 Holborn, London EC1N 2NA.
>
>If you are not the intended recipient of this e-mail and have received
>it in error, please notify the sender by replying with 'received in
>error' as the subject and then delete it from your mailbox.
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--
Long may you run.
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
is authorised and regulated by the Financial Services Authority. Egg
Investments Ltd. is entered in the FSA register under number 190518.
Registered in England and Wales. Registered offices: 1 Waterhouse
Square, 138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have received
it in error, please notify the sender by replying with 'received in
error' as the subject and then delete it from your mailbox.
|
