Discussion :

[Mothership]

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 :

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

[elsuket]

Bonjour,

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

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.

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.

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.

[mikedavem]

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.

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.

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.

++

[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

[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 ?

[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 +

[Mothership]

Concernant

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.

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.

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

[SQLpro]

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 +

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

[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 +

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