Analyse du résultat du CheckDB : identification des données concernées

Analyse du résultat du CheckDB

Voyons maintenant d’un peu plus près le résultat du CheckDB, et tâchons d’identifier les données concernées par la corruption. Premièrement le résultat du CheckDB nous apprend qu’une seule page de données a été corrompue : (type In-row data): Page (1:6196). En effet, on retrouve le même ID de page (surligné en jaune), et l’on sait que c’est une page de données car elle est de type « In-row-data ». Mais ce n’est pas tout. Une autre page semble poser problème : off-row data node at page (1:306651). Cette page quant à elle ne contient pas de données à proprement parler, mais du BLOB. En effet, elle est de type « LOB Data) et est « off-row ». Le message d’erreur Msg 8964, Level 16, State 1, Line 1 nous dit que le text ID xxxxx n’est pas référencé. Il faut savoir que les colonnes de types BLOB sont stockées dans des unités d’allocation « off row », dans des pages de type LOB.Les pages de données contiennent un pointeur qui pointe vers ces pages. Dans le cas présent, nous avons une page de données corrompue (1:6196), puis 4 erreurs concernant la même page LOB, pour laquelle la référence à la page source est perdue. Cela sous-entend que la page de données corrompue contenait 4 lignes, chaque ligne ayant un pointeur vers une donnée BLOB contenue dans la page 1:306651.

La page de données source étant désormais illisible, les pointeurs sont cassés d’où les erreurs concernant la page BLOB 1:306651. A priori, nous n’aurions donc finalement qu’un problème sur la page de données 1 :6196, concernant vraisemblablement que 4 enregistrements.

Correction

Notre base de données étant en mode simple, la restauration de la page est impossible. Elle ne fonctionne en effet que dans les modèles FULL et BULK-LOGGED. L’idée est donc de restaurer le backup, récupérer le contenu de la page dans la base ainsi restaurée, supprimer la page ID 1:6196 de la base corrompue puis ajouter les données récupérées.

Step 1 : restauration de la base et récupération des données de la page

En s’appuyant sur un ancien backup, nous restaurons une base propre, nommée ici BaseOK. Un p’tit checkDB nous confirme que cette base est propre. Nous allons afficher le contenu de la page grâce à la commande DBCC PAGE.

L’activation du traceflag 3604 permet de renvoyer le résultat du DBCC PAGE directement sur la console.

DBCC TRACEON (3604)

DBCC PAGE (BaseOK,1,6196,3)

Nous avons tout d’abord l’entête de la page, qui nous donne pas mal d’informations sur le contenu de la page, mais dans notre cas, nous allons surtout nous arrêter sur les champs suivants :

• Confirmation de Object ID 1333579789

• M_type = 1 : c’est une page de donnée (2 = index,3=text

mix page, 8,9,10,11 pages systèmes etc…)

• m_slotCnt= 4 : nombre d’enregistrements contenu dans la page : nous confirmons la supposition faite plus tôt.

(((IMG7317)))

Après l’entête, vient le contenu de la page à proprement parler.

(((IMG7319)))

Le mot clé SLOT permet d’identifier le n° de l’enregistrement dans la page.

(((IMG7320)))

(((IMG7321)))

(((IMG7322)))

(((IMG7323)))

Nous devons donc retrouver les 4 enregistrements de la page. L’important ici va être de connaître la clé identifiant les lignes dans la table. En effet, nous allons voir que nous pouvons récupérer dans la page l’ensemble des valeurs des colonnes, mais cette recherche est quand même fastidieuse. Le plus simple est de chercher seulement les valeurs de clé, puis de faire un SELECT de ces valeurs dans la table pour récupérer les autres colonnes. Dans notre cas, notre clé est composée du champ « ID » detype INT et du champ LoadingID du type UniqueIdentifier. Nous devons donc trouver 4 valeurs d’ID / LoadingID dans la page : voir figure 3. Nous avons bien récupéré nos 4 valeurs de clé. Il nous reste à faire un SELECTdans la table de la base restaurée pour récupérer les lignes complètes : voir figure 4. Et voilà nos quatre enregistrements. Nous savons maintenant quelle étaient les données contenues dans la page corrompue.

(((IMG7324)))

La partie 2 de cet article sera publiée le mois prochain.