Bloc corrompu dans un fichier de données !

**zestrellita** · 28/11/2005, 13h57

Bonjour à tous,

Je vous expose mon problème : il y a une semaine, nous avons subi coup sur coup 2 pannes d'électricité au niveau de nos serveurs de bases de données.
A l'issue de la 1ère panne, les bases ont toutes redémarré correctement, mais en contrôlant leurs fichiers d'alerte, l'une d'elles indiquait que des blocs corrompus avaient été trouvés, mais apparemment réparés avec succès.
En voici un extrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
Completed redo scan
 9597 redo blocks read, 758 data blocks need recovery
Mon Nov 21 21:24:04 2005
Started recovery at
 Thread 1: logseq 3622, block 2578, scn 0.0
Mon Nov 21 21:24:04 2005
Recovery of Online Redo Log: Thread 1 Group 6 Seq 3622 Reading mem 0
  Mem# 0 errs 0: /u04/oradata/builder/redo06.log
  Mem# 1 errs 0: /u03/oradata/builder/redo16.log
***
Corrupt block relative dba: 0x00806eb5 (file 2, block 28341)
Fractured block found during crash/instance recovery
Data in bad block -
 type: 2 format: 2 rdba: 0x00806eb5
 last change scn: 0x0000.0ee2f996 seq: 0x4 flg: 0x04
 consistency value in tail: 0xb6b10203
 check value in block header: 0xc807, computed block checksum: 0xf470
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x00806eb5 (file 2, block 28341) found same corrupted data
***
Corrupt block relative dba: 0x0781c0f4 (file 30, block 114932)
Fractured block found during crash/instance recovery
Data in bad block -
 type: 6 format: 2 rdba: 0x0781c0f4
 last change scn: 0x0000.0ee2f20c seq: 0x1 flg: 0x06
 consistency value in tail: 0xf8920601
 check value in block header: 0x2ee7, computed block checksum: 0xa9e
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0781c0f4 (file 30, block 114932) found same corrupted data
Mon Nov 21 21:24:04 2005
Recovery of Online Redo Log: Thread 1 Group 7 Seq 3623 Reading mem 0
Mon Nov 21 21:24:04 2005
Started recovery at
 Thread 1: logseq 3622, block 2578, scn 0.0
Mon Nov 21 21:24:04 2005
Recovery of Online Redo Log: Thread 1 Group 6 Seq 3622 Reading mem 0
  Mem# 0 errs 0: /u04/oradata/builder/redo06.log
  Mem# 1 errs 0: /u03/oradata/builder/redo16.log
***
Corrupt block relative dba: 0x00806eb5 (file 2, block 28341)
Fractured block found during crash/instance recovery
Data in bad block -
 type: 2 format: 2 rdba: 0x00806eb5
 last change scn: 0x0000.0ee2f996 seq: 0x4 flg: 0x04
 consistency value in tail: 0xb6b10203
 check value in block header: 0xc807, computed block checksum: 0xf470
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x00806eb5 (file 2, block 28341) found same corrupted data
***
Corrupt block relative dba: 0x0781c0f4 (file 30, block 114932)
Fractured block found during crash/instance recovery
Data in bad block -
 type: 6 format: 2 rdba: 0x0781c0f4
 last change scn: 0x0000.0ee2f20c seq: 0x1 flg: 0x06
 consistency value in tail: 0xf8920601
 check value in block header: 0x2ee7, computed block checksum: 0xa9e
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0781c0f4 (file 30, block 114932) found same corrupted data
Mon Nov 21 21:24:04 2005
Recovery of Online Redo Log: Thread 1 Group 7 Seq 3623 Reading mem 0
  Mem# 0 errs 0: /u03/oradata/builder/redo07.log
  Mem# 1 errs 0: /u04/oradata/builder/redo17.log
Mon Nov 21 21:24:04 2005
Completed redo application
Mon Nov 21 21:24:04 2005
Ended recovery at
 Thread 1: logseq 3623, block 1938, scn 0.249780245
 764 data blocks read, 745 data blocks written, 9597 redo blocks read
Crash recovery completed successfully

A la 2ème panne, survenue le lendemain, les choses se sont moins bien passées puisque cette fois un fichier de redolog a été corrompu, et son archive perdue lors de la panne. La base a donc été entièrement restaurée à l'aide de RMAN et ouverte en mode resetlogs.

Aujourd'hui, on m'a signalé que des erreurs avaient été trouvés dans des logs applicatifs, qui concernent justement le bloc 114932 du fichier 30, qui était concerné par la corruption suite à la 1ère panne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
java.sql.SQLException: ORA-01578: ORACLE data block corrupted (file # 30, block # 114932)
ORA-01110: data file 30: '/u01/oradata/builder/lm_big_index05.dbf'

Que faire pour résoudre le problème maintenant ?

Merci de votre aide

**thomasjcj** · 28/11/2005, 14h03

Apparament, ce n'est qu'un index, donc il suffit de drop l'index correspondant et de le recreer.
ensuite fait un ANALYZE INDEX... pour controller

**zestrellita** · 28/11/2005, 14h10

Merci thomasjcj, c'est un peu ce que je pensais. Mais quand je regarde la liste de mes index, je n'en vois aucun invalide. Est-ce qu'il y a un moyen de savoir à quoi correspond ce bloc ?

**thomasjcj** · 28/11/2005, 14h16

regarde la note 28814.1 sur Metalink, il y a tout sur le probleme de corruption de fichier, avec les requetes te permettant d'identifier les objets duis les numeros de blocs.

**zestrellita** · 28/11/2005, 14h19

Merci beaucoup, je regarde ça tout de suite !

**ducho** · 28/11/2005, 14h34

bonjour,

dans la note préciséee plus haut, tu as cette requête qui te donne les infos :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
SQL> select segment_name,segment_type from dba_extents where file_id=11 and 133 between block_id and (block_id+blocks-1);
 
SEGMENT_NAME
--------------------------------------------------------------------------------
 
SEGMENT_TYPE
------------------
ATELIERS_NIVEAU_FK
INDEX

11 est le numéro du fichier ( file#) de la table v$datafile
133 est le numéro du bloc corrompu donné par oracle .

cdlt

**LeoAnderson** · 28/11/2005, 14h57

J'en profite pour rappeller un outil trop souvent oublié : dbv qui permet de vérifier l'intégrité de chaque bloc d'un Dbf.... ;-)

**zestrellita** · 28/11/2005, 15h27

Merci à vous, vous m'aidez bien

Concernant dbv, j'y ai pensé en 1er, mais je ne l'ai jamais utilisé et il semble qu'il ne s'utilise que offline

J'ai testé sur des bases de test online et offline et j'obtiens systématiquement les erreurs suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Page 2539 is marked corrupt
***
Corrupt block relative dba: 0x000009eb (file 0, block 2539)
Bad header found during dbv:
Data in bad block -
 type: 182 format: 1 rdba: 0x0dc30400
 last change scn: 0x4480.0206172e seq: 0xb6 flg: 0x01
 consistency value in tail: 0x60cf0602
 check value in block header: 0x4d, block checksum disabled
 spare1: 0x4e, spare2: 0x0, spare3: 0x400
***
 
Page 2540 is marked corrupt
***
Corrupt block relative dba: 0x000009ec (file 0, block 2540)
Bad header found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0x0380027b
 last change scn: 0x0000.08ec60cf seq: 0x2 flg: 0x04
 consistency value in tail: 0x44800206
 check value in block header: 0xf80c, computed block checksum: 0x5ba4
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
..................................................

Pour l'instant, j'ai réussi à localiser plus précisément le bloc corrompu : il s'agit bien d'un index (ni clé primaire, ni contrainte), mais j'hésite à le supprimer pour le recréer alors que la base est disponible...

A noter que les blocs corrompus sont également visibles dans la vue SYS v$database_block_corruption

**LeoAnderson** · 28/11/2005, 15h39

Vous avez 2 blocs HS, pas un seul.
Si c'est un index incriminé, faites une requete qui nécessite de parcourir l'intégralité de l'index pour vous rendre compte que ça marchera pas !

La base est dispo, certes, mais parce que vous n'utilisez pas encore les données corrompues !

**zestrellita** · 28/11/2005, 15h41

Non non, l'exemple que j'ai mis pour le dbv correspond à une base de test, et il ne fait pas ça pour 2 blocs, mais pour tous les blocs.
Je pense donc que je n'utilise pas dbv comme il faut.

**LeoAnderson** · 28/11/2005, 15h52

Concernant l'utilisation de dbv : http://download-uk.oracle.com/docs/c...y.htm#SUTIL013

Concernant votre problème, n'ayez pas de scrupules à supprimer/recréer l'index, il est HS et ne peut que vous posez des problèmes ! ;-)

**zestrellita** · 28/11/2005, 16h44

Oui, pour dbv, je fais bien ce qui est indiqué, je ne comprends pas pourquoi ça ne marche pas

Sinon j'ai supprimé et recréé l'index, mais je vois toujours le bloc corrompu dans la vue v$database_block_corruption

**ducho** · 28/11/2005, 17h04

bonsoir,

cette vue amenée avec la v9 enregistre les blocs corrompus de la
base .
elle n' est mise à jour qu' apres un autre backup avec rman :

In Oracle9i and beyond you can query the view name V$DATABASE_BLOCK_CORRUPTION
to determine what corruption, if any, was found by RMAN. As in Oracle8i,
corruptions found are NOT reported back to the RMAN interface.

Note that corruption reported in V$DATABASE_BLOCK_CORRUPTION is cleared with each
RMAN backup validate run. If new corruption is found this view is updated with
the new corruption details. All rows in this view are not removed until another
RMAN backup validate is run AND during which no corruption was detected. To
understand what is reported in this view, see the description of the view as
shown in the manual titled Oracle9i Database Reference.

cdlt