Checkdb erreur sur certaines tables

Version imprimable

01/06/2012, 11h53
Mothership

Checkdb erreur sur certaines tables

Bonjour,

Suite à un problème disque relativement impactant, nous avons rencontré plusieurs problèmes sur nos sgbd, notre base MSSQL étant la dernière à manifester ses problèmes. Après 7 jours de fonctionnement "normal", j'ai constaté tardivement des erreurs détectées lors du check sur la BD. Voici une petite partie, concernant une de nos tables impactées :

Citation:

Msg 8978, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). Une référence de la page précédente (5:2052218) est manquante à la page (3:1910329). Un problème de liaison de chaîne s'est peut-être produit.
Msg 8928, Level 16, State 1, Line 2
ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data)*: impossible de traiter la page (5:2052218). Pour plus d'informations, consultez les autres erreurs.
Msg 8943, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data), page (5:2052218). Échec du test (max <= m_freeData). Emplacement 0, la ligne s'étend dans l'espace libre à 0xc.
Msg 8976, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). La page (5:2052218) n'a pas été détectée lors de l'analyse alors que sa page parent (5:2052217) et les (5:2052216) pages précédentes la référencent. Vérifiez les erreurs précédentes.
Msg 8928, Level 16, State 1, Line 2
ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data)*: impossible de traiter la page (5:2052219). Pour plus d'informations, consultez les autres erreurs.
Msg 8943, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data), page (5:2052219). Échec du test (max <= m_freeData). Emplacement 0, la ligne s'étend dans l'espace libre à 0xb.
Msg 8976, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). La page (5:2052219) n'a pas été détectée lors de l'analyse alors que sa page parent (8:2613686) et les (1:3252821) pages précédentes la référencent. Vérifiez les erreurs précédentes.
Msg 8978, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). Une référence de la page précédente (5:2052219) est manquante à la page (5:2052220). Un problème de liaison de chaîne s'est peut-être produit.
Msg 8928, Level 16, State 1, Line 2
ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data)*: impossible de traiter la page (5:2052221). Pour plus d'informations, consultez les autres erreurs.
Msg 8976, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). La page (5:2052221) n'a pas été détectée lors de l'analyse alors que sa page parent (8:2613686) et les (5:2052220) pages précédentes la référencent. Vérifiez les erreurs précédentes.
Msg 8944, Level 16, State 12, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data), page (5:2052221), ligne 1. Échec du test (ColumnOffsets <= (nextRec - pRec)). Valeurs 257 et 209.
Msg 8944, Level 16, State 12, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data), page (5:2052221), ligne 1. Échec du test (ColumnOffsets <= (nextRec - pRec)). Valeurs 257 et 209.
Msg 8978, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 1, ID de partition 72057603499425792, ID d'unité d'allocation 72057603586129920 (type In-row data). Une référence de la page précédente (5:2052221) est manquante à la page (5:2052222). Un problème de liaison de chaîne s'est peut-être produit.
Msg 8978, Level 16, State 1, Line 2
Erreur de table*: ID d'objet 377481565, ID d'index 3, ID de partition 72057604608491520, ID d'unité d'allocation 72057604729077760 (type In-row data). Une référence de la page précédente (9:1733352) est manquante à la page (9:5827618). Un problème de liaison de chaîne s'est peut-être produit.
CHECKTABLE a trouvé 0 erreurs d'allocation et 14 erreurs de cohérence dans la table 'xxxxx.HLPRPLP' (ID d'objet 377481565).
repair_allow_data_loss est le niveau minimum de réparation pour les erreurs trouvées par DBCC CHECKTABLE (RFXCOOPPROD.xxxxx.HLPRPLP).

Donc pas mal de choses, le problème commence a être critique, des jobs fonctionnels tombent en erreurs mais aussi tehcnique puisque la sauvegarde des journaux de transactions elle aussi n'arrive plus à se terminer (comme celle la complète d'hier soir d'ailleurs).

Après avoir lu pas mal de site web, plusieurs options :
La restauration d'une page : Oui mais les données ont plus que changées depuis 7 jours, cela parait très difficile de repartir avec les données si lointaine.
L'utilisation des commandes CHECKTABLE/DB avec les options REPAIR : Oui mais devra se faire base non utilisée et la possibilité de perdre des données me rebute pour le moment.
Ce sont les deux options principale, j'ai pu voir aussi

Dans le cadre de manipulation au sein de la base, est-il possible de récupérer les données dans une table temporaire ou quelque chose d'approchant ?

Je suis ouvert à toutes informations ou idées :)
01/06/2012, 21h32
elsuket

Bonjour,

Citation:

repair_allow_data_loss est le niveau minimum de réparation pour les erreurs trouvées par DBCC CHECKTABLE (RFXCOOPPROD.xxxxx.HLPRPLP).

:aie: Il faut aussi avoir à éliminer la corruption au niveau des disques (c'est souvent mais pas toujours la source du problème que vous rencontrez).

Vous pouvez trouver le nom de la table en question en exécutant SELECT OBJECT_NAME(377481565).

Ensuite c'est l'index cluster de cette table qui est touché (ID d'index 1), donc vous pouvez tenter de reconstruire cet index (faites le OFFLINE si vous êtes sous SQL Server 2005 ou 2008) sur un fichier différent, stocké sur un disque physiquement distinct de celui qui supporte le fichier actuel.

Quand ce sont les index non-cluster, on peut tenter de les reconstruire directement, mais toujours OFFLINE.

Citation:

La restauration d'une page : Oui mais les données ont plus que changées depuis 7 jours, cela parait très difficile de repartir avec les données si lointaine.

Là par contre il s'agit plutôt d'un manque de maintenance : la corruption est révélée par les journaux d'erreur de SQL Server, ou par les erreurs à l'accès des pages requises par l'application appelante. Encore faut il que les premiers soient revus, et que les secondes soient journalisées et revues :)
Donc vous auriez pu vous en sortir par la restauration de la sauvegarde complète la plus récente + RESTORE DATABASE ... PAGE.

Citation:

Dans le cadre de manipulation au sein de la base, est-il possible de récupérer les données dans une table temporaire ou quelque chose d'approchant ?

Non, la page est corrompue; donc à la lecture de celle(s)-ci, vous obtiendrez les mêmes problèmes qu'avec vos jobs ou vous applications.

Si la reconstruction d'index ne marche pas (pensez bien à la valider avec un DBCC CHECKTABLE), vous devrez passer à un DBCC CHECKDB avec l'option REPAIR_REBUILD.
Si vous avez de la chance, ça marchera; sinon, vous devrez changer par l'option REPAIR_ALLOW_DATA_LOSS dont le nom est explicite :)
Enfin l'option REPAIR_FAST ne fait rien.

Notez qu'une bonne partie des instructions DBCC viennent avec une option non documentée : WITH TABLERESULTS.
02/06/2012, 09h19
mikedavem

Citation:

Ensuite c'est l'index cluster de cette table qui est touché (ID d'index 1), donc vous pouvez tenter de reconstruire cet index (faites le OFFLINE si vous êtes sous SQL Server 2005 ou 2008) sur un fichier différent, stocké sur un disque physiquement distinct de celui qui supporte le fichier actuel.

L'index 1 correspond directement aux données de la table. La reconstruction ne changera rien. Dans ce cas il faut jouer avec une restauration de pages + journal ou utiliser l'option de réparation avec perte de données de la commande DBCC CHECKDB.

Citation:

Après avoir lu pas mal de site web, plusieurs options :
La restauration d'une page : Oui mais les données ont plus que changées depuis 7 jours, cela parait très difficile de repartir avec les données si lointaine.

Si vous avez les backups nécessaires (j'insiste bien sur ce fait) alors il n'est pas impossible de revenir à un état stable. Le travail peut être long en effet mais c'est le seul moyen de pouvoir restaurer avec le moins de perte possible.

Citation:

L'utilisation des commandes CHECKTABLE/DB avec les options REPAIR : Oui mais devra se faire base non utilisée et la possibilité de perdre des données me rebute pour le moment.

Dans tous les cas vous allez perdre des données si vous ne pouvez pas restaurer à partir d'un backup. Maintenant vous pouvez toujours tenter de récupérer un maximum de données de votre table et connaître les intervalles de données qui seront concernés par vos corruptions de pages.

David Baffaleuf a écrit un très bon billet à ce sujet.

++
05/06/2012, 11h56
Mothership

Merci pour ces informations, nous venons de passer un weekend sympatico. Nous avons via BCP exporté l'ensemble des données de 7 des 11 tables impactées et lors de l'import, la ou les lignes erronées ont été squizzées de l'import. Ces lignes ont ensuite pu être récupérées depuis une sauvegarde X ou Y.

Ce fut long, les imports/exports avec des journaux de transaction qui sont pénibles etc. Bref on a longuement travaillé, c'était peu académique mais pour ces tables là nous n'avons plus d'erreurs.

Pour les 4 autres, la ou les pages provoque des erreurs lors de l'export donc impossible de procéder de la même manière. Samedi avant nos opérations (notamment le repair_rebuild) fait un split de nos disques, ceux-ci étant en miroir entre nos deux SAN. Il se trouve après l'avoir testée, que la base sur le miroir (stockée sur le SAN n'ayant pas eu d'incident jeudi 24/05) fonctionne correctement. Je ne sais pas pourquoi, mais c'est ainsi, l'erreur n'a pas été répliqué sur le LUN de l'autre baie. Nous referons une coupure ce soir pour voir si cela se reproduit "miraculeusement".

En attendant nous avons échafaudé le plan ci-dessous :
Nous avons une base OK de ce weekend (la base sur le miroir)
Nous avons une base KO de ce weekend (la sauvegarde du dimanche)

Nous allons procéder à un allow_repair_data_loss sur nos 4 tables de notre base KO.
Nous allons comparer les 4 tables avec leur fausses jumelles sur la base OK
Nous récupérons la différence à injecter dans la table ayant été réparée.

Dans le même temps je vais tester le RESTORE PAGE
05/06/2012, 14h19
dbaffaleuf

Au sujet des pages:
{
3:1910329
5:2052218
5:2052219
5:2052221
9:5827618
}

Est-ce que le dbcc page renvoie qq chose ou est-ce qu'il sort en erreur ?
05/06/2012, 14h27
SQLpro

La première des choses est quand même d'isoler de toute urgence les disques fautifs. En effet, c'est comme un nid de poule sur la route. Tenter une réparation sur le disque existant peut s'avérer plus catastrophique encore !

Tentez la réparation avec DBCCCHECK... WITH DATA_PURITY.

A +
05/06/2012, 14h38
Mothership

Concernant

Citation:

Tentez la réparation avec DBCCCHECK... WITH DATA_PURITY.

J'ai lu ça sur le site MSDN donc je n'ai pas rajouté l'option, peut être à tort. Notre base ayant vu le jour sur du SQL 2005...

For databases created in SQL Server 2005 and later, column-value integrity checks are enabled by default and do not require the DATA_PURITY option

Pour la gestion des disques, pas d'erreur sous l'OS ni dans la console de gestion du SAN. Ce lun étant (comme tous les autres) stripé sur plusieurs arrays il nous était assez difficile de penser qu'une fois les arrays reconstruits, le problème serait encore physique. Pour information les chkdsk ne remonte aucune erreur.

Concernant les pages en question, il me ressort bien des informations.

Citation:

Est-ce que le dbcc page renvoie qq chose ou est-ce qu'il sort en erreur ?

Je l'ai surtout utilisé pour valider le fait que l'index était bien Cluster et pas un index que j'aurai pu supprimer/recrée aisément. Je ne sais pas si on peut en déduire quelque chose.
05/06/2012, 15h27
dbaffaleuf

Dans l'article pointé par Mike un peu plus haut, j'indique comment voir quels sont les ranges de valeurs qui sont concernés. Comme les pages d'index clusterisé sont classés dans l'ordre de la clé, si on arrive à lire la dernière valeur de la page avant et la première valeur de la page après chaque page endommagée, on en déduit quelles lignes seront perdues avec un repair_allow_data_loss.
05/06/2012, 17h32
SQLpro

Citation:

Envoyé par Mothership

Pour la gestion des disques, pas d'erreur sous l'OS ni dans la console de gestion du SAN. Ce lun étant (comme tous les autres) stripé sur plusieurs arrays il nous était assez difficile de penser qu'une fois les arrays reconstruits, le problème serait encore physique. Pour information les chkdsk ne remonte aucune erreur.

Ce peut être le contrôleur qui est buggué. Déjà vu avec du Dell / Perc !

A +
05/06/2012, 17h36
Mothership

Pour le moment et sur notre environnement de recette, nous avons perdu des lignes (33, 90 etc.) en fonction des tables, enregistrements que nous récupérons sur la base de samedi.

On devrait donc s'en sortir (ne crions pas victoire trop vite).

Du coup, demain arrêt de production de 4h pour cela, vu que le allow_repair_data_loss fait un rebuild de tous les indexes ensuite, certaines tables sont plus gourmandes que d'autres.

Nous profiterons du samedi/dimanche pour la déplacer sur une autre baie par "précaution".

Question annexe :

D'ailleurs pour cela je pense passer par un backup/restauration, on peut retailler la taille des fichiers pendant une restauration ? Déplacer j'ai déjà fait, mais jamais retailler.
05/06/2012, 18h18
SQLpro

Pendant la restauration, non. Mais retailler des fichiers se fait à chaud (pendant que la base est en prod. Et cela a peut d'incidence sur la production.

Il est important de le faire aussi bien pour les données, mais plus encore pour le JT.

A +
08/06/2012, 10h26
Mothership

Merci à tous pour vos réponses, la solution que nous avons mis en place à (heureusement) fonctionné, les dernières tables ont été réparées mercredi soir avec un repair_allow_data_loss suivi de l'insert des données pardues (les données sur les pages en question ayant été identifiées et récupérées depuis une base)

Je clôture le post.