Détection de la corruption avec CHECKDB

Commande DBCC CHECKDB

Le seul moyen de s’assurer de l’intégrité d’une base de données est d’utiliser la commande DBCC CHECKDB. En deux mots, cette commande va vérifier l’intégrité physique et logique de l’ensemble de la base de données et remonter les éventuelles erreurs rencontrées. Je vous invite à consulter l’aide en ligne pour en connaître les détails. Voici ce que cela donne sur notre base :

DBCC CHECKDB (baseKO) WITH NO_INFOMSGS;

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).

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).

CHECKDB found 0 allocation errors and 2 consistency errors not

associated with any single object.

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.

CHECKDB found 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’.

repair_allow_data_loss is the minimum repair level for the

errors found by DBCC CHECKDB (BaseKO).

 La commande liste les erreurs puis affiche une synthèse comprenant le nombre d’allocation errors et le nombre de consistency errors. Le résultat affiche également le niveau minimum de réparation à utiliser (cf aide en ligne), repair_allow_data_loss dans le cas présent. Attention, l’utilisation de ce niveau de réparation supprime purement et simplement les pages corrompues, entrainant une perte de données, non quantifiable à ce stade. Son éventuelle utilisation ne doit se faire que dans un second temps, une fois que l’on a bien identifié les données concernées. A partir du moment où nous avons des « consistency errors » concernant des pages de données, nous devrons nous appuyer sur un Backup de la base pour récupérer les données. Impossible de corriger une page de données corrompue, seul le backup pourra nous tirer d’affaires.

Commande DBCC CHECKDB

Le seul moyen de s’assurer de l’intégrité d’une base de données est d’utiliser la commande DBCC CHECKDB. En deux mots, cette commande va vérifier l’intégrité physique et logique de l’ensemble de la base de données et remonter les éventuelles erreurs rencontrées. Je vous invite à consulter l’aide en ligne pour en connaître les détails. Voici ce que cela donne sur notre base :

DBCC CHECKDB (baseKO) WITH NO_INFOMSGS;

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).

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).

CHECKDB found 0 allocation errors and 2 consistency errors not

associated with any single object.

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.

CHECKDB found 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’.

repair_allow_data_loss is the minimum repair level for the

errors found by DBCC CHECKDB (BaseKO).

 La commande liste les erreurs puis affiche une synthèse comprenant le nombre d’allocation errors et le nombre de consistency errors. Le résultat affiche également le niveau minimum de réparation à utiliser (cf aide en ligne), repair_allow_data_loss dans le cas présent. Attention, l’utilisation de ce niveau de réparation supprime purement et simplement les pages corrompues, entrainant une perte de données, non quantifiable à ce stade. Son éventuelle utilisation ne doit se faire que dans un second temps, une fois que l’on a bien identifié les données concernées. A partir du moment où nous avons des « consistency errors » concernant des pages de données, nous devrons nous appuyer sur un Backup de la base pour récupérer les données. Impossible de corriger une page de données corrompue, seul le backup pourra nous tirer d’affaires.

Commande DBCC CHECKDB

Le seul moyen de s’assurer de l’intégrité d’une base de données est d’utiliser la commande DBCC CHECKDB. En deux mots, cette commande va vérifier l’intégrité physique et logique de l’ensemble de la base de données et remonter les éventuelles erreurs rencontrées. Je vous invite à consulter l’aide en ligne pour en connaître les détails. Voici ce que cela donne sur notre base :

DBCC CHECKDB (baseKO) WITH NO_INFOMSGS;

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).

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).

CHECKDB found 0 allocation errors and 2 consistency errors not

associated with any single object.

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.

CHECKDB found 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’.

repair_allow_data_loss is the minimum repair level for the

errors found by DBCC CHECKDB (BaseKO).

 La commande liste les erreurs puis affiche une synthèse comprenant le nombre d’allocation errors et le nombre de consistency errors. Le résultat affiche également le niveau minimum de réparation à utiliser (cf aide en ligne), repair_allow_data_loss dans le cas présent. Attention, l’utilisation de ce niveau de réparation supprime purement et simplement les pages corrompues, entrainant une perte de données, non quantifiable à ce stade. Son éventuelle utilisation ne doit se faire que dans un second temps, une fois que l’on a bien identifié les données concernées. A partir du moment où nous avons des « consistency errors » concernant des pages de données, nous devrons nous appuyer sur un Backup de la base pour récupérer les données. Impossible de corriger une page de données corrompue, seul le backup pourra nous tirer d’affaires.