> Tech > Corruption de données : un cas concret (partie 2)

Corruption de données : un cas concret (partie 2)

Tech - Par Olivier Maître - Publié le 05 mars 2015
email

La corruption de données est la hantise de tous les DBA. Elle peut être lourde de conséquences, et complexe à traiter.

Corruption de données : un cas concret (partie 2)

Le checkDB nous reporte également les quatre erreurs suivantes (voir première partie ici):

Msg 8928, Level 16, State 1, Line 1

Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057654272 (type In-row data): Page (1:6196) could not be processed. See other errors for details.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 86, text ID 40341078016 is not referenced.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 87, text ID 40341143552 is not referenced.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 88, text ID 40341209088 is not referenced.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 89, text ID 40341274624 is not referenced.

Quatre enregistrements sont donc orphelins, du fait, nous l’avons vu, de la corruption de la page de donnée source 1:6196. Le message d’erreur nous dit également que ces quatre enregistrements sont identifiés dans la page 1:306651, par les numéros de slot 86, 87, 88 et 89. Le pointeur qui lie les pages de data (type=1) et les pages BLOB (type=3) n’est pas bi directionnel, c’est-à-dire qu’à partir de la page de données, les champs « TextTimeStamp = 40341078016 RowId = (1:306651:86) » permettent effectivement d’identifier l’enregistrement blob correspondant, par contre, à partir de la page blob, aucune référence n’est faite vers la page source. Dans notre exemple : voir figure 1.

(((IMG7461)))

Si l’on regarde le contenu de la page correspondante : 1 :306651 : voir figure 2. On retrouve bien notre enregistrement, mais impossible d’identifier la page source depuis cette page blob. Comment le CheckDB a-t-il donc identifié que les Slot 86, 87, 88 et 89 était orphelins, sachant qu’il n’a pas pu accéder à la page de données et ainsi suivre le pointeur ? Et bien en faisant un scan de toutes les pages. En effet, le checkDB découpe ces traitements en batch. Lorsqu’un de ces batchs contient une page LOB, pour chaque enregistrement de la page, il rescan l’intégralité des pages contenu dans son batch pour trouver la page source correspondante, c’est-àdire contenant le pointeur vers la page LOB. C’est pourquoi le checkDB est extrêmement long sur une table qui contient des données LOB. Mais cela signifie également que dans le cas présent, nous n’avons aucune correction à apporter sur cette page. Le simple fait de remettre la page de data source aura pour effet de corriger la situation.

(((IMG7462)))

Step 2 : retour à la base corrompue : désallocation de la page corrompue

Nous avons identifié les enregistrements contenus dans la page corrompue 1:6196, et nous savons que la page 1:306651 ne nous posera pas de problème. Nous pouvons donc maintenant faire un CHECKDB REPAIR_ALLOW_ DATA_LOSS qui aura pour effet de désallouer la page 6196. Attention à l’utilisation de cette option du checkDB. En effet, nous n’avons pas le contrôle absolu sur les actions qu’elle peut mener et sur les pages qu’elle peut désallouer. A utiliser donc en dernier recours, et préférer une restauration de base si l’on à le choix entre les deux solutions.

ALTER DATABASE BaseKO SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

GO

DBCC CHECKDB (baseKO, REPAIR_ALLOW_DATA_LOSS) WITH NO_ INFOMSGS;

GO

ALTER DATABASE BaseKO SET MULTI_USER;

GO

Nonqualified transactions are being rolled back. Estimated rollback completion: 0%.

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

Msg 8909, Level 16, State 1, Line 1

Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 20547866576748544 (type Unknown), page ID (1:6196) contains an incorrect page ID in its page header. The PageId in the page header = (55:3276845).

The error has been repaired.

Msg 8909, Level 16, State 1, Line 1

Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 20547866576748544 (type Unknown), page ID (1:6196) contains an incorrect page ID in its page header. The PageId in the page header = (55:3276845).

The error has been repaired.

CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.

CHECKDB fixed 0 allocation errors and 2 consistency errors not associated with any single object.

Repair: The page (1:6196) has been deallocated from object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057654272 (type In-row data).

Repair: Deleted off-row data column with ID 40341078016, for object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data) on page (1:306651), slot 86.

Repair: Deleted off-row data column with ID 40341143552, for object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data) on page (1:306651), slot 87.

Repair: Deleted off-row data column with ID 40341209088, for object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data) on page (1:306651), slot 88.

Repair: Deleted off-row data column with ID 40341274624, for object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data) on page (1:306651), slot 89.

Msg 8928, Level 16, State 1, Line 1

Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057654272 (type In-row data): Page (1:6196) could not be processed. See other errors for details.

The error has been repaired.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 86, text ID 40341078016 is not referenced.

The error has been repaired.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 87, text ID 40341143552 is not referenced.

The error has been repaired.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 88, text ID 40341209088 is not referenced.

The error has been repaired.

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 1333579789, index ID 0, partition ID 72057594041335808, alloc unit ID 72057594057785344 (type LOB data). The off-row data node at page (1:306651), slot 89, text ID 40341274624 is not referenced.

The error has been repaired.

CHECKDB found 0 allocation errors and 5 consistency errors in table ‘Table1’ (object ID 1333579789).

CHECKDB fixed 0 allocation errors and 5 consistency errors in table ‘Table1’ (object ID 1333579789).

CHECKDB found 0 allocation errors and 7 consistency errors in database ‘BaseKO’.

CHECKDB fixed 0 allocation errors and 7 consistency errors in database ‘BaseKO’.

En substance, la page de données a bien été désallouée, tandis que les enregistrements blob orphelins ont été supprimés. Un nouveau DBCC CHECKDB nous confirme que la base ne contient plus d’erreur. Il ne nous reste plus alors qu’à réinsérer les données précédemment récupérées pour que ce problème de corruption soit définitivement réglé.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par Olivier Maître - Publié le 05 mars 2015