Discussion :

[mikedavem]

Bonjour,

m_flagBits = 0x0 et m_tornBits = 49153

>> @dbaffaleuf
Il me semble .... que si la page est lue directement depuis le buffer SQL Server il n'est pas forcé que tu vois la valeur correspondant à la méthode de vérification d'intégrité de la page à moins que la page soit elle même corrompue. Tu me confirmeras peut être .. ??

>> @uigsounet
En regardant un peu vos pages, on voit que l'extent correspond à la page est alloué mais n'est pas déclaré dans la page IAM correspond à l'objet '566663146' de la table 'PMTC_COMMERCE'. Le message d'erreur de la commande DBCC vous le dit d'ailleurs.

Vous pouvez le vérifier en exécutant la commande (aux erreurs de syntaxe près) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
USE PMTC_COMMERCE
GO
 
DECLARE @objet_name SYSNAME
SET @objet_name = OBJECT_NAME(566663146)
 
DBCC IND('PMTC_COMMERCE', @objet_name, -1)

En principe la page no 109880 ne devrait pas être présente dans votre cas.
Si la réparation ne fonctionne pas le seul moyen est la restauration d'une sauvegarde saine ....

++

[dbaffaleuf]

OK je comprends mieux... Msg 8905 indique en gros qu'une page référencée par le plan d'allocation global dans le fichier (GAM = Global Allocation Map) ne se trouve appartenir à aucun objet (IAM = Index Allocation Map, le plan d'allocation par table/index). Donc deux pages se baladent et n'appartiennent à aucun objet, ce qui explique aussi que tes utilisateurs ne sont pas impactés. Comme indiqué dans la sortie du dbcc en mode repair, REPAIR_ALLOW_DATA_LOSS ne peut pas réparer ces erreurs.

Sans backup, il faut essayer de sortir toute la base et de la recharger ailleurs, par exemple avec l'assistant d'export, et relancer un checkdb sur la nouvelle base.

En même temps, il faudrait jeter un coup d'oeil sur la machine sur lequel le problème est arrivé, dans l'eventvwr, pour voir s'il n'y a pas un pb matériel là dessous.

Je répondrai par MP (ou par article s'il y a de quoi raconter) sur la question de m_tornbits / m_flagbits.

A+,

David B.

[SQLpro]

Si la réparation ne fonctionne pas le seul moyen est la restauration d'une sauvegarde saine ....

Pas uniquement car comme sa base semble fonctionner on peut extraire le DDL de la version actuelle (hors index) puis toutes les lignes de toutes les tables et réinjecter dans une nouvelle base et reconstruire les index !

A +

[SQLpro]

Ceci dit, la première chose à faire de toute urgence est de déplacer les fichiers vers un système disque sain, car il y a fort à parier que c'est le disque qui est partit en vrille ou le contrôleur qui est HS.

Vérifier que vous n'avez pas activé le contrôleur disque avec cache en écriture. Si c'est le cas, désactivez le. Vérifiez la pile... Sachez que certains cahce disque en écriture sont strictement incompatible avec les SGBDR. Votre fabriquant doit le certifier....

Donc :
1) sp_detach_db + déplacement des fichiers + sp_attach_db
2) migration de la base avec reconstruction comme indiqué.

A +

[mikedavem]

Pas uniquement car comme sa base semble fonctionner on peut extraire le DDL de la version actuelle (hors index) puis toutes les lignes de toutes les tables et réinjecter dans une nouvelle base et reconstruire les index !

Tu as raison mais en fait je parlais des données à restaurer qu'il a perdu avec les 2 extents .. je n'ai pas précisé ... celles-ci seront effectivement bien perdues ...

++

[dbaffaleuf]

Il me semble .... que si la page est lue directement depuis le buffer SQL Server il n'est pas forcé que tu vois la valeur correspondant à la méthode de vérification d'intégrité de la page à moins que la page soit elle même corrompue. Tu me confirmeras peut être .. ??

Je ne sais pas trop quelles peuvent être les raisons valables pour que m_flagbits reste à 0x0: même en désactivant TPD dans une base en 2000, m_flagBits est à 0x8000 et m_tornBits à 0x0, ce qui est normal...

David B.

[mikedavem]

Effectivement .. mais au fait quelle est la méthode employée sur la base de données en question ? (TORN_PAGE ou NONE)

++

[SQLpro]

Si l'objet est un index, toutes les données peuvent être récupérées. Si c'est une table.... walou !

J'ai pas suivi tout le fil... mais bon !

A +

[mikedavem]

Si l'objet est un index, toutes les données peuvent être récupérées. Si c'est une table.... walou !

Je pense également que cela ne sera pas possible .. en fait c'est juste par curiosité .... pour éclaircir ce problème de valeur de flag ... si on pouvait avoir une réponse cela serait bien :-)

[dbaffaleuf]

Si l'objet est un index, toutes les données peuvent être récupérées.

Hello Frédéric,

Ce ne sont pas des pages d'index, sinon le CHECKDB renverrait REPAIR_REBUILD comme solution minimale de réparation.

David B.

[mikedavem]

Ce ne sont pas des pages d'index, sinon le CHECKDB renverrait REPAIR_REBUILD comme solution minimale de réparation.

... et le flag m_indexId (=0) des pages concernées le confirme (sur la version 2000 on a bien la relation entre l'objet et l'index auquel appartient la page)

++

[SQLpro]

OK, boys, donc j'en reviens à mon premier post : sauvegarde + restore !!!

A +

[dbaffaleuf]

Juste une mise à jour pour les guicques au sujet de m_flagBits / m_tornBits.

m_flagBits à une valeur de 0 peut signifier deux choses, sachant qu'en version 2000, les fichiers de données étaient toujours zéro-initialisés (pas de IFI):
- Soit la page n'a pas été formatée: elle n'est ni une page de donnée, ni une page d'index, ni une PFS, SGAM, GAM, ML, DIFF, IAM, ce qu'on veut. Elle se trouve dans un extent qui n'est tout simplement pas encore utilisé.
- Soit elle est corrompue (le scoop !). C'est le cas ici car m_type=1 signifie qu'il s'agit d'une page de donnée. m_tornBits lui décrit bien la séquence de bits utilisés par le TPD. Voilà ce qui s'appelle enfoncer une porte ouverte.

Celà dit, je persiste, pour que ce genre de choses arrive, il y a potentiellement qq chose qui cloche côté sous-système IO sur la machine origine. Je suis d'avis qu'un petit coup de SQLIOSIM ne ferait pas de mal.
(http://support.microsoft.com/kb/231619)

David B.

[mikedavem]

Ok merci pour l'info

Un petit chkdsk et / ou le parcours du journal d'événement est aussi parfois très révélateur.

++