Oracle-L: RE: rman question(allocating channels)

From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Date: Wed, 28 Aug 2002 09:23:27 -0800
Message-ID: <F001.004C1A3B.20020828092327@fatcity.com>

Joe -

Why do you feel writing RMAN backup to one disk is not ideal? Is it the one disk, or disk vs. tape?
I would watch the I/O while it is running to see how close you are coming to maxing out your I/O subsystem.
I suspect, but haven't investigated, that RMAN defaults are set a little low so that it doesn't tend to interfere with normal production. If this is true, you might either try increasing the RATE parameter, or allocating a second channel. Of course, if your Oracle is being used during the backup, increasing the I/O for RMAN may interfere with the users.
One issue is the read side of the RMAN backup process. The bottleneck may be in reading data blocks, no just writing them. In the worst case you have a single-disk Oracle system so RMAN is reading and writing to/from the same drive. Dennis Williams DBA Lifetouch, Inc. dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Wednesday, August 28, 2002 7:38 AM To: Multiple recipients of list ORACLE-L

I've tried to find this in the docs to no avail.

If I'm writing out an RMAN backup to one disk(yes this is not ideal), then does it make sense to allocate multiple channels?

Are multiple channels related to CPUs or to destinations?

thanks, joe

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Wed Aug 28 2002 - 12:23:27 CDT