ORA-19571 for RMAN backup

ORA-19571 for RMAN backup

A ORA-19571 error occurred while performing an RMAN backup, resulting in the end of the backup task with the following error:

RMAN-00571: ========================================================== ==============================

RMAN-00569: ==================== error message stack follows ==========================

RMAN-00571: ========================================================== ==============================

RMAN-03002: failure of backup plus archivelog command at 07/10/2015 16:18:43

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/10/2015 16:18:24

ORA-19571: archived-log recid 85421 stamp 650564644 not found in control file

The error message is obvious because an archive file record is not found in the control file, resulting in backup failure. It seems that the control file record is overwritten. There are two types of records in the control file. One is the record used cyclically. When the solt of the record is full, the old record will be overwritten. The record retention time is controlled by the control_file_record_keep_time parameter. Therefore, first check the settings of this parameter.

SQL> show parameter control_file

NAME TYPE VALUE

-----------------------------------------------------------------------------

Control_file_record_keep_time integer 15
The parameter is set to 15 days, and then check the generation time of the archive log in the error message.

SQL> select recid, SEQUENCE #, ARCHIVED, STATUS, COMPLETION_TIME from v $ archived_log where recid = 125609;

Recid sequence # arc s COMPLETION_TIME

-------------------------------------------

125609 885421 yes a 02:05:59
From the above information, the record generated two days ago on the archive should not expire in the control file. To ensure that the backup task is completed in a timely manner without affecting the normal business of the next day, you must manually register the archive information to the control file.

RMAN> catalog start with '/arch1 /';
When you use the preceding command to register an archive file, the system prompts that no registrable files are found on one of the nodes. Use the following command to register each archive file.

Run {

Catalog archivelog '/arch1/xxx_rj47849_801075830.dbf ';

Catalog archivelog '/arch1/xxx_rj47850_801075830.dbf ';

... Omitted
Catalog archivelog '/arch1/xxx_rj47854_801075830.dbf ';

Catalog archivelog '/arch1/xxx_rj47855_801075830.dbf ';
}
After manual registration, the backup is successful, but why the archive information is not properly stored in the control file, then perform further analysis.
First, check the alert log of the database and find the following warning before the Backup Task fails:

WARNING: You are creating/reusing datafile/dev/rlvims_control1.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

WARNING: You are creating/reusing datafile/dev/rlvims_control1.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

WARNING: You are creating/reusing datafile/dev/rlvims_control2.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

WARNING: You are creating/reusing datafile/dev/rlvims_control2.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

WARNING: You are creating/reusing datafile/dev/rlvims_control3.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

WARNING: You are creating/reusing datafile/dev/rlvims_control3.

WARNING: Oracle recommends creating new datafiles on devices with zero offset. the command "/usr/sbin/mklv-y LVname-t o-w n-s n-r n VGname NumPPs" can be used. please contact Oracle customer support for more details.

Expanded controlfile section 28 from 564 to 1128 records

Requested to grow by 564 records; added 3 blocks of records
The warning message is that the database file is not placed on a raw logical volumes device with a zero offset on the AIX platform. The following is a verification of this error:

Xxx1> dbfsize/dev/rlvims_control1

Database file:/dev/rlvims_control1

Database file type: raw device

Database file size: 1866 16384 byte blocks

Xxx1> dbfsize/dev/rlvims_control2

Database file:/dev/rlvims_control2

Database file type: raw device

Database file size: 1866 16384 byte blocks

Xxx1> dbfsize/dev/rlvims_control3

Database file:/dev/rlvims_control3

Database file type: raw device

Database file size: 1866 16384 byte blocks
The device where the control file is located does have an offset. If there is no offset, the system will prompt the Database file type: raw device without 4 K starting offset. In AIX, different vg types determine different lv structures. original valume group generates a 4 K offset when data is stored, the first 4 k of the logical volume is used to store the control block (LVCB). When creating a bare device, the big volume group can specify a parameter to eliminate the offset. The scalable volume group does not produce the offset. Therefore, in systems that support scalable volume group, you must create a scalable volume group.
To confirm the type of the volume group:

Volume group: vgims vg identifier: 00f7614c00004c000000013b4a54f3b1

Vg state: active pp size: 256 megabyte (s)

Vg permission: read/write TOTAL PPs: 3388 (867328 megabytes)

MAX LVs: 512 FREE PPs: 488 (124928 megabytes)

LVs: 68 USED PPs: 2900 (742400 megabytes)

OPEN LVs: 66 QUORUM: 7 (Enabled)

TOTAL PVs: 12 vg descriptors: 12

STALE PVs: 0 STALE PPs: 0

ACTIVE PVs: 12 auto on: no

Concurrent: Enhanced-Capable Auto-Concurrent: Disabled

VG Mode: Concurrent

Node ID: 1 Active Nodes: 2

MAX packets per VG: 130048

MAX PPs per PV: 1016 MAX PVs: 128

LTG size (Dynamic): 256 kilobyte (s) auto sync: no

Hot spare: no bb policy: relocatable

Pv restriction: none infinite retry: no
The marked part indicates that the volume group is a big volume group. To eliminate the 4 K offset, you must specify the-t o parameter when creating the lv. Unfortunately, the DBA who installed the database did not specify this parameter, causing the control file to be placed on a device with a 4 K offset.
When the block size of the database file exceeds 4 kb (the control file is usually 16 KB), the database block may be split, across the lv Strip border, this may cause data block fragmentation and file damage when the operating system crashes or restarts, which is very dangerous.
However, this warning message is not fatal, and the database is currently running normally and should not cause loss of records in the control file. The database uses bare devices, and it is suspected that the number of control files has exceeded.
Lv size. Check the size of the control file below.

SQL & gt; select CREATION_TIME, CHECKPOINT_TIME, FILESIZE/1024/1024 from v $ backup_controlfile_details;

CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024

--------------------------------------------------------

17:03:51 07:52:47 20.390625

17:03:51 09:40:21 20.390625

17:03:51 12:21:55 20.390625

17:03:51 14:07:27 20.390625

17:03:51 12:21:36 20.390625

17:03:51 14:11:47 20.390625

17:03:51 12:22:19 20.390625

17:03:51 14:13:46 20.390625

17:03:51 12:26:32 20.390625

17:03:51 17:30:12 20.390625

17:03:51 12:22:04 20.390625

CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024

--------------------------------------------------------

17:03:51 12:22:45 20.390625

17:03:51 12:21:33 20.390625

17:03:51 07:45:44 20.390625

17:03:51 09:35:59 20.390625

17:03:51 07:46:13 20.390625

17:03:51 09:58:12 20.390625

17:03:51 12:21:47 20.390625

17:03:51 16:21:07 20.390625

17:03:51 12:21:48 20.390625

17:03:51 12:21:58 20.390625

17:03:51 12:22:24 20.390625

CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024

--------------------------------------------------------

17:03:51 12:22:41 20.390625

17:03:51 12:21:53 20.390625

17:03:51 12:22:02 20.390625

17:03:51 05:00:43 20.390625

17:03:51 11:37:27 27.265625

17:03:51 06:23:44 29.171875

17:03:51 10:37:40 29.171875

17:03:51 12:21:54 29.171875

The control file is less than 30 mb, And the lv for storing the control file is 1 GB. Therefore, the above assumptions are not true.

Continue to analyze the alert LOG. Before each backup failure, the alter system archive log appears several times in a row, and the warning information mentioned above appears. Observe the warning information carefully, each warning message is accompanied by an Expanded controlfile section. Therefore, it is suspected that the backup may cause the control file to grow, trigger the above error, and the underlying layer may be accompanied by block splitting. In this case, the control file information is lost or the backup process cannot correctly read the control file information, trigger ORA-19571.

The temporary adjustment scheme can write the action of registering the archive file to the backup script, or manually register the archive information after an error is reported before backing up.

-------------------------------------- Recommended reading --------------------------------------

RMAN: Configure an archive log deletion policy

Basic Oracle tutorial-copying a database through RMAN

Reference for RMAN backup policy formulation

RMAN backup learning notes

Oracle Database Backup encryption RMAN Encryption

-------------------------------------- Split line --------------------------------------