Discussion :

[Blacknounou]

Bonjour,

J'ai effectué un DBCC CHECKDB sur l'une de mes bases SQL 2000.

Et j'ai eu cette erreur :

I/O error (bad page ID) detected during read at offset 0x0000000398000 in file
'C:\Datas\MSSQL\MSSQL$Paris\LOG\xxxx.mdf'.

J'ai aussi exécuté un SELECT sur la table et j'ai la même erreur.

Pourriez-vous m'aider ?

Merci d'avance.

[dbaffaleuf]

Il faut regarder dans le journal des évènements windows la trace d'erreurs matérielles, pb disque, etc... et te préparer à restaurer tes backups. Une erreur 823 vient à 99.9% d'un problème disque ou contrôleur.

Peux-tu renvoyer la sortie complète de

Code :

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

1
2
DBCC CHECKDB('<mabase>') WITH ALL_ERRORMSGS, NO_INFOMSGS
GO

[Blacknounou]

Voici le résultat du :

Code :

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

DBCC CHECKDB (chantier) WITH ALL_ERRORMSGS, NO_INFOMSGS

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Msg*8909, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 0, index ID*=*0, page ID = (1:22988). ID de page de l'en-tête de page = (0:0).
CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence non associées à un quelconque objet unique.
Msg*8928, Niveau*16, État*1, Ligne*1
Objet ID = 574885365, index ID = 0 : La page (1:22988) ne peut pas être traitée. Pour plus d'informations, consultez les autres erreurs.
Msg*8976, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. Page (1:22988) n'a pas été trouvé dans l'analyse bien que ses parents (1:22930) et (1:22987) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Msg*8978, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. La page (1:22989) n'a pas de référence dans la page précédente (1:22988). Possibilité d'un problème de liaison de chaîne.
CHECKDB a trouvé 0 erreurs d'allocation et 3 erreurs de cohérence dans la table 'Circulaires' (objet ID = 574885365).
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la base de données 'chantier'.
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKDB (chantier ).

[dbaffaleuf]

OK. Donc une fois le problème racine identifié et corrigé , l'ultime solution reste de restaurer un backup. Surtout ne pas être tenté de détacher la base. Il faut faire un état des lieux de tes backups:

- As-tu seulement un backup complet valide de la base ? Peux-tu le restaurer qq part pour t'en assurer ?
- Quel est le mode de récupération de la base (select databasepropertyex('chantier')) ?
- Si elle est en mode FULL, as-tu des backups de journaux qui pourraient te permettre de revenir au point de crash ? Il faut être sûr de tout avoir sous la main car lorsque le tail-log backup est effectué, il n'y a plus de retour arrière. On est obligé de restaurer.
- Si elle est en mode SIMPLE, as-tu des backups différentiels pour revenir au plus près du point de crash ?
- Est-ce que tu exécutes régulièrement un DBCC CHECKDB('chantier') ? Si tu ne le lances jamais, il peut être difficile de savoir de quand date le dernier backup valide.

Si tu as une solution de backup valide et que ta base est en mode de récupération FULL:
1) Fermer les connexions à la base.
2) Faire un tail-log backup:

Code :

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

backup log chantier to disk='...'  WITH NO_TRUNCATE, NORECOVERY, STATS, INIT

3) Restaurer tes backups en commençant par la dernière complète en WITH NORECOVERY.Si tu as d'autres backups transactionnels les rejouer dans l'ordre jusqu'au dernier, toujours en WITH NORECOVERY.
4) Restaurer le backup TAIL-LOG pris à l'étape 2) en WITH RECOVERY

Si tu as un backup valide et que la base est en mode SIMPLE:
1) Fermer les connexions à la base.
2) Restaurer le dernier backup complet valide.
3) Si tu as un backup différentiel à suivre, il faut restaurer la complète en WITH NORECOVERY suivie de la différentielle en WITH RECOVERY. Si tu n'as pas de backup différentiel à suivre, il faut juste remonter le backup complet en WITH RECOVERY.


J'insiste sur le fait qu'avant de faire tout ça, il faut assainir la partie matérielle. Ca ne sert à rien de restaurer une sauvegarde sur un sous-système IO qui bagotte. Tu peux peut-être te faire aider par un admin système ou stockage pour détecter une erreur système de ce côté-là

[Blacknounou]

Malheureusement, le client n'a aucun Backup valide à me proposer.

Nous avons essayé de restaurer un backup sur un autre serveur et l'erreur réapparaissait.

Y-a-t-il une autre solution ?

[Blacknounou]

Sinon, comment pourrais-je cibler la ou les lignes corrompues, pour pouvoir la ou les supprimer?