RMAN备份时遭遇ORA-19571
进行RMAN备份时出现ORA-19571错误,导致备份任务终止,错误提示很明显,是因为在控制文件中没有找到某个归档文件记录,导致备份失
进行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

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

이 기사에서는 Drop Table 문을 사용하여 MySQL에서 테이블을 떨어 뜨리는 것에 대해 설명하여 예방 조치와 위험을 강조합니다. 백업 없이는 행동이 돌이킬 수 없으며 복구 방법 및 잠재적 생산 환경 위험을 상세하게합니다.

기사는 외국 열쇠를 사용하여 데이터베이스의 관계를 나타내고 모범 사례, 데이터 무결성 및 피할 수있는 일반적인 함정에 중점을 둡니다.

이 기사에서는 PostgreSQL, MySQL 및 MongoDB와 같은 다양한 데이터베이스에서 JSON 열에서 인덱스를 작성하여 쿼리 성능을 향상시킵니다. 특정 JSON 경로를 인덱싱하는 구문 및 이점을 설명하고 지원되는 데이터베이스 시스템을 나열합니다.
