Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RMAN Questions: Channels and Restores

Re: RMAN Questions: Channels and Restores

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sat, 8 Nov 2003 05:24:51 +1100
Message-ID: <3fabe37c$0$3789$afc38c87@news.optusnet.com.au>

"Don Seiler" <don_at_seiler.us> wrote in message news:pan.2003.11.07.15.32.30.417995_at_seiler.us...
> I'm working with a test Oracle9i (HPUX) instance and working on practicing
> backups and recovery scenarios. Across reading the references docs on the
> Oracle site and some example RMAN scrips at dbaclick.com, I'm curious as
> to what extra benefit there is to be had in allocating multiple channels
> for a backup to disk, as opposed to just using RMAN's default single disk
> channel.

Because a database isn't comprised of just one file, but several. So if there are several channels (ie server processes) one can be grabbing blocks out of, say, files 1,3 and 5 whilst another is grabbing files 2, 4 and 6. Each channel runs independently of the other, so you've effectively got two half-backups running simultaneously, and therefore the backup time should be halved. Whether it is actually halved or not depends on the layout of your files on disk, and the kind of disk array you're asking RMAN to write to (not much point in trying to write two files simultaneously to the one single hard disk).

> Also just to clarify in my mind, multiple channels does NOT mean multiple
> copies of the backup, right?

Correct/ Multiple channels is simply a way of hiring more workers to do your work. Provided they don't end up treading on each others' toes, they should get the work done faster.

>The oracle doc said that "when backing up to
> disk you can allocate as many channels as necessary for maximum
> throughput." This sounds like allocating extra channels (up to a point)
> will decrease the backup time. Please correct me if I'm wrong.

Spot on, but with due caution given to the toe-treading issue (ie, backup to a 0+1 array and you'll benefit. Backup to the C: drive of your primary domain controller, or your busiest print server, and you won't).

OF course, RMAN *can* produce multiple copies of backups, and in that case, you've doubled (or trebled etc) your requested workload. Again, having more 'workers' can make that extra workload do-able, particularly within the same maintenance window you're permitted.

> Also a question about restores. I believe that I've seen this on another
> post but I want to be sure in black-and-white. If I want to take a backup
> of my production database and restore it on to a
> test/training/dev/whatever machine, I need to put those backup files in
> the same file path as they were made on the prod machine, and then RMAN
> will automagically know everything it needs to know?

Correct. There is a mechanism in 9i RMAN (called 'cross check') whereby RMAN can go out to sisk and make sure that what it thought it put there really is still there. But there is no mechanism to get it to search an entire hard disk to 'discover' the new location of backups you've moved or restored them to. Personally, that's a bit of a pet peeve of mine right now, and a significant lack of functionality (though it's not a show-stopper). Backups must be found by RMAN in the location to which they were originally written.

>Although I still
> have reading to do, I'll risk asking: How will RMAN know? Do I need to
> call RMAN with a param pointing to those backup files? If so, why would
> the files need to be in the same file path (not that it is a problem for
> me anyway)?

Everything RMAN does gets recorded in the control file of the target database: what was backed up, when and to where. If you have a catalog database, then that information is also stored there. So when RMAN is working out where it can restore stuff from, it consults that information. And it's for that reason you can't restore to somewhere else and expect RMAN to know about it: its records tell it one thing, and those records are not editable (note to myself: new project for the next wet Wednesday afternoon... see what happens when you issue DML to alter the contents of the RMAN repository database manually. Must remember to point out to all and sundry that such a move would be entirely unsupported, and is highly likely to break RMAN altogether. And that you can't do DML on the control file, so without a repository database, even that risky approach won't work.)

Regards
HJR Received on Fri Nov 07 2003 - 12:24:51 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US