Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Khalid.

Asked: May 31, 2007 - 2:16 pm UTC

Last updated: December 13, 2017 - 2:03 am UTC

Version: 10.2.0.2.0

Viewed 10K+ times! This question is

You Asked

Tom,
I am reading Oracle® Database Backup and Recovery Advanced User's Guide, 10g Release 2 (10.2), Part Number B14191-02, http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconfg003.htm#sthref521
The document says:
1) "As a rule, allocating one channel for each physical device is best. If you are backing up to only one disk location or only one tape drive, then you need only one channel."
2) It also states that, "Configuring parallelism for a device type specifies the number of server sessions".

Unfortunately all of my backups, I either back up to a single Tape drive via media manager, OR to a single filesystem at a time as in as in "CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u03/backups/rman/prd7/%d_%T_%U';". Therefore, if I go with what the doc. says, I have to limit my parallelism to 1, which is why I want to ask you this question.

Most of our databases are hosted on SMP with at least 4 CPU's and lots of horse power, and they are all scheduled nightly when nobody is around, but I cannot take advantage of creating several server sessions? because as I see it I am limited by 1) to go with parallelism=1.

I also noticed and have read that RMAN sometimes multiplexes blocks from different datafiles and creates a single piece out of them, is this why there is that limitation because it has to wait/synchronize for all server sessions to finish at the point that it writes to a backup piece? If so, then I don't mind if I am able to tell RMAN please create different backup pieces for different server sessions and as many as you want (Many pieces is fine, but we will provide you with only one filesystem or one tape-drive), it is perfectly OK with me, as long as I can parallelize the writes and make the backup operation faster. Therefore, is there something I can do to take advantage of this parallelism option?

Thanks,
Khalid




and Tom said...

backup bottlenecks are not around the CPU

they are about the ability to write to the backup device.

If you have one physical device to write to- such as a single tape device, all you would do is have everyone get in line to write. Parallel would not do anything (beyond add overhead).

However, with disk, it is likely that your single file system is really a big old striped file system over many devices and some degree of parallelism between 1 and 8 (2xcpu count) would make sense.

So, it comes down to this: if you hit your backup device with many processes all doing IO (writes) at the same time will it

a) serialize or worse (contention)
b) scale nicely

If B - go for parallel (benchmark it!)

I don't know what you mean by "multi-plexes" blocks, that didn't make sense.

Rating

  (7 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

On disk, I hope scales nicely

Khalid Rahim, May 31, 2007 - 5:08 pm UTC

a) I don't care so much about tape, because you have that problem of "waiting in line", we don't have much choice.
b) In case of disk, I would hope "scale nicely", because, I know our disk partitions are all SAN based, and a SAN partition could internally somehow map to many many physical disks. But benchmark like you always say, I plan to do that, and I will settle for the right number, even if that is "1".

What did I mean by "multi-plexes" blocks?,
Say I have 4 datafiles, does RMAN not read some blocks from datafile 1, some from 2, 3, and 4 and may write all of them to a single backup piece? if not, then I may have misunderstood this chapter, "Multiplexed Backup Sets" in chapter 2 of http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconfg003
htm#sthref521



Tom Kyte
June 01, 2007 - 8:25 am UTC

the word plex does not appear on that linked page.

http://docs.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconfg003.htm#sthref521

Multiplexed backup sets

A reader, June 01, 2007 - 8:48 am UTC

Sorry wrong link, but try this one,
http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1002.htm#sthref174

Otherwise, Database Backup and Recovery Advanced User's Guide, Chapter 2 has the topic "Multiplexed Backup Sets"



Tom Kyte
June 01, 2007 - 1:10 pm UTC

ok, so, now we are on the same page as they say - what is the question about this?

Bottleneck because of it

Khalid Rahim, June 01, 2007 - 2:59 pm UTC

You see my point? RMAN may be creating that bottleneck because it is writing to the same backup piece from different sources (datafiles). Instead if one backup piece contains data from exactly one datafile, then we can create n backup pieces in parallel for the n datafiles, taking advantage of features like disk write-caching etc. Even if one file-system partition maps to a slice on a single disk. (n procs in parallel creating n files, as opposed to n serial ops creating 1 file). Of course I'm theorizing all this.


Tom Kyte
June 03, 2007 - 4:55 pm UTC

don't use that feature than - but also remember - your datafiles are massively STRIPED.

so, even if each one reads from a separate file, they are all on the same devices anyway.

don't confuse "files" with "devices" - there are physical devices, you have a big bad SAN, your files are not on a device, they are on 10's or more of devices already.

Multisection backup

A reader, May 19, 2011 - 12:45 pm UTC

Tom,
I was reading about multisection backup of datafile which is new in 11g. Is there a corresponding multisection restore?

Thanks...

Tom Kyte
May 23, 2011 - 11:02 am UTC

http://docs.oracle.com/docs/cd/B28359_01/backup.111/b28270/wnbradv.htm

Multisection backups

RMAN can back up a single file in parallel by dividing the work among multiple channels. Each channel backs up one file section. You create a multisection backup by specifying SECTION SIZE on the BACKUP command. Restoring a multisection backup in parallel is automatic and requires no option.

A reader, May 24, 2011 - 8:34 am UTC

Thanks for pointing out the multisection restore. I was reading the RMAN documentation and completely missed out the new features guide.

In most RMAN documentation, it is said that the parallelism should be set equal to the number of tape devices. What happens if I specify parallelism which is higher than the number of tape devices?

My guess is that Oracle will allocate the channels based on parallelism since it has no way of knowing how many tape devices are actually attached. The extra channels will wait for their turn to write to the tape. Is this correct?

Thanks...

Tom Kyte
May 24, 2011 - 10:09 am UTC

What happens if I specify parallelism which is
higher than the number of tape devices?

it won't be able to do that, it won't really parallelize. tapes are sequential IO devices, they do not support seeking, two things cannot feed off of a single physical tape drive at the same time. One would have to wait for the other to finish


Parallelism

Gytis, August 31, 2011 - 1:10 am UTC

In that case, if lets say I have 17 tapes in one pool and machine with 4 CPU, its absolutely OK to make PARALLEL=8 or even 12?
Tom Kyte
August 31, 2011 - 9:08 am UTC

probably - since the tape device is so slow to write to - you probably will not overwhelm the cpu. That would be the gating factor - you don't want to go parallel so high that you are trying to use more than 100% of the cpu resources

RMAN Backup Parallel on RAC

Pablo Rubino, December 11, 2017 - 3:55 pm UTC

Hi, i've read the topic about parallelism on RMAN, so my quiestion is:
I have a RAC enviroment (LAB) with 2 nodes, so...i run a full compressed backup (the size of database is 500GB) with 4 channels (2 configured on every instances/node):
* CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
* CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'SYS/xxxxx@xxxx1'
* CONFIGURE CHANNEL 2 DEVICE TYPE DISK CONNECT 'SYS/xxxxx@xxxx1'
* CONFIGURE CHANNEL 3 DEVICE TYPE DISK CONNECT 'SYS/xxxxx@xxxx2'
* CONFIGURE CHANNEL 4 DEVICE TYPE DISK CONNECT 'SYS/xxxxx@xxxx2'
So, the process takes 13 hours to finish..(actually on Prod with 4 filesystems on disk for RMAN Parallel Backup takes 5 hours)
So the questions are:
1) Parallel on RAC run with parallel is related with nodes..(in my case 2 channels run on node 1 and another 2 channels run from node2)? is correct ??
2) The RMAN Backup is send to ASM Fast Recovery Area Disk Group (FRA), how manage ASM parallelism???

Now i'm running the same backup with 10 channels to lower backup times...is make any sense???
Connor McDonald
December 13, 2017 - 2:03 am UTC

Rather than try speed up a full backup, perhaps look at

a) block change tracking
b) recovery of image copies, ie, you can take an image copy and roll it forward to keep it (say) a couple days behind the true copy.

Then you never have to take a full backup again
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's latest video and Chris's latest video from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.

More to Explore

Backup/Recovery

Check out the complete guide to all of the Backup & Recovery techniques in the Oracle Database.