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

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

AI Hentai Generator
Générez AI Hentai gratuitement.

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

L'article discute de l'utilisation de l'instruction ALTER TABLE de MySQL pour modifier les tables, notamment en ajoutant / abandon les colonnes, en renommant des tables / colonnes et en modifiant les types de données de colonne.

L'article discute de la configuration du cryptage SSL / TLS pour MySQL, y compris la génération et la vérification de certificat. Le problème principal est d'utiliser les implications de sécurité des certificats auto-signés. [Compte de caractère: 159]

L'article traite des outils de GUI MySQL populaires comme MySQL Workbench et PhpMyAdmin, en comparant leurs fonctionnalités et leur pertinence pour les débutants et les utilisateurs avancés. [159 caractères]

L'article traite des stratégies pour gérer de grands ensembles de données dans MySQL, y compris le partitionnement, la rupture, l'indexation et l'optimisation des requêtes.

L'article discute de la suppression des tables dans MySQL en utilisant l'instruction TABLE DROP, mettant l'accent sur les précautions et les risques. Il souligne que l'action est irréversible sans sauvegardes, détaillant les méthodes de récupération et les risques potentiels de l'environnement de production.

Les capacités de recherche en texte intégral d'InNODB sont très puissantes, ce qui peut considérablement améliorer l'efficacité de la requête de la base de données et la capacité de traiter de grandes quantités de données de texte. 1) INNODB implémente la recherche de texte intégral via l'indexation inversée, prenant en charge les requêtes de recherche de base et avancées. 2) Utilisez la correspondance et contre les mots clés pour rechercher, prendre en charge le mode booléen et la recherche de phrases. 3) Les méthodes d'optimisation incluent l'utilisation de la technologie de segmentation des mots, la reconstruction périodique des index et l'ajustement de la taille du cache pour améliorer les performances et la précision.

L'article discute de l'utilisation de clés étrangères pour représenter les relations dans les bases de données, en se concentrant sur les meilleures pratiques, l'intégrité des données et les pièges communs à éviter.

L'article discute de la création d'index sur les colonnes JSON dans diverses bases de données comme PostgreSQL, MySQL et MongoDB pour améliorer les performances de la requête. Il explique la syntaxe et les avantages de l'indexation des chemins JSON spécifiques et répertorie les systèmes de base de données pris en charge.
