Discussion :

[KyoshiroKensei]

Bonjour

Je vous contacte pour avoir une confirmation sur mon analyse d'un problème de checkdb. Lors de notre plan de maintenance, nous avons eu les erreurs suivantes :

Msg*8928, Niveau*16, État*1, Ligne*2
ID d'objet 402100473, ID d'index 1, ID de partition 72057594430095360, ID d'unité d'allocation 72057594444185600 (type In-row data)*: impossible de traiter la page (1:37812134). Pour plus d'informations, consultez les autres erreurs.
Msg*8928, Niveau*16, État*1, Ligne*2
ID d'objet 402100473, ID d'index 1, ID de partition 72057594430095360, ID d'unité d'allocation 72057594444185600 (type In-row data)*: impossible de traiter la page (1:37812135). Pour plus d'informations, consultez les autres erreurs.
Msg*8976, Niveau*16, État*1, Ligne*2
Erreur de table*: ID d'objet 402100473, ID d'index 1, ID de partition 72057594430095360, ID d'unité d'allocation 72057594444185600 (type In-row data). La page (1:37812134) n'a pas été détectée lors de l'analyse alors que sa page parent (1:37784461) et les (1:37812133) pages précédentes la référencent. Vérifiez les erreurs précédentes.
Msg*8980, Niveau*16, État*1, Ligne*2
Erreur de table*: ID d'objet 402100473, ID d'index 1, ID de partition 72057594430095360, ID d'unité d'allocation 72057594444185600 (type In-row data). La page de nœud d'index (1:37784461), emplacement 447 référence la page enfant (1:37812135) et la page enfant précédente (1:37812134), mais elles n'ont pas été détectées.
Msg*8978, Niveau*16, État*1, Ligne*2
Erreur de table*: ID d'objet 402100473, ID d'index 1, ID de partition 72057594430095360, ID d'unité d'allocation 72057594444185600 (type In-row data). Une référence de la page précédente (1:37812135) est manquante à la page (1:37812136). Un problème de liaison de chaîne s'est peut-être produit.
Msg*8928, Niveau*16, État*1, Ligne*2
ID d'objet 402100473, ID d'index 7, ID de partition 72057594430226432, ID d'unité d'allocation 72057594444316672 (type In-row data)*: impossible de traiter la page (1:48165514). Pour plus d'informations, consultez les autres erreurs.
Msg*8976, Niveau*16, État*1, Ligne*2
Erreur de table*: ID d'objet 402100473, ID d'index 7, ID de partition 72057594430226432, ID d'unité d'allocation 72057594444316672 (type In-row data). La page (1:48165514) n'a pas été détectée lors de l'analyse alors que sa page parent (1:52651969) et les (1:48165513) pages précédentes la référencent. Vérifiez les erreurs précédentes.
Msg*8978, Niveau*16, État*1, Ligne*2
Erreur de table*: ID d'objet 402100473, ID d'index 7, ID de partition 72057594430226432, ID d'unité d'allocation 72057594444316672 (type In-row data). Une référence de la page précédente (1:48165514) est manquante à la page (1:48165515). Un problème de liaison de chaîne s'est peut-être produit.
CHECKDB a trouvé 0 erreurs d'allocation et 8 erreurs de cohérence dans la table (ID d'objet 402100473).
CHECKDB a trouvé 0 erreurs d'allocation et 8 erreurs de cohérence dans la base de données
repair_allow_data_loss est le niveau minimum de réparation pour les erreurs trouvées par DBCC CHECKDB ().

Je me suis concentré sur le l'index cluster de l'objet 402100473, qui aurait 2 pages référencées mais non accessible 37812134 et 37812135:
Lorsque je lance DBCC PAGE ('MABDD', 1,37812134,3) ou DBCC PAGE ('MABDD', 1,37812135,3) , aucune ligne ne ressort. J'en conclu que la page ne contient aucune donnée et que seule la référence de la page est erronée. Est ce bien cela?

Curieusement, lorsque je lance une 2ème fois DBCC CHECKDB, les erreurs ne sont plus ressortie. Est ce que cette erreur sur des pages vides auraient été corrigée par sql?

Note: le problème s'est produit suite à un disque plein.

merci d'avance.

[SQLpro]

tout dépend si vous êtes en AlwaysOn ou pas....

En effet AlwaysOn procède à une réparation automatique des pages endommagées.

Vous pouvez voir cela dans msdb.dbo.suspect_pages.

A +

[KyoshiroKensei]

Bonjour,

Non pas de AlwaysOn actif, je suisen version standard. La requête sur msdb.dbo.suspect_pages ne renvoi aucune ligne.

J'ai relancé le checkdb et plus de retour d'erreur. Du coup difficile de savoir si j'ai bien une base endommagée ou pas. J'avais prévu de remonter un backup puis de reiinsérer les nouvelles données à la main mais cela semble inutile.

Quel est votre avis? Que puis je contrôler pour m'en assurer?

[SQLpro]

Non, pas d'erreur, les pages ne pouvait pas être écrite temporairement, mais tant que votre journal n'était pas saturé, elle étaient en instance d'écriture et SQL y a procédé dès que vous avez fait le ménage. Il y avait sans doute peu de choses à écrire...

Le plus dramatique c'est le journal de transaction pas les fichiers de données.

A +

[KyoshiroKensei]

merci beaucoup.