Discussion :

[Scregneugneuu]

Bonjour,

Il y a de la corruption sur une base de données de plusieurs tera, en checkant la table "suspect_pages", j'ai pu constater qu'il s'agissait de page système :

• 106 pages PFS :
• 6 pages GAM
• 6 pages SGAM
• 6 pages DIFF MAP
• 6 pages ML MAP

Elles ont toutes l'ID 1, qui correspond à cela d'après la doc Microsoft : Erreur 823 provoquée par une erreur CRC du système d'exploitation ou erreur 824 autre qu'une somme de contrôle incorrecte ou une page endommagée (par exemple, ID de page incorrect)

Nous avons restauré un backup de la base sur un autre environnement et sur ce dernier, il n'y avait plus de problème avec les pages. J'ai lancé un DBCC CHECKDB pour valider, il ne semblait plus y avoir une seule page corrompu, pourtant le backup utilisé est un backup qui a été fait alors que le problème était déjà présent sur la base source.
J'ai recherché un peu sur internet, mais je n'ai pas trouvé comment une restauration peut corriger ce problème, auriez-vous une explication ?

Je me dis que lors de la restauration, SQL Server refait les entête des pages et donc elles pointent vers les bons endroits (par exemple)
Je ne suis pas sur de cette explications, donc je viens vers vous

D'ailleurs, lorsque l'on a ce genre de corruption, je ne sais pas s'il y a d'autres solutions que la restauration ? Un emptyfile par exemple, pour que les entêtes des pages soient recrées ?
Si la restauration corrige le problème, il y a peut-être une commande qui permet de corriger cela sans faire de restauration ?
Un DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS par exemple, mais aucune données serait perdues car seulement les entêtes des pages systèmes seraient reconstruit ?

Par avance, je vous remercie pour vos réponses

Cordialement,
Donovan

[SQLpro]

Oui, la restauration recalcule les pages systèmes.

Le principe de sauvegarde de MS SQL Server est le suivant : lecture des pages des tables systèmes (metadonnées) et stockage de celles-ci dans le fichier de sauvegarde. Puis stockage de toutes les pages des tables des utilisateurs. Puis stockage de la partie de journal pour les transactions ayant eu lieu depuis le démarrage de la sauvegarde.
Lors de la restauration il y a lecture des tables systèmes sysfiles, sysfilegroups... pour créer les fichiers vides. Puis placement des pages dans les fichiers vides et recalcule des pages techniques. Puis exécution des dernières transactions.

C'est pourquoi vos pages corrompues ont été reconstruites.

Le fait que vous n'ayez pas vu de corruption sur autre chose que des pages techniques m'intrigue.... Peut être n'y a t-il pas de CHECKSUM oui TORN activé dans votre base ?

Enfin, oui, il est possible de restaurer certaines pages en faisant un RESTORE DATABASE/LOG ... PAGE = ...

Code :

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

1
2
3
4
5
6
7
8
9
--To Restore Specific Pages:
RESTORE DATABASE { database_name | @database_name_var }
   PAGE = 'file:page [ ,...n ]'
 [ , <file_or_filegroups> ] [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
       NORECOVERY
      [ , <general_WITH_options> [ ,...n ] ]
[;]

https://docs.microsoft.com/fr-fr/sql...l-server-ver15

A +

[Scregneugneuu]

Merci pour le retour et les précisions sur le fonctionnement du backup/restau, c'est intéressant à savoir

Je ne connaissais pas ces paramètres de vérification des pages pour les bases, j'ai vérifié et dans "Recovery -> Page Verify" de la base, il y a bien CHECKSUM.

Cette corruption semble être apparu après une tentative de déplacement du fichier sur un autre disque. Il y a eu copie du fichier, la base ne voulait pas démarrer et donc ils ont remis l'ancien fichier et la base a redémarré, mais en checkant, on a constaté de la corruption sur des pages systèmes.
N'étant pas présent lorsque le déplacement a voulu être fait, je ne sais pas tout ce qui a pu être fait, je souhaite donc corriger cette corruption avant d'aller plus loin.

La restauration complète ou du fichier impacté semble être une bonne solution pour corriger les pages systèmes et je n'ai pas trouvé d'autres solutions "miracle" en fouillant un peu partout sur internet.

Cordialement,
Donovan