Discussion :

[Guigsounet]

En faisant un DBCC CHECK sur ma base SQL SRV 2000 j'obtiens ce message

Code :

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

1
2
3
4
5
6
L'extension (1:109880) de la base de données ID = 5 est marquée allouée au GAM, mais aucun SGAM ou IAM ne l'ont allouée.
L'extension (1:109896) de la base de données ID = 5 est marquée allouée au GAM, mais aucun SGAM ou IAM ne l'ont allouée.
CHECKDB a trouvé 2 erreurs d'allocation et 0 erreurs de cohérence non associées à un quelconque objet unique.
CHECKDB a trouvé 2 erreurs d'allocation et 0 erreurs de cohérence dans la base de données 'XXXX'.
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKDB (XXXX ).
(26,687 sec)

Sur une seconde instance (elle meme sur un second serveur) j'ai recrée la base, l'ai restaurée et ai tenté un repair_allow_data_loss
Si celui ci m'a pondu des lignes et des lignes de log il ne semble avoir eu aucun resultat

En effet un second DBCC CHECK me retourne les memes erreurs

Que faire ?

D'avance Merci

[mikedavem]

Bonjour,

Avez vous placé votre base de données en mode d'urgence avant d'effectuer un DBCC CHECKDB ?

++

[Guigsounet]

Mode urgence ? C est a dire en Single User ?

Si c est cela alors Oui

J'ai a dispo la log du Check repair_allow_data_loss , si cela peut aider

[SQLpro]

En 2000 il n'y a pas de mode d'urgence.

base flingué ! => reprise de sauvegarde.

A +

[Guigsounet]

Les sauvegardes dispo sont corrompus car le pb existe depuis oulah bien tout ca (je suis dans l environnement impacté depuis moins d une semaine, je ne dispose pas d un historique tres precis)

Mais bizarement les applis/users ne sont en rien génés dans leur travail quotidien hormis quelques msgs d 'erreur de ci de la

[mikedavem]

En 2000 il n'y a pas de mode d'urgence.

Oui effectivement, je n'avais pas fait attention à la version
Quoi que tu me diras on peut implémenter ce mode avec SQL Server 2000 en changeant la valeur de la colonne status pour la base de données concernée avec 32768. (en ayant au préalable autoriser les modifications dans les tables systèmes).

++

[dbaffaleuf]

Si CHECKDB retourne que repair_allow_data_loss est le niveau de réparation minimum, alors les 2 pages ne sont probablement pas des pages d'index. Tu peux vérifier en faisant un :

Code :

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

1
2
3
dbcc traceon(3604)
dbcc page(5,1,109880,0)
dbcc page (5,1,109896,0)

et nous renvoyer les valeurs de m_objId et m_indexId.

Il n'y a pas de moyen de connaître la date du dernier DBCC sans erreur dans cette version, il faut vraiment migrer quand vous en avez l'occasion, il y a beaucoup plus de solutions dans les versions ultérieures.

La seule solution consiste à rejouer un backup valide,et si pas de backup, réparer avec repair_allow_data_loss, en indiquant à ton management les conséquences: les deux pages vont très probablement être désallouées donc des données vont être perdues.

David B.

NB: Surtout ne pas détacher cette base !

[Guigsounet]

J ai deja fait le repair et il n a eu aucun effet sur les erreurs en question


m_objId = 566663146 m_indexId = 0

m_objId = 1882807799 m_indexId = 0

[dbaffaleuf]

OK,

Code :

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

1
2
3
4
5
use <mabase>
GO
select object_name(566663146)
select object_name(1882807799)
GO

Est-ce que tu peux lire toutes les lignes de ces 1 tables ?

David B.

[Guigsounet]

ces deux select ne me renvoient aucun resultat

[dbaffaleuf]

Tu exécutes bien la requête dans la base dans laquelle se trouve le problème ?

David B.

[Guigsounet]

oui oui

[dbaffaleuf]

et quand tu relances le dbcc checkdb, il remonte toujours des erreurs sur les mêmes pages ?

Code :

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

dbcc checkdb('<mabase>') with NO_INFOMSGS, ALL_ERRORMSGS

David B.

[Guigsounet]

oui les memes

dois je en conclure que les problèmes que nous avons sont sur des pages qui ne stockent aucun objet, aucune donnée ?

[dbaffaleuf]

Tu vas me trouver un peu insistant ( ) mais peux-tu nous poster dans un fichier joint les résultats suivants (dans SSMS, affiche le résultat de la requête en mode texte pour qu'on ait aussi l'entête de la page):

Code :

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

1
2
3
dbcc traceon(3604)
dbcc page(5,1,109880,3)
dbcc page (5,1,109896,3)

Je regarde ça dans la journée,

David B.

[Guigsounet]

Voici le fichier

[dbaffaleuf]

Il y a deux choses qui m'interpellent:

1) bdbid = 9 sur les 2 pages , or dans le message de sortie de DBCC CHECKDB, on parle d'ID=5. Quelle est la base avec un ID de 9 ( select db_name(9) ) ? Peux-tu relancer les select object_name() dans cette base si elle existe ?

2) m_flagBits = 0x0 et m_tornBits = 49153. Là c'est contradictoire. Potentiellement m_flagBits = 0x0 ça peut vouloir dire que l'option PAGE_VERIFY n'est pas positionnée (on devrait voir au moins 0x100 pour Torn Page Detection, ou 0x200 pour CHECKSUM), mais m_tornBits à autre chose que 0x0 ça veut dire qu'un checksum ou qu'une séquence de bits du TPD ont été codées dans l'entête. (Il faut que je pose la question à une personne avisée, à suivre)

Un dernier truc, peux-tu poster le résultat du dbcc checkdb with no_infomsgs, all_errormsgs, pour voir les numéros d'erreur précis. Thx,

David B.

[Guigsounet]

Ayant recopié la base sur une instance Vierge , j'ai passé des requetes sur l'une ou/et l'autre pour verifier la concordance des resultats (et les resultats sont bien les memes)

Pour les requetes necessitant un Base ID , j ai remplacé ce base ID par le nom de la base

[dbaffaleuf]

ah OK

Si tu peux juste poster le résultat complet du CHECKDB

merci,

David B.

[Guigsounet]

Si tu parles du Repair, voici la log sinon, le Check Sans les msgs d info est dans le premier post

En tous cas merci de ta reactivité et de ton interet