RMAN Parallelism
To backup the database with multithreads can considerably speed up the backup process as long as IO throughput is good enough to handle high volume read-write.
Although Oracle recommends that we enable asynchronous disk IO to backup the database, we can still use parallelism to simulate it and boost IO performance with synchronous IO.
In this post, I will talked about the following topics.
A. All-time Parallelism
If you want RMAN to backup parallelly without specifying how many channels it could use, you can configure the degree of parallelism in RMAN.
RMAN> configure device type disk parallelism 4;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
From now on, every time you backup by RMAN, you don't have to allocate any channels to do the job parallelly, because RMAN will spawn necessary channels for you.
B. Run-time Parallelism
If you'd like to control how many channels to backup the database parallelly, you can set it in the run-block.
1. Default Destination
Without specifying destination, backup pieces go to the configured destination, mostly, it's DB_RECOVERY_FILE_DEST (Fast Recovery Area, FRA).
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
backup database plus archivelog;
}
Further reading: How to Set USE_DB_RECOVERY_FILE_DEST.
2. Specific Destination
We can make all backup pieces go to the same specific destination as long as we format the filename in channels.
run {
allocate channel c1 type disk format '/backup1/ORCLCDB/%U';
allocate channel c2 type disk format '/backup1/ORCLCDB/%U';
allocate channel c3 type disk format '/backup1/ORCLCDB/%U';
allocate channel c4 type disk format '/backup1/ORCLCDB/%U';
backup database plus archivelog;
}
Channels are released automatically once the execution exits the run-block.
3. Multiple Destinations
We can also spread backup pieces across several destinations, this is especially useful when one disk space is not enough to accommodate all backup pieces.
run {
allocate channel c1 type disk format '/backup1/ORCLCDB/%U';
allocate channel c2 type disk format '/backup2/ORCLCDB/%U';
allocate channel c3 type disk format '/backup3/ORCLCDB/%U';
allocate channel c4 type disk format '/backup4/ORCLCDB/%U';
backup database plus archivelog;
}
As you can see, we spread the backup across 4 disks by channels. By the way, there're more about setting backup locations for different scenarios.
C. Degree of Parallelism (DOP)
Now comes the question, how many parallel channels should be allocated? I think we should seek for an answer from the database.
SQL> select a.value * b.value "Recommended Degree of Parallelism" from v$parameter a, v$parameter b where a.name = 'cpu_count' and b.name = 'parallel_threads_per_cpu';
Recommended Degree of Parallelism
---------------------------------
4
In fact, we derive the value of DOP from CPU_COUNT and PARALLEL_THREADS_PER_CPU by this:
You can use the value as a good starting point to tune DOP.
Next, for easing the burden of IO and space, you may consider to compress backup sets by RMAN.