What people have said so far about this is right. However, they miss some
fundamental points.
RMAN channels are used to back up Oracle datafiles. The backup is fully
controlled by RMAN; all NW does is to call RMAN to perform a backup. The
number of channels are set up in an RMAN script and NetWorker will multiplex
these to tape according to drive availability and the target sessions value.
Thankfully though, with NMO 4.2, an environment variable was introduced which
will force each channel to an individual NW device, overriding any other
considerations. This is good because, while you may not have your drives
streaming at maximum speed during backup, you will be able to perform
recoveries in a reasonable time.
The problem with multiplexing channels is that tape drives are sequential I/O
devices. Oracle will quite happily send stream after stream to the same tape.
When it's recovering though, it may take slightly longer to figure out that
it's done with a datafile and that it wants the next one. With 4 sessions
multiplexed to the same tape, what this results in is one session reading and 3
more waiting until that's done to be able to start their recoveries. With a
reasonable number of datafiles, this can occur many times during a recovery.
The worst one I've heard of so far was a database that took 3 hours to back up
and over 36 hours to recover, though I'm sure others on this list can come back
with more interesting numbers than that. There's also the question of
availability while you back up vs downtime when it's entirely down anyway.
While writing this, I've come up with a *possibility* that may help in this
instance anyway - 4 channels for multiplexed backup, 5 channels for recovery.
Should mean that, in theory, you'd have a channel already waiting for the point
on tape where the next datafile starts at all times. Anyone tried this?
So my answers:
1. Increasing the number of channels can be beneficial for improving drive
utilisation and reducing the backup window, but tests should be performed to
check recovery SLAs.
2. One database has multiple datafiles. If you have all night to do this,
probably best to use just one channel. If you have a short backup window or
it's a non-critical database, best to use multiple channels. If it's a
critical database, have 2 mirrors on disk, put Oracle into hot backup mode,
break the mirror (or take a snapshot), mount the mirror/snap elsewhere and back
up at one channel per tape drive from there.
3. Depends. Preferably for recovery purposes (with NMO 4.2), but not
necessarily.
Cheers,
Stuart.
________________________________
From: Legato NetWorker discussion on behalf of McKnight, Scott
(USPC.PRG.Atlanta)
Sent: Wed 23-Aug-06 05:09
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Questions on Oracle RMAN channels with NetWorker?
1) Increasing the number of channels causes additional streams of data.
Depending on how your network is configured, this can increase the
overall speed of the backup.
2) We currently back up single databases using 3 channels for larger
ones and 2 for smaller ones.
3) No, it will stream to the same tape but your overall throughput will
increase. For example, we tried using just one channel and got about
19MB/s throughput. When we increased to 3, we went up to about 35MB/s
to 40MB/s depending on overall network traffic, load on the box, and
etc.
4) Yes, that is exactly what it does.
R. Scott McKnight
-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of Bhaskar Mylavarapu
Sent: Tuesday, August 22, 2006 6:07 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Questions on Oracle RMAN channels with NetWorker?
Hi,
We're very confused here about this concept of "channels", as used in
Oracle RMAN scripts, and how this effects NetWorker, and we're hoping
someone can enlighten us. We have NetWorker 7.2.2 on a Solaris 9 server
with the NMO license installed. We're using Oracle 10g on the client
machine which is also running NetWorker 7.2.2 client and has the NMO 4.2
software installed. We're planning to test backing up a test database.
We've read through the Legato Admin. guide for NMO multiplatform
version, but we're unclear exactly how a channel effects the backups.
In other words, is a channel purely an Oracle thing, or does it also
influence how NetWorker will in turn behave? Is it similar to a save
stream or a session? I'm unclear if it makes sense to associate an
Oracle backup with a normal save set stream but just asking if there's
any correlation in the terminology. Let's say I set my RMAN script to
use two channels rather than one. Does this translate somehow to sending
2 streams to the NetWorker tape device on the other end? Or does it
still send a single save stream as far as NetWorker is concerned, but
the dual channels remains purely an Oracle thing?
1. Why would increasing the number of channels be beneficial and what
are the justifications for doing this?
2. If we're only backing up one database, does more than one channel
make sense?
3. If, for example, you set the RMAN script to use two channels, will
this require two tapes on the NetWorker end?
4. Does using multi-channels somehow split the Oracle backup into more
than one stream?
Would greatly appreciate any clarification on this.
Bhaskar
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--------------------------------------------------------
Princeton Retirement Group, Inc - Important Terms
This E-mail is not intended for distribution to, or use by, any person or
entity in any location where such distribution or use would be contrary to law
or regulation, or which would subject Princeton Retirement Group, Inc. or any
affiliate to any registration requirement within such location.
This E-mail may contain privileged or confidential information or may otherwise
be protected by work product immunity or other legal rules. No confidentiality
or privilege is waived or lost by any mistransmission. Access, copying or
re-use of information by non-intended or non-authorized recipients is
prohibited. If you are not an intended recipient of this E-mail, please notify
the sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute any portion of this E-mail.
The transmission and content of this E-mail cannot be guaranteed to be secure
or error-free. Therefore, we cannot represent that the information in this
E-mail is complete, accurate, uncorrupted, timely or free of viruses, and
Princeton Retirement Group, Inc. cannot accept any liability for E-mails that
have been altered in the course of delivery. Princeton Retirement Group, Inc.
reserves the right to monitor, review and retain all electronic communications,
including E-mail, traveling through its networks and systems (subject to and in
accordance with local laws). If any of your details are incorrect or if you no
longer wish to receive mailings such as this by E-mail please contact the
sender by reply E-mail.
--------------------------------------------------------
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
