Optimization and tuning of backup


Before understanding backup optimization, you should first know the principle of RMAN backup:

When RMAN initiates a backup task, it will open the corresponding channels. Each channel has a corresponding service process in the database server. RMAN will call the DBMS first_ Rcvman package reads the control file and determines the storage location of the data file. After obtaining this information, rman will call the DBMS_ BACKUP_ The restore package reads and backs up data files. The reading process is to compile the list of files to be backed up based on the algorithm rules of RMAN backup. When RMAN performs a backup operation, it will request the Oracle shared memory segment to create its own backup buffer. The service process corresponding to the channel will scan the data blocks in the data file and read the data blocks to be backed up into the input buffer. When the input buffer is filled, it will be transferred to the output buffer. In the process of transfer, Data blocks will also be detected to detect whether there are damaged data blocks. When the output buffer is filled, a backup slice will be formed, and the service process corresponding to the channel will eventually write it to the location of the specified backup slice.

All backup and recovery cannot be the same. It needs to be adjusted and optimized according to the production environment of different customers, otherwise it is likely to cause problems in the production environment. Production environment scenarios include: insufficient backup disk space, slow storage I / O, fast storage and sufficient CPU resources.

The advantages of RMAN backup are as follows (take 11g as an example):

1) RMAN detects bad data blocks

2) There is no need to turn on the hot standby, and the additional rework will be reduced

3) RMAN backups back up only used blocks

4) RMAN backups have compression features

5) Support incremental backup strategy

For different scenarios, we need to give different optimization methods:

Scenario 1: insufficient space in the divided backup file system:
In such a case, the size of the query database is slightly larger than the backup space. What should we do?

This requires two concepts from RMAN’s backup features:

1 )null block compression

2 )unused block compression

The compression method of RMAN in version 10.1 is null compression. When scanning data blocks for backup, null compression can be performed. Blocks with empty block headers are filtered when transferred from the input buffer to the output buffer, and allocated but unformatted blocks will not be backed up.

In the 10.2 version of RMAN, there is an unused block compression. This compression method filters out data blocks that do not contain data, that is, the data block has been used (formatted) but does not contain data.

Unused block compression works only when the following conditions are met:

1) Initialization parameter compatible = 10.2 or later
2) Data files are managed locally

3) Full or level 0 backup

4) The specified location of the backup is on disk

Therefore, the backup piece backed up is equivalent to being compressed, so this is also RMANgameA very important feature of backup tools is to reduce unnecessary space waste.

Scenario 2: the backup file system space is very small
At this time, we can easily think of RMAN’s compression characteristics. RMAN can use binary compression algorithm for backup. This binary compression algorithm can greatly reduce the disk space required by the backup set. Generally, the compression ratio will reach 2-4 times

The commands to use this compression method are as follows:

rman> backup as compressed backupset database;

1) Enabling compression consumes more CPU resources..

2) Enabling compressed backups takes slightly longer

3) Save space for storing backups

Scenario 3: the backup piece is large and the backup time is long
The method to speed up backup is nothing more than opening parallel, which involves two keywords: channel and parallel

Auto assign channel:

Configure command to complete the channel configuration. If you do not manually assign channels to RMAN, rman automatically assigns channels to commands using predefined settings

RMAN>Configure channel device type disk format ‘xxx’;

Multiple channels can be configured to be automatically assigned

Manual allocation channel (parallelism):

The allocate channel command allocates channels. This command can only be placed in the run command block, and the channels it allocates only act on the commands in this run block.

run {

Allocate channel d1 device type disk format ‘xxx’;

Allocate channel d2 device type disk format ‘xxx’;

Backup database;

release channel d1 ;

release channel d2 ;


Note: if the data of the configured channel is less than parallelism, for example, parallelism is 5, configure chanl 1, 2, 3, then the configuration backup specified by 1, 2, 3, 4, 5 will be backed up according to the default configuration. If the configured channel is larger than parallelism, parallelism is 3, and 5 channels are configured, then channels 4 and 5 are ignored

A CPU can only process one transaction at any time, and the parallelism cannot exceed the number of CPUs.

Scenario 4: the amount of database data is huge, and incremental backup takes a long time
Here you need to open a database feature: block tracking

1) Block modification tracking records the update information of each block in the data file, and these tracking information is saved in the tracking file. After starting the block modification tracking, rman uses the information in the tracking file to only read the changed www.sangpi.com block information instead of scanning the entire data file, so as to improve the performance of RMAN backup.

2) Block modification tracking is disabled by default. If incremental backup is enabled, it is recommended to enable block modification tracking. After BCT is enabled, no other maintenance operations are required.

3) During backup, modification tracking maintains bitmap information for blocks that have been marked for change. Oracle will automatically manage the size of the modification tracking file and retain only the information of the last 8 block changes. More than 8 times, the first block bitmap information will be overwritten by the current change.

4) The first level 0 incremental backup scans the entire data file. Subsequent incremental backups use block tracking file information to scan only blocks that have been marked as changed since the last backup.

5) In the case of a RAC environment, the block trace file must be placed on a shared device.

6) Block tracking can be enabled when the database is in the open or mounted state

Turn on block tracking:

(1) See if the path is set

SQL> showparameter db_create_file_dest


db_create_file_dest string

(2) Set the path to store the block trace file

SQL> alter system set db_create_file_dest = ‘oracle/blkch’ scope=both sid=’*’;

System altered.

(3) Check setup path

SQL> show parameter db_create_file_dest


db_create_file_dest string oracle/blkch


(4) Turn on block tracking

SQL> alter database enable block change tracking;

Database altered.

You can also directly specify a directory or reuse existing files

SQL>alter database enable block change tracking using file ‘oracle/blkch/blkch.chg’ reuse;

Disable block tracking:

SQL>alter database disable block change tracking;

To see if block tracking is available:

SQL> select status, filename fromv$block_change_tracking;


ENABLED /oracle/blkch/blkch.chg

Note that there are generally two scenarios for fast tracking: 1. Conventional RMAN backup strategy with incremental backup; 2. Applied to xtts migration, it can effectively speed up the backup of incremental data.

When using RMAN incremental backup, enabling block tracking will shorten the time of RMAN backup when doing incremental backup, because the entire data file does not need to be scanned. But block tracing also brings some other overhead. Therefore, it is necessary to decide whether to enable block tracking according to the actual situation.