Oracle RMAN修复逻辑坏块
试用Rman可以实现数据块级的数据恢复,在传统恢复手段中即某个数据文件的一个数据块被损坏,就造成整个数据文件无法试用,此时必
RMAN 实现数据块恢复
试用Rman可以实现数据块级的数据恢复,在传统恢复手段中即某个数据文件的一个数据块被损坏,就造成整个数据文件无法试用,此时必须通过备份恢复整个数据文件。显然这样的方法会会时间较长,而RMAN实现块级恢复,如果某个数据文件的数据损坏,通过数据文件的完整备份就可以恢复数据块。
案例:
数据库是一个单实例Oracle数据库,该库的总大小有700G。
存储设备使用华为存储,备份设备使用希捷3T的移动硬盘。该数据库无DG无OGG。备份策略为每周六0点全库备份,周三0点1级差异备份其余时间为每天0点做2级差异备份。全库备份大小为500G左右。
2.2 故障情况
本次故障原因是INSPUROA用户在查询EDOC_BASE_WORKFLOW表出现报错。提示故障坏块为datafile 5。报错信息取至alter日志如下:
Reading datafile '/oradata/datafiles/oadb/oa01.dbf' for corruption at rdba: 0x016d4dd5 (file 5, block 2969045)
Reread (file 5, block 2969045) found same corrupt data (no logical check)
Tue Aug 18 10:53:51 2015
Corrupt Block Found
TSN = 6, TSNAME = OA
RFN = 5, BLK = 2969045, RDBA = 23940565
OBJN = 95690, OBJD = 95690, OBJECT = EDOC_BASE_WORKFLOW, SUBOBJECT =
SEGMENT OWNER = INSPUROA, SEGMENT TYPE = Table Segment
Tue Aug 18 10:55:03 2015
Hex dump of (file 5, block 2969045) in trace file /u01/app/oracle/diag/rdbms/oadb/oadb/trace/oadb_ora_4565.trc
Corrupt block relative dba: 0x016d4dd5 (file 5, block 2969045)
Bad header found during buffer read
Data in bad block:
type: 117 format: 0 rdba: 0x20206b73
last change scn: 0x2020.20202020 seq: 0x20 flg: 0x20
spare1: 0x64 spare2: 0x69 spare3: 0x0
consistency value in tail: 0x4d240601
check value in block header: 0x5f49
block checksum disabled
Reading datafile '/oradata/datafiles/oadb/oa01.dbf' for corruption at rdba: 0x016d4dd5 (file 5, block 2969045)
Reread (file 5, block 2969045) found same corrupt data (no logical check)
Tue Aug 18 10:55:03 2015
Corrupt Block Found
TSN = 6, TSNAME = OA
RFN = 5, BLK = 2969045, RDBA = 23940565
OBJN = 95690, OBJD = 95690, OBJECT = EDOC_BASE_WORKFLOW, SUBOBJECT =
SEGMENT OWNER = INSPUROA, SEGMENT TYPE = Table Segment
Tue Aug 18 10:57:29 2015
Hex dump of (file 5, block 2969045) in trace file /u01/app/oracle/diag/rdbms/oadb/oadb/trace/oadb_ora_21708.trc
Corrupt block relative dba: 0x016d4dd5 (file 5, block 2969045)
Bad header found during buffer read
Data in bad block:
type: 117 format: 0 rdba: 0x20206b73
last change scn: 0x2020.20202020 seq: 0x20 flg: 0x20
spare1: 0x64 spare2: 0x69 spare3: 0x0
consistency value in tail: 0x4d240601
check value in block header: 0x5f49
block checksum disabled
分析原因
观察存储,无报错警告,初步怀疑逻辑坏块
执行修复
根据报错信息
Reading datafile '/oradata/datafiles/oadb/oa01.dbf' for corruption at rdba: 0x016d4dd5 (file 5, block 2969045)
Reread (file 5, block 2969045) found same corrupt data (no logical check)
Corrupt Block Found
TSN = 6, TSNAME = OA
RFN = 5, BLK = 2969045, RDBA = 23940565
OBJN = 95690, OBJD = 95690, OBJECT = EDOC_BASE_WORKFLOW, SUBOBJECT =
SEGMENT OWNER = INSPUROA, SEGMENT TYPE = Table Segment
确定数据文件 datafile 5,oa01.dbf出现坏块现象
查看坏块信息:
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
5 2969045 1 0 CORRUPT
确定坏块为2969045号
检查备份日志(增量,全量)是否完整备份
检查备份datafile 5 是否完整
RMAN> backup validate datafile 5;
Starting backup at 18-AUG-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=982 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/oradata/datafiles/oadb/oa01.dbf
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:35
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
5 FAILED 0 1840 4190720 9484751217293
File Name: /oradata/datafiles/oadb/oa01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 2842014
Index 0 182983
Other 1 1163883
validate found one or more corrupt blocks
See trace file /u01/app/oracle/diag/rdbms/oadb/oadb/trace/oadb_ora_13513.trc for details
Finished backup at 18-AUG-15
执行修复
使用RMAN工具
RMAN> blockrecover datafile 5 block 2969045;
Starting recover at 18-AUG-15
using channel ORA_DISK_1

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)

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 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.

La numérisation complète de la table peut être plus rapide dans MySQL que l'utilisation d'index. Les cas spécifiques comprennent: 1) le volume de données est petit; 2) Lorsque la requête renvoie une grande quantité de données; 3) Lorsque la colonne d'index n'est pas très sélective; 4) Lorsque la requête complexe. En analysant les plans de requête, en optimisant les index, en évitant le sur-index et en maintenant régulièrement des tables, vous pouvez faire les meilleurs choix dans les applications pratiques.

Oui, MySQL peut être installé sur Windows 7, et bien que Microsoft ait cessé de prendre en charge Windows 7, MySQL est toujours compatible avec lui. Cependant, les points suivants doivent être notés lors du processus d'installation: téléchargez le programme d'installation MySQL pour Windows. Sélectionnez la version appropriée de MySQL (communauté ou entreprise). Sélectionnez le répertoire d'installation et le jeu de caractères appropriés pendant le processus d'installation. Définissez le mot de passe de l'utilisateur racine et gardez-le correctement. Connectez-vous à la base de données pour les tests. Notez les problèmes de compatibilité et de sécurité sur Windows 7, et il est recommandé de passer à un système d'exploitation pris en charge.

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]

La différence entre l'index cluster et l'index non cluster est: 1. Index en cluster stocke les lignes de données dans la structure d'index, ce qui convient à la requête par clé et plage primaire. 2. L'index non clumpant stocke les valeurs de clé d'index et les pointeurs vers les lignes de données, et convient aux requêtes de colonne de clés non primaires.

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.
