Bonjour,
Un job de check d'intégrité a détecté une corruption sur deux pages d'une table.
A l'aide de l'OBJECT_ID remonté par DBCC, je peux identifier la table concernée.
Suite à cela, j'utilise DBCC PAGE pour voir de quel type de page il s'agit, sauf qu'en exécutant le DBCC PAGE, je trouve des résultats "étranges" :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 Page 1478974 m_pageId = (8224:540291124) m_headerVersion = 128 m_type = 0 m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x100 m_objId (AllocUnitId.idObj) = 892743985 m_indexId (AllocUnitId.idInd) = 64614 Metadata: AllocUnitId = -259461421657423872 Metadata: PartitionId = 0 Metadata: IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (0:8) Page 1478975 m_pageId = (32:-2078539520) m_headerVersion = 128 m_type = 55 m_typeFlagBits = 0x38 m_level = 49 m_flagBits = 0x3831 m_objId (AllocUnitId.idObj) = 42525 m_indexId (AllocUnitId.idInd) = 13363 Metadata: AllocUnitId = 3761350116571414528 Metadata: PartitionId = 0 Metadata: IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (8224:538976288)
On peut constater que le m_pageId ne correspond pas au numéro de la page, je ne comprend pas pourquoi.
Le m_type indique 55, mais je ne connais pas ce dernier et je n'ai pas trouvé de m_type allant au delà de 20.
Le champ Metadata: IndexId indique -1, je ne sais pas à quoi cela correspond, je sais que 0/1 indique qu'il s'agit de la table (HEAP/CLUSTER) et au delà, d'index, mais -1, je n'ai rien trouvé à ce sujet.
Le champ Metadat: ObjectId indique 0, seulement, l'ID de ma table n'est pas du tout 0, je ne comprend donc pas non plus cette valeur.
Auriez-vous des explications pour les points ci-dessus ?
J'ai également voulu suivre le document de Frédéric Brouard (coucou SQLPro), mais je n'ai pas pu continuer, toujours à cause de cet IndexId à -1 et de ObjectId à 0 qui me perdent
(https://blog.developpez.com/sqlpro/f...corrompues.pdf).
Il s'avère que cette table est fréquemment supprimée et recrée par un job, il a donc suffit de lancer ce dernier, la table a été recrée et le DBCC CHECKDB s'exécute désormais sans erreur, la résolution a été simple, sinon, il aurait fallu faire une restauration à partir d'un backup et comme il s'agit d'une base en mode SIMPLE, au revoir les données les plus fraîches.
DBCC CHECKDB indiquait que le niveau minimum était le REPAIR_ALLOW_DATA_LOSS, on aurait pu tenter ça avant la restauration, mais ce n'est pas sans risque non plus.
Cordialement,
Donovan
Partager