Discussion :

[remika]

ça me renvoie le nombre de lignes sans problème
et c'est le bon nombre

[bouyao]

Alors pas de panique.
Ca peut arriver qu'oracle regle tout seule certains problème de corruption.
(checksum)

[remika]

ok bon on va dire que ça remarche

je reposte dans ce sujet si ça recommence

[LeoAnderson]

Alors pas de panique.
Ca peut arriver qu'oracle regle tout seule certains problème de corruption.
(checksum)

Ok, il peut être capable de recalculer un checksum mais dans ce cas, pourquoi balancer une erreur si derrière on n'a rien à faire et que le problème est résolu ?
A la rigueur, qu'il génère une trace mais retourner une erreur ORA-xxx et planter la transaction, c'est moyen !

[bouyao]

Si oracle trouve un problème sur un bloc oracle, et n'a pas le temps de le resoudre alors il envoi un message d'erreur et suivant certains parametres d'initialition il crée un fichier trace.

Après il peut le resoudre en vérifiant le bloc dans d'autres endroits comme cache, redo, undo , …

J'ai fait certains testes en modifiant des blocs oracle par un editeur hex et le resultats que toutes mes modifications sont corrigés par oracle automatiquement, mais attention pas n'importe quelle bits.

j'a fait ses testes sur les blocs de données de table, index, fichier de contrôle.

[Jaouad]

Oracle a tout simplement "récuperer" l'erreur lors du premier DBV

[remika]

l'erreur est revenue avec un autre numéro de bloc

[remika]

j'ai relancé une requête seule et je n'ai aucun problème
on dirait que le problème revient quand je lance plusieurs requêtes simultanément

[bouyao]

DBV ne corrige pas le problème. En plus il ne voit pas certains bloc corrompu. (corruption logique).

EDIT: je viend de voir ton nouveau message.
On peut avoir le contenu de ton fichier alert.log (juste les dernieres lignes)

[remika]

comment le régler alors ?

[LeoAnderson]

Bon, là, il y a manifestement un GROS problème disque !

il faudrait

1. Arrêter la base
2. Faire une sauvegarde (c'est IMPERATIF !!)
3. S'assurer qu'il n'y a pas de virus sur la machine
4. Lancer des scandisk et autres outils de vérification minutieuses
5. Vérifier les contrôleurs SCSI et/ou RAID selon le cas

[remika]

ça se trouve où alert.log ?

[bouyao]

sous sql tu lance :

Code :

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

show parameter background_dump_dest

il va te donnait le repertoire du fichier alert<SID>.log

[remika]

le fichier alert donne plein de

***
Reread of rdba: 0x02c074a0 (file 11, block 29856) found same corrupted data
***
Corrupt block relative dba: 0x02c074a0 (file 11, block 29856)
Bad check value found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x02c074a0
last change scn: 0x0000.00da1fce seq: 0x1 flg: 0x04
consistency value in tail: 0x1fce0601
check value in block header: 0x74a5, computed block checksum: 0x8
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x02c074a0 (file 11, block 29856) found same corrupted data

les numéros de blocs ne sont pas tous les mêmes

[remika]

la sauvegarde est faite, pas de spyware, pas de virus, scan minutieux du disque au prochain redémarrage

[bouyao]

Ca peut venir s'il y'a beaucoup d' E/S et que le CPU de la machine n'est pas assez puissant.
pour resoudre ton problème tu peut desactiver db_block_checksum , juste dans ce cas

Code :

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

SQL> alter system set db_block_checksum = FALSE scope=both;

[remika]

pour le proc, c'est un Athlon 64 3500+
ça devrait pas être trop mal

[bouyao]

essaye comme même de changer ce parametre
et vérifie si ces problèmes perssistes.
A +.

bouyao