Discussion :

[dbaffaleuf]

Y a-t-il des messages en provenance du contrôleur disques dans le journal d'évènements ? Si je comprends bien la cinématique:

- Base SUSPECT.
- SET EMERGENCY
- SET SINGLE_USER
- DBCC CHECKDB ('REPAIR_ALLOW_DATA_LOSS') -> doit reconstruire le journal.
- base ONLINE
- Nouveau DBCC CHECKDB -> nouvelle corruption au même endroit ?

[mikedavem]

Yes, c'est ce que j'ai tenté de lui faire faire. Et d'après ce que je vois dans le fichier log c'est toujours au même endroit.

Seulement je trouve bizarre d'avoir une erreur sur le journal et un CHECKDB qui se termine de façon anormale.

++

[bribou]

Bonjour,
J'ai pu detacher la base mais je ne peux pas la re-attacher. J'obtiens le message suivant:


Msg 824, Level 24, State 2, Procedure sp_MScleandbobjectsforreplication, Line 33
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x348ec1e4; actual: 0x348ec1e0). It occurred during a read of page (1:24) in database ID 8 at offset 0x00000000030000 in file 'E:\mssql\data\eta_util_data1.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

[mikedavem]

Il faut la reattacher sans le fichier journal.

Renommer votre fichier journal et reessayez de reattacher votre base juste avec le fichier de donnees.

Au passage avez vous fait un chkdsk de votre disque ?

++

[dbaffaleuf]

Je ne suis pas sûr que le rattachement soit possible, dans la mesure ou un checksum est invalide dans la page 1:24, même en forçant la recréation du journal. Ca vaut le coup d'essayer, mais si le CREATE DATABASE FOR ATTACH plante avec la même erreur, il faudra utiliser le hack de Paul Randal pour ramener la base suspecte ONLINE (http://www.sqlskills.com/BLOGS/PAUL/post/TechEd-Demo-Creating-detaching-re-attaching-and-fixing-a-suspect-database.asp). Le principe est de
1) faire une copie des fichiers initiaux de la base ETA_UTIL (ceux qu'on ne peut plus rattacher). Puis les suprimer (bien vérifier que la copie est OK surtout).
2) Recréer une base ETA_UTIL avec les mêmes noms de fichiers.
3) Stopper l'instance et supprimer les nouveaux fichiers créés, pour les remplacer par les deux fichiers corrompus copiés à l'étape 1.
4) Relancer SQL Server, il va ramener la base en ligne à l'état SUSPECT. Et là on peut repasser la base en EMERGENCY pour sortir les données à la main par BCP out ou retenter un REPAIR_ALLOW_DATA_LOSS.

[mikedavem]

En fait je voulais en venir a la. Voir si le pb ne vient pas surtout du fichier de des transactions. L'option REPAIR_ALLOW_DATA_LOSS reconstruit effectivement le journal en mode EMERGENCY mais je ne sais pas si celui-ci se sert du meme fichier (meme container) ou il en cree un nouveau. Le fait de reattacher avec le fichier de donnees seul permettrait de creer un nouveau container a un autre endroit du disque (des fois que les clusters du disque ne soient pas integres).

Dans un deuxieme temps je voulais lui faire tenter le fameux hack. Tu m'as devance :-)

++

[bribou]

Je l'ai re-attachee avec un CREATE DATABASE .. FOR ATTACH. La commande s'executee sans erreur.
Toutefois, j'ai toujours cette meme erreur qui mentionne une erreur de checksum sur le fichier PRIMARY. Cette erreur affecte problablement les tables systemes et je suppose que c'est pour cela que je ne vois plus les tables utilisateur.

[dbaffaleuf]

Cette erreur affecte problablement les tables systemes et je suppose que c'est pour cela que je ne vois plus les tables utilisateur.

C'est très possible, chez moi (build 9.0.4035), 1:24 correspond à une page de sysobjvalues.

[dbaffaleuf]

Dans un deuxieme temps je voulais lui faire tenter le fameux hack. Tu m'as devance :-)++

Désolé

[mikedavem]

Désolé

Pas de souci.

[mikedavem]

On pourrait avoir (si c'est possible et que ca ne ramene pas d'erreur) le detail de cette fameuse page :

Code :

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

1
2
3
DBCC TRACEON(3604);
GO
DBCC PAGE('mabase', 1, 24, 3)

++

[bribou]

Voir le fichier ci-apres.

[mikedavem]

Perso je dois admettre que ca va etre dur de recuperer votre page si vous avez une erreur 824 (erreur logique)

Vous pouvez bien tenter un autre DBCC avec l'option de reparation mais je pense que la ca va etre dur.

A tout hasard vous pouvez voir si vous n'avez pas des informations concernan les erreurs logiques sur vos pages. La c'est la page 24 qui est touchee mais cela peut cacher d'autres problemes egalement.
Quoi qu'il en soit vous avez interet a regarder vos disques car ils sont tres probablement a l'origine du probleme.

Code :

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

1
2
3
SELECT * FROM msdb..suspect_pages
   WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);
GO

++

[dbaffaleuf]

Il n'y a vraiment pas moyen de faire des bcp out des tables de la base endommagée en mode emergency ?

Code :

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

select 'bcp ETA_UTIL..'+name+' out '+name+'.bcp -c -T -S <instancename>'  from sys.tables where name <> 'sys%'

[mikedavem]

Si tu as raison David mais encore faut il avoir acces aux tables ... dans le cas present je doute qu'il puisse faire cela ... mais pourquoi pas le tenter c'est vrai.

++

[bribou]

Il y a effectivement 2 pages suspectes (24 et 2672).
L'acces a sys.tables ne marche pas (renvoie l'erreur de checksum sur la page 24).
Il y a effectivement eu une serie d'erreurs disque sur la baie qui est a l'origine de la corruption de la BD.

Je pense qu'on peut s'arreter la. Je vais reconstruire la BD from scratch...
Je vous remercie beaucoup pour votre aide et le temps que vous avez passe.

Brigitte

[mikedavem]

Pensez a faire des backups. Cela pourra vous servir la prochaine fois

++

[dbaffaleuf]

+1. Le backup c'est la clé. Bon courage A+

[SQLpro]

S'il a une réplication, il faudrait déjà l'arrêter et tenter de savoir si les données sont correctes dans les bases d'origines afin de pouvoir reconstituer les données..... ou tenter de .....

A +