The unreasonable setting of MAXPIECESIZE and FORMAT causes RMAN backup to fail.

Source: Internet
Author: User

The unreasonable setting of MAXPIECESIZE and FORMAT causes RMAN backup to fail.
Today, I went to the customer to build the DG. When I created the RMAN backup set, I encountered a problem, causing the backup set to never be generated. Because the customer's backup set is about 10 Gb, it would take more than an hour to back up data at a time, I started to waste a lot of time. After diagnosis, I found that the original problem was caused by MAXPIECESIZE. Next I did a test to illustrate the fault phenomenon and solution:
[Root @ ora10g ~] # Su-oracle
[Oracle @ ora10g ~] $ Sqlplus/as sysdba
SQL * Plus: Release 10.2.0.1.0-Production on 24 14:32:34 2014
Copyright (c) 1982,200 5, Oracle. All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-ProductionWith the Partitioning, OLAP and Data Mining options
SQL> select open_mode from v $ database;
OPEN_MODE----------READ WRITE
SQL> exitDisconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-ProductionWith the Partitioning, OLAP and Data Mining options [oracle @ ora10g ~] $ Rman target/
Recovery Manager: Release 10.2.0.1.0-Production on 24 14:32:52 2014
Copyright (c) 1982,200 5, Oracle. All rights reserved.
Connected to target database: ORA10G (DBID = 4175411955)
RMAN> show all;
Using target database control file instead of recovery catalogRMAN configuration parameters are: configure retention policy to redundancy 5; configure backup optimization on; configure default device type to disk; configure controlfile autobackup on; configure controlfile autobackup format for device type disk to '/u01/orabackup/backupsets/ora10g-% F. ctl '; configure device type disk parallelism 1 backup type to backupset; configure datafile backup copies for device type disk to 1; # defaultCONFIGURE archivelog backup copies for device type disk to 1; # defaultCONFIGURE channel device type disk maxpiecesize 10000 M; -- maximum backup set limit: configure maxsetsize to unlimited; # defaconfigconfigure encryption for database off; # defaultCONFIGURE encryption algorithm 'aes128 '; # defaultCONFIGURE archivelog deletion policy to none; configure snapshot controlfile name to '/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_ora10g.f'; # default
RMAN> exit

Recovery Manager complete. [oracle @ ora10g ~] $ Cd/u01/orabackup/scripts/[oracle @ ora10g scripts] $ ls-ltotal 4-rwxr-xr-x 1 oracle oinstall 2443 Dec 24 backup_full.sh [oracle @ ora10g scripts] $. /backup_full.shRMAN> RMAN> 2> 3> RMAN> [oracle @ ora10g backupsets] $ ls-lrthtotal ready m-rw-r ----- 1 oracle oinstall 9.8 M Dec 24 ora10g-4175411955_20141224_867162246_380.arc-rw-r ----- 1 oracle oinstall 1.7 M Dec 24 ora10g-4175411955_20141224_867162255_381.arc-rw-r ----- 1 oracle oinstall 439 K Dec 24 ora10g-4175411955_20141224_867162257_382.arc-rw-r ----- 1 oracle oinstall 747 K dec 24 ora10g-4175411955_20141224_867162820_384.arc-rw-r ----- 1 oracle oinstall 170 M Dec 24 ora10g-4175411955_20141224_867162823_385.db-rw-r ----- 1 oracle oinstall 491 K Dec 24 ora10g-4175411955_20141224_867162990_386.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-00.ctl [oracle @ ora10g backupsets] $
According to the preceding configuration, the RMAN backup set is correctly generated. The total size is about MB, and the backup set of the largest data file is 170 MB.
In the backup script, the format is "$ ORACLE_SID-% I _ % T _ % t _ % s. db". The specific statement of the script is as follows:
Backup as compressed backupset database format' $ RMAN_BACKUPSETS/$ ORACLE_SID-% I _ % T _ % t _ % s. db 'tag' db _ Bak' plus archivelog format' $ RMAN_BACKUPSETS/$ ORACLE_SID-% I _ % T _ % t _ % s. arc 'not backed up 1 times delete all input tag 'arc _ Bak ';
When you change the value of MAXPIECESIZE to a smaller value than the previous largest backup set size (170 M), for example, to M, run the backup script, and then view the log file output by RMAN, A ORA-27038 was found, prompting that the file already exists:
[Oracle @ ora10g backupsets] $ cat ../logs/rman. log | grep ORA-
ORA-19504: failed to create file "/u01/orabackup/backupsets/ora10g-4175411955_20141224_867163196_389.db"
ORA-27038: created file already exists

Channel ORA_DISK_1: starting piece 2 at 2014-12-24RMAN-00571: ========================================================== ============================== RMAN-00569: ================ error message stack follows ============================ RMAN-00571: ========================================================== ============================== RMAN-03002: failure of backup plus archivelog command at 12/24/2014 14: 41: 52ORA-19504: failed to create file "/u01/orabackup/backupsets/ora10g-4175411955_20141224_867163196_389.db" ORA-27038: created file already existsAdditional information: 1
Under normal circumstances, the maximum size of the generated backup set is 170 MB, but after you modify the MAXPIECESIZE parameter to MB, once the backup set size exceeds MB, 2nd backup slices are automatically generated, because I only configured "$ ORACLE_SID-% I _ % T _ % t _ % s. db ", the meaning of these wildcards is: % I -- DBID % T -- date and time (year, month, day) % t -- auto-generated timestamp % s -- backup set serial number (Sequence)
When the first backup file reaches 2nd MB, you want to generate files. However, these Wildcards are insufficient to distinguish the backup files in the backup set (the same file name is generated ), when 2nd backup slices are created, the system prompts that the file already exists, resulting in backup failure.
There are two ways to solve this problem:
1. Add the % p wildcard to the format parameter.
When the size of MAXPIECESIZE is exceeded, only % p can generate different backup slices, because the timestamp % t is insufficient to distinguish the names of different parts.

[Oracle @ ora10g backupsets] $.../scripts/backup_full.sh
RMAN> 2> 3> RMAN> [oracle @ ora10g backupsets] $ ls -lrth .. /backupsets/total 375M-rw-r ----- 1 oracle oinstall 9.8 M Dec 24 ora10g-4175411955_20141224_867162246_380.arc-rw-r ----- 1 oracle oinstall 1.7 M Dec 24 ora10g-4175411955_20141224_867162255_381.arc-rw-r ----- 1 oracle oinstall 439 K Dec 24 ora10g-4175411955_20141224_867162257_382.arc-rw-r ----- 1 oracle oinstall 747 K Dec 24 ora10g-4175411955_20141224_867162820_384.arc-rw-r ----- 1 oracle oinstall 170 M Dec 24 ora10g-4175411955_20141224_867162823_385.db-rw-r ----- 1 oracle oinstall 491 K Dec 24 ora10g-4175411955_20141224_867162990_386.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-00.ctl-rw-r ----- 1 oracle oinstall 30 K Dec 24 ora10g-4175411955_20141224_867163193_388.arc-rw-r ----- 1 oracle oinstall 7.4 M Dec 24 ora10g-4175411955_20141224_867164604_390_1.arc-rw-r ----- 1 oracle oinstall 99 M Dec 24 ora10g-4175411955_20141224_867164614_391_1.db-rw-r ----- 1 oracle oinstall 73 M Dec 24 ora10g-4175411955_20141224_867164614_391_2.db-rw-r ----- 1 oracle oinstall 22 K Dec 24 ora10g-4175411955_20141224_867164776_392_1.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-01.ctl [oracle @ ora10g backupsets] $
After the % p wildcard is added to the format, the problem is solved. You can create a backup set again through the script backup set. Note that because % p is configured, here, the db Backup set is changed to two backup slices: "_ 1" and "_ 2", separated by MB (the size specified by MAXPIECESIZE)
[Oracle @ ora10g backupsets] $ cat ../logs/rman. log | grep ORA-ORA-19504: failed to create file "/u01/orabackup/backupsets/ora10g-4175411955_20141224_867163196_389.db"
ORA-27038: created file already exists [oracle @ ora10g backupsets] $
Since the RMAN backup log uses the append method, this error is recorded before the capture, no new ORA-27038 appears
2. Clear the value of MAXPIECESIZE
When MAXPIECESIZE is set to an infinitely large value, it can solve the problem that the backup set exceeds the upper limit, or you do not need to configure % p. However, this method is not recommended. If the data size of the database is very large, the generated backup set is too large, which is not conducive to storage and recovery.
RMAN> configure channel device type disk clear;
Old RMAN configuration parameters: configure channel device type disk maxpiecesize 100 M; old RMAN configuration parameters are successfully deleted -- the previously configured MAXPIECESIZE value is cleared
RMAN> show all;
RMAN configuration parameters are: configure retention policy to redundancy 5; configure backup optimization on; configure default device type to disk; configure controlfile autobackup on; configure controlfile autobackup format for device type disk to '/u01/orabackup/backupsets/ora10g-% F. ctl '; configure device type disk parallelism 1 backup type to backupset; configure datafile backup copies for device type disk to 1; # defaultCONFIGURE archivelog backup copies for device type disk to 1; # defaultCONFIGURE maxsetsize to unlimited; # defaultCONFIGURE encryption for database off; # defaultCONFIGURE encryption algorithm 'aes128 '; # defaultCONFIGURE archivelog deletion policy to none; configure snapshot controlfile name to '/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_ora10g.f'; # default
We can see that the value of MAXPIECESIZE does not exist in show all, that is, there is no limit on the backup part.
Back up again. You can run the script or run the following Backup statement separately: RMAN> backup as compressed backupset database format' $ RMAN_BACKUPSETS/$ ORACLE_SID-% I _ % T _ % t _ % s. db 'tag' db _ Bak' plus archivelog format' $ RMAN_BACKUPSETS/$ ORACLE_SID-% I _ % T _ % t _ % s. arc 'not backed up 1 times delete all input tag 'arc _ Bak ';

[Oracle @ ora10g backupsets] $... /scripts/backup_full.sh RMAN> 2> 3> RMAN> [oracle @ ora10g backupsets] $ ls-lrth .. /backupsets/total 553M-rw-r ----- 1 oracle oinstall 9.8 M Dec 24 ora10g-4175411955_20141224_867162246_380.arc-rw-r ----- 1 oracle oinstall 1.7 M Dec 24 ora10g-4175411955_20141224_867162255_381.arc-rw-r ----- 1 oracle oinstall 439 K Dec 24 ora10g-4175411955_20141224_867162257_382.arc-rw-r ----- 1 oracle oinstall 747 K Dec 24 ora10g-4175411955_20141224_867162820_384.arc-rw-r ----- 1 oracle oinstall 170 M Dec 24 ora10g-4175411955_20141224_867162823_385.db-rw-r ----- 1 oracle oinstall 491 K Dec 24 ora10g-4175411955_20141224_867162990_386.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-00.ctl-rw-r ----- 1 oracle oinstall 30 K Dec 24 ora10g-4175411955_20141224_867163193_388.arc-rw-r ----- 1 oracle oinstall 7.4 M Dec 24 ora10g-4175411955_20141224_867164604_390_1.arc-rw-r ----- 1 oracle oinstall 99 M Dec 24 ora10g-4175411955_20141224_867164614_391_1.db-rw-r ----- 1 oracle oinstall 73 M Dec 24 ora10g-4175411955_20141224_867164614_391_2.db-rw-r ----- 1 oracle oinstall 22 K Dec 24 ora10g-4175411955_20141224_867164776_392_1.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-01.ctl-rw-r ----- 1 oracle oinstall 457 K Dec 24 ora10g-4175411955_20141224_867165923_394.arc-rw-r ----- 1 oracle oinstall 170 M Dec 24 ora10g-4175411955_20141224_867165927_395.db-rw-r ----- 1 oracle oinstall 20 K Dec 24 ora10g-4175411955_20141224_867166094_396.arc-rw-r ----- 1 oracle oinstall 7.3 M Dec 24 ora10g-c-4175411955-20141224-02.ctl [oracle @ ora10g backupsets] $
The backup set generated by 3rd backup scripts is not partitioned (because the % p parameter is removed), and The MAXPIECESIZE limit is also removed.
Summary
If the value of MAXIECESIZE is specified as a specific value in the RMAN parameter, the wildcard "% p" must be added to the FORMAT. Otherwise, once the backup part exceeds the upper limit, the backup fails. Therefore, we recommend that you configure the MAXPIECESIZE parameter and add the % U wildcard in the FORMAT, which contains % u (the unique 8-bit number automatically calculated ), % p (Backup credits), % c (number of copies of backup slices, 1-256 ).







Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.