This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C41577.81D1AC30
Content-Type: text/plain;
charset="iso-8859-1"
I disagree. We multiplex x3 to LTO-II FC drives [using three RMAN channels
per job] in a FC L180. Using multiplexing we can push the drives to around
70-80Mb Per sec. Without the MPX they idle along at 25MB per sec.
We have seen no degredation in restore times using three restore
streams.....
-----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.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
------_=_NextPart_001_01C41577.81D1AC30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [Veritas-bu] Oracle RMAN Backup Multiplexing at 4.5</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I disagree. We multiplex x3 to LTO-II FC drives =
[using three RMAN channels per job] in a FC L180. Using multiplexing we =
can push the drives to around 70-80Mb Per sec. Without the MPX they =
idle along at 25MB per sec.</FONT></P>
<P><FONT SIZE=3D2>We have seen no degredation in restore times using =
three restore streams.....</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Joost Mulders [<A =
HREF=3D"mailto:mail AT j-mulders.demon DOT nl">mailto:mail AT j-mulders.demon
DOT nl</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 28 March 2004 23:15</FONT>
<BR><FONT SIZE=3D2>To: veritas-bu AT mailman.eng.auburn DOT edu; =
Philip.Weber AT egg DOT com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Veritas-bu] Oracle RMAN Backup =
Multiplexing at 4.5</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Hi Phil, </FONT>
</P>
<P><FONT SIZE=3D2>Multiplexing Oracle backups does not improve backup =
performance and *can* </FONT>
<BR><FONT SIZE=3D2>multiply restore time, so I wouldn't use it.</FONT>
</P>
<P><FONT SIZE=3D2>RMAN assumes that the output of a channel (a backup =
set) is stored on different </FONT>
<BR><FONT SIZE=3D2>media and it will backup and restore those backup =
sets in parallel. What happens </FONT>
<BR><FONT SIZE=3D2>if the backup sets are multiplexed on a single tape =
is best explained by an </FONT>
<BR><FONT SIZE=3D2>example:</FONT>
</P>
<P><FONT SIZE=3D2> 1. RMAN requests the data for channel 1 to the =
media manager and waits for the </FONT>
<BR><FONT SIZE=3D2> data to come in</FONT>
<BR><FONT SIZE=3D2> 2. NBU locates and mounts the tape. It finds =
the tape has multiplexed backups</FONT>
<BR><FONT SIZE=3D2> and waits MPX_RESTORE_DELAY =
seconds (default 30) for other restore requests</FONT>
<BR><FONT SIZE=3D2> coming out of the same read pass. =
This timer expires and NBU starts sending </FONT>
<BR><FONT SIZE=3D2> data.</FONT>
<BR><FONT SIZE=3D2> 3. RMAN receives the data for channel 1 and =
requests the data for channel 2.</FONT>
<BR><FONT SIZE=3D2> 4. NBU finds that the tape is busy and queues =
the request until channel 1 </FONT>
<BR><FONT SIZE=3D2> is finished.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>So, MPX'ing 2 channels/sets on 1 tape doubles =
restore time. The scenario above </FONT>
<BR><FONT SIZE=3D2>is the sole reason why people have ridiculous long =
CLIENT_READ_TIMEOUT settings </FONT>
<BR><FONT SIZE=3D2>(like a hour or so) with Oracle: channel 2 must wait =
until 1 is finished.</FONT>
</P>
<P><FONT SIZE=3D2>To configure Oracle backups I use the following =
scenario:</FONT>
<BR><FONT SIZE=3D2> 1. Allocate as much channels as the bottleneck =
in the datapath from db server</FONT>
<BR><FONT SIZE=3D2> to tape can utilize:</FONT>
<BR><FONT SIZE=3D2> 100Mbit ethernet + DLT8000 w. =
compression: 1 channel</FONT>
<BR><FONT SIZE=3D2> Gbit ethernet + DLT8000 w. =
compression: 4 channels</FONT>
<BR><FONT SIZE=3D2> 1Gbit SAN + w. LTO2 w. =
compression: 2 channels</FONT>
<BR><FONT SIZE=3D2> etc. etc.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> 2. If necessary tune Oracle to deliver =
sufficient data for all channels.</FONT>
<BR><FONT SIZE=3D2> I almost always see improvement =
with</FONT>
<BR><FONT SIZE=3D2> set limit channel c1 =
maxopenfiles 1;</FONT>
<BR><FONT SIZE=3D2> in the RMAN commandfile. For =
composing a backup set, RMAN does a</FONT>
<BR><FONT SIZE=3D2> multiplexed read from up to =
(default) 16 datafiles in the hope that these </FONT>
<BR><FONT SIZE=3D2> datafiles are on different disks. =
If datafiles are on the same disk this </FONT>
<BR><FONT SIZE=3D2> multiplexing just generates a lot =
of head movements. If the datafiles are </FONT>
<BR><FONT SIZE=3D2> on some form of RAID storage, the =
multiplexing thrashes cache and disable</FONT>
<BR><FONT SIZE=3D2> readahead algorithms. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Sorry for the long post ;-)</FONT>
</P>
<P><FONT SIZE=3D2>Best regards, Joost</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>>NBU 4.5 FP 4, Solaris 2.6 Master, Media & =
Clients. StorageTek L700 with</FONT>
<BR><FONT SIZE=3D2>>DLT7000.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>Do people tend to multiplex Oracle RMAN =
backups? I'm on a drive to improve</FONT>
<BR><FONT SIZE=3D2>>throughput of our solution, looking into tuning =
the buffers mainly, but I</FONT>
<BR><FONT SIZE=3D2>>notice we aren't multiplexing Oracle backups =
whereas everything else is at 4</FONT>
<BR><FONT SIZE=3D2>>MPX. I assume if multiplexed, restore =
performance will suffer, but to what</FONT>
<BR><FONT SIZE=3D2>>degree? I have heard some scare stories =
here as explanations for why we</FONT>
<BR><FONT SIZE=3D2>>aren't multiplexing (1.5 hour backup taking =
"all day" to restore) but</FONT>
<BR><FONT SIZE=3D2>>suspect something else was causing them.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>Any feedback would be appreciated.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>thanks, Phil</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>Phil Weber</FONT>
<BR><FONT SIZE=3D2>>Egg Distributed Hosts - UNIX Systems =
Engineer</FONT>
<BR><FONT SIZE=3D2>>Phone: 01384 26 4136</FONT>
<BR><FONT SIZE=3D2>>Mobile: </FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>This private and confidential e-mail has been =
sent to you by Egg.</FONT>
<BR><FONT SIZE=3D2>>The Egg group of companies includes Egg Banking =
plc</FONT>
<BR><FONT SIZE=3D2>>(registered no. 2999842), Egg Financial Products =
Ltd (registered</FONT>
<BR><FONT SIZE=3D2>>no. 3319027) and Egg Investments Ltd (registered =
no. 3403963) which</FONT>
<BR><FONT SIZE=3D2>>is authorised and regulated by the Financial =
Services Authority. Egg</FONT>
<BR><FONT SIZE=3D2>>Investments Ltd. is entered in the FSA register =
under number 190518. </FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>Registered in England and Wales. Registered =
offices: 1 Waterhouse</FONT>
<BR><FONT SIZE=3D2>>Square, 138-142 Holborn, London EC1N 2NA.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>>If you are not the intended recipient of this =
e-mail and have received</FONT>
<BR><FONT SIZE=3D2>>it in error, please notify the sender by =
replying with 'received in</FONT>
<BR><FONT SIZE=3D2>>error' as the subject and then delete it from =
your mailbox.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT =
SIZE=3D2>>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>>Veritas-bu maillist - =
Veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>><A =
HREF=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu"; =
TARGET=3D"_blank">http://mailman.eng.auburn.edu/mailman/listinfo/veritas=
-bu</A></FONT>
</P>
<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Long may you run.</FONT>
</P>
<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Veritas-bu maillist - =
Veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu"; =
TARGET=3D"_blank">http://mailman.eng.auburn.edu/mailman/listinfo/veritas=
-bu</A></FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C41577.81D1AC30--
|
