question about RMAN

I have been reading and testing RMAN. I have question b/c I wasn't clear about channel and how RMAN is going to handle the backup. Any way, as I understand correct the reason you have multiple channel b/c you want to avoid i/o contention for large database. let say if you have:


run
{
allocate channel d1 type disk format 'c:\temp\%d_backup%u';
allocate channel d2 type disk format 'd:\temp\%d_backup%u';
backup database;
}


How does RMAN know to seperate the backup set to C or D??? I did a test and I only have the backup set on C drive and nothing on D drive.

could someone explain ???
thanks,

You are asking it to to write into two different locations with two different channels. Why are you asking that question again ?

Read completely and then try analyzing and ask questions if you have any.

Make sure you have the d:\directory or the path to this directory is correct.Bcos there's nothing wrong with your script.
remember to put your format paths in between quotes.

In my VERY limited experience it seems (at least under Windows) that a channel is allocated to a datafile and so you only get any benefit if you have several datafiles per tablespace - the tablespaces are placed in backup mode and processed one at a time. If you only have one file per TS then it always uses just the first channel, hence the C: drive.

Quote:

---

Originally posted by DaPi
In my VERY limited experience it seems (at least under Windows) that a channel is allocated to a datafile and so you only get any benefit if you have several datafiles per tablespace - the tablespaces are placed in backup mode and processed one at a time. If you only have one file per TS then it always uses just the first channel, hence the C: drive.

---

Not Exactly. RMAN will divide up the files that need to be backed up, splitting them between each channel. It doesn't really matter how many files per tablespace you have. I've had a database backed up with RMAN, and it had 50+ datafiles - some tablespaces had multiple files, some didn't. We would use two channels and it would "Randomly" pick half of the files for each channel. There must be some sort of algorithm, because both pieces tend to be about the same size.

Couple things to note... if you use multiple channels, you obviously get multiple backup pieces. Make sure to check your bandwith if your using multiple channels across the LAN. There is a point a diminishing returns. We found using 3 didn't get the backup done any faster than 2. We were using as much bandwith with 2 that we possibly could.

As far as Learning_bee's question.. I'm not sure why you only used one channel. How many files did you have?

According to the RMAN Guide:

Quote:

---

The default for filesperset is the lesser of these two values: 64, number of input files / number of channels. For example, if you back up 100 datafiles using 2 channels, RMAN sets filesperset to 50.

RMAN always attempts to create enough backup sets so that all allocated channels have work to do. An exception to the rule occurs when there are more channels than files to back up. For example, if RMAN backs up two datafiles when three channels are allocated and filesperset = 1, then one channel is necessarily idle.

---

HTH
Jodie

Quote:

---

Originally posted by DaPi
. . . - the tablespaces are placed in backup mode and processed one at a time.

---

Am I wrong about this? Will there be more than one TS in backup mode at any one time?

("Still learning" too - hope I never stop!)

Quote:

---

Originally posted by DaPi
Am I wrong about this? Will there be more than one TS in backup mode at any one time?

("Still learning" too - hope I never stop!)

---

Well, more than 1 tablespace will be backed up at one time. But the database isn't really in "backup" mode like when you'd do a manual backup and actually put the tablespace in backup mode. I'm embarassed to say that I don't know exactly how it DOES work. (It's kinda like MAGIC! :) )I'll have to go do some research. I can't believe that the db doesn't do checkpoints to the datafiles during a whole db backup like it does when you issue a "alter tablespace begin backup." I've had backups run for HOURS, so I can't believe this would happen...

I'll do some research and let you know what I find.

Hmmm... You got me thinking this morning!

Jodie

Quote:

---

Originally posted by jodie
It's kinda like MAGIC! :)

---

I'm glad of that - it all gets toooo technical at times :)

Thanks for your help Jodie.

Regarding tablespaces in BACKUP MODE, i agree with all you guys.
Oracle DOES NOT put tablespaces in BACKUP MODE when doing RMAN online backups. I guess you can check this selecting from dba_tablespaces while performing backups.
Hope your research can get this clear.
By the way, you can try RMV from www.otools.com.ar
there is a GUI reporting tool to obtain information related to your backups performed with catalog RMAN.
Regards..........

Quote:

---

I guess you can check this selecting from dba_tablespaces while performing backups.

---

How would this help? Status only has ONLINE, OFFLINE, READ_ONLY. The tablespaces don't go offline, or READ_ONLY when you do a backup.. either kind.

Now, v$backup will tell if a file is in active backup, but I'm not sure that really tells us what's happening either..

Found an answer:

From NOTE 76736.1 on Metalink:

Quote:

---

Q: Why do tablespaces not require hot backup mode or extra logging when using RMan for backups?

A: To understand why RMAN does not require extra logging or backup mode, you must first understand why those features are required for non-RMAN online backups.

A non-RMAN online backup consists of a non-Oracle tool, such as cp or dd, backing up a datafile at the same time that DBWR is updating the file. We can't prevent the tool from reading a particular block at the exact same time that DBWR is updating that block. When that happens, the non-Oracle tool might read a block in a half-updated state, so that the block which is copied to the backup media might only have been updated in its first half, while the second half contains older data. This is called a "fractured block". If this backup needs to be restored later, and that block needs to be recovered, recovery will fail because that block is not usable.

The 'alter tablespace begin backup' command is our solution for the fractured block problem. When a tablespace is in backup mode, and a change is made to a data block, instead of logging just the changed bytes to the redo log, we also log a copy of the entire block image before the change, so that we can reconstruct this block if media recovery finds that this block was fractured. That block image logging is what causes extra redo to be generated while files are in backup mode.

The reason that RMAN does not require extra logging is that it guarantees that it will never back up a fractured block. We can make that guarantee because we know the format of Oracle data blocks, and we verify that each block that we read is complete before we copy it to the backup. If we read a fractured block, we read the block again to obtain a complete block before backing it up. non-Oracle tools are not able to do the same thing because they do not know how to verify the contents of an Oracle data block.

Backup mode has another effect, which is to 'freeze' the checkpoint in the header of the file until the file is removed from backup mode. We do this because we cannot guarantee that the third-party backup tool will copy the file header prior to copying the data blocks. RMAN does not need to freeze the file header checkpoint because we know the order in which we will read the blocks, which enables us to capture a known good checkpoint for the file. ---

---

Hope that clears things up a bit!

Thanks for questioning this, Dapi. Sometimes I think we just accept things without knowing why. I feel more comfortable knowing the reason behind the "magic" now!

Good research Jodie - guess I owe you a beer.

- - - - - - - - -


Just realised, this means we haven't found an answer to learnin_bee's question.

Quote:

---

Originally posted by DaPi
Good research Jodie - guess I owe you a beer.

- - - - - - - - -


Just realised, this means we haven't found an answer to learnin_bee's question.

---

Great! I'll take you up on that beer if you're ever in Ohio, or I'm in Geneva!

Well, Learning_bee's script should be splitting the files between each drive since he's doing a database backup and will obviously have more than 1 file. Maybe the DB is so small that RMAN decides to skip the second channel.

Learning_Bee - Can you give us some specifics on your DB?

I have doubt in the following lines,plz clear it,

"When a tablespace is in backup mode, and a change is made to a data block, instead of logging just the changed bytes to the redo log, we also log a copy of the entire block image before the change, so that we can reconstruct this block if media recovery finds that this block was fractured. That block image logging is what causes extra redo to be generated while files are in backup mode."

I studied that if it's in backup mode,if any change is made in a block,the whole block will be written to the redo log,thats why more redo log generation.but here,they've given "entire block image before the change",.

1.I wants to know whether the changed block plus before image of that block are stored in redo log, or only changed block is stored.

2. If before image is stored,what is the use of this,how it helps in recovery process.

If anyone found,i've understood it wrong,please correct me.If possible,explain with a recovery scenario,so that i can understand this process very well.

plz someone help me in clearing this doubt.