RMAN备份时遭遇ORA-19571

时间：2015-07-23 02:15:58 阅读：172 评论：0 收藏：0 [点我收藏+]

进行RMAN备份时出现ORA-19571错误，导致备份任务终止，具体错误如下：

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

错误提示很明显，是因为在控制文件中没有找到某个归档文件记录，导致备份失败，看上去像是控制文件记录被覆盖了。控制文件中的记录分为两类，
一类是循环使用的记录，当记录的solt满时，会覆盖老的记录，记录的保存时间由参数control_file_record_keep_time控制。所以这里首先检查这个参数
的设置。

SQL> show parameter control_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 15

参数配置为15天，接下来再检查报错中的归档日志的生成时间

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 2015-07-08 02:05:59

从上面的信息看，归档上两天前生成的，该记录在控制文件中不应该过期。为保证备份任务及时完成，不影响下一天的正常业务，首先手动将归档信息
注册到控制文件。

RMAN>catalog start with ‘/arch1/‘;

使用上面的命令注册时，在其中一个节点上提示没有发现可注册的文件，使用下面的命令分别对每个归档文件进行注册

run{
catalog archivelog ‘/arch1/xxx_1_47849_801075830.dbf‘;
catalog archivelog ‘/arch1/xxx_1_47850_801075830.dbf‘;
...省略部分
catalog archivelog ‘/arch1/xxx_1_47854_801075830.dbf‘;
catalog archivelog ‘/arch1/xxx_1_47855_801075830.dbf‘;
}

手动注册后备份成功，但为什么归档信息没有正确的保留在控制文件中，接下来做进一步分析。
首先检查数据库的alert日志，发现在备份任务失败前出现如下警告：

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

这个警告信息是在AIX平台下，没有将数据库文件放置在零偏移的raw logical volumes设备上，下面对这个错误进行验证：

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

发现控制文件所在的设备的确存在偏移，如果没有偏移，会提示Database file type: raw device without 4K starting offset。在AIX中，不同的vg类型决定了不同
的lv结构，original valume group在数据落地的时候会产生4k的偏移量，逻辑卷前 4k 用于存储 control block (LVCB)，big volume group在创建裸设备时可以指定参数消除偏移，scalable volume group不会产生偏移，所以，在支持scalable volume group的系统中，一定要建立scalable 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 PPs 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

标注的部分标明，该卷组是big volume group，所以要消除4k偏移量，需要在建立lv的时候指定-T O参数。不巧，安装这套数据库的DBA没有指定这个参数，导致
控制文件放置在了存在4k偏移量的设备上。
使用存在偏移量的设备存放数据库文件，当数据库文件的块大小超过4k时（控制文件一般为16k），数据库的块就可能会进行分裂，跨越lv条带边界，这样在操作系统崩溃或者重启的时候
就很可能导致数据块破碎，造成文件损坏，这是非常危险的。
但是这个警告信息出现时不是致命的，而且数据库目前运行正常，不应该导致控制文件中记录丢失。数据库使用的是裸设备，怀疑会不会是控制文件增长超过了
lv的大小，下面检查控制文件大小

SQL> select CREATION_TIME,CHECKPOINT_TIME,FILESIZE/1024/1024 from v$backup_controlfile_details;
CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024
------------------- ------------------- ------------------
2012-12-03 17:03:51 2015-06-30 07:52:47 20.390625
2012-12-03 17:03:51 2015-06-30 09:40:21 20.390625
2012-12-03 17:03:51 2015-06-30 12:21:55 20.390625
2012-12-03 17:03:51 2015-06-30 14:07:27 20.390625
2012-12-03 17:03:51 2015-07-01 12:21:36 20.390625
2012-12-03 17:03:51 2015-07-01 14:11:47 20.390625
2012-12-03 17:03:51 2015-07-02 12:22:19 20.390625
2012-12-03 17:03:51 2015-07-02 14:13:46 20.390625
2012-12-03 17:03:51 2015-07-03 12:26:32 20.390625
2012-12-03 17:03:51 2015-07-03 17:30:12 20.390625
2012-12-03 17:03:51 2015-07-04 12:22:04 20.390625
CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024
------------------- ------------------- ------------------
2012-12-03 17:03:51 2015-07-05 12:22:45 20.390625
2012-12-03 17:03:51 2015-07-06 12:21:33 20.390625
2012-12-03 17:03:51 2015-07-07 07:45:44 20.390625
2012-12-03 17:03:51 2015-07-07 09:35:59 20.390625
2012-12-03 17:03:51 2015-07-08 07:46:13 20.390625
2012-12-03 17:03:51 2015-07-08 09:58:12 20.390625
2012-12-03 17:03:51 2015-07-08 12:21:47 20.390625
2012-12-03 17:03:51 2015-07-08 16:21:07 20.390625
2012-12-03 17:03:51 2015-07-09 12:21:48 20.390625
2012-12-03 17:03:51 2015-07-10 12:21:58 20.390625
2012-12-03 17:03:51 2015-07-11 12:22:24 20.390625
CREATION_TIME CHECKPOINT_TIME FILESIZE/1024/1024
------------------- ------------------- ------------------
2012-12-03 17:03:51 2015-07-12 12:22:41 20.390625
2012-12-03 17:03:51 2015-07-13 12:21:53 20.390625
2012-12-03 17:03:51 2015-07-14 12:22:02 20.390625
2012-12-03 17:03:51 2015-07-15 05:00:43 20.390625
2012-12-03 17:03:51 2015-07-15 11:37:27 27.265625
2012-12-03 17:03:51 2015-07-16 06:23:44 29.171875
2012-12-03 17:03:51 2015-07-16 10:37:40 29.171875
2012-12-03 17:03:51 2015-07-16 12:21:54 29.171875

控制文件不到30M，存放控制文件的lv为1G，因此上面的假设不成立。
再继续分析alert日志，在每次备份失败前，会连续出现几次ALTER SYSTEM ARCHIVE LOG，然后就出现上文提到的警告信息，仔细观察警告信息，每次警告
信息出现都是伴随着Expanded controlfile section。所以怀疑是由于备份时导致控制文件增长，触发上述错误，且底层可能伴随着块分裂，这时导致控制文件信息
丢失或是备份进程不能正确读取控制文件信息，触发ORA-19571。
临时的调整方案可以将注册归档文件的动作写入到备份脚本中，或者在出现报错后手动注册归档信息，再进行备份。

RMAN备份时遭遇ORA-19571

原文：http://blog.itpub.net/29821678/viewspace-1736660/

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年09月23日 (328)
2021年09月24日 (313)
2021年09月17日 (191)
2021年09月15日 (369)
2021年09月16日 (411)
2021年09月13日 (439)
2021年09月11日 (398)
2021年09月12日 (393)
2021年09月10日 (160)
2021年09月08日 (222)