Problème 'DBCC CHECKDB'

Bonjour,
lorsque je clique sur un bouton un message d'erreur s'affiche (image ci-dessous) , je me suis assurée de la procédure stockée qui est la cause de ce problème , et quand je l 'ai exécuté sur sql ça m'a donné cette erreur :
Un index endommagé a peut-être été détecté. Exécutez DBCC CHECKDB.
je ne sais vraiment pas quoi faire , j'ai cherché sur net mais cela ne m'a servi à rien DU TOUT .
MERCI

Bin tu peux peut-être faire ce que sql serveur suggère...

C'est-à-dire exécuter DBCC CHECKDB sur la DB de l'index qui pose problème...

bien suur que j l'ai fait , mais ça donne rien : Résultats DBCC pour*'PharmaticaCote'.
Message Service Broker 9675, état 1*: Types de messages analysés*: 14.
Message Service Broker 9676, état 1*: Contrats de service analysés*: 6.
Message Service Broker 9667, état 1*: Services analysés*: 3.
Message Service Broker 9668, état 1*: Files d'attente du service analysées*: 3.
Message Service Broker 9669, état 1*: Points de terminaison de conversation analysés*: 0.
Message Service Broker 9674, état 1*: Groupes de conversation analysés*: 0.
Message Service Broker 9670, état 1*: Liaisons de service distant analysées*: 0.
Message Service Broker 9605, état 1*: Priorités de conversation analysées*: 0.
Msg*8905, Niveau*16, État*1, Ligne*1
L'extension (1:82728) dans l'ID de base de données 16 est marquée comme étant allouée dans GAM, mais aucun SGAM ou IAM ne l'a allouée.
Msg*8905, Niveau*16, État*1, Ligne*1
L'extension (1:82736) dans l'ID de base de données 16 est marquée comme étant allouée dans GAM, mais aucun SGAM ou IAM ne l'a allouée.
CHECKDB a trouvé 2 erreurs d'allocation et 0 erreurs de cohérence qui ne sont associées à aucun objet unique.
Résultats DBCC pour*'sys.sysrscols'.
Il y a 1494 lignes dans 16 pages pour l'objet "sys.sysrscols".
Résultats DBCC pour*'sys.sysrowsets'.
Il y a 203 lignes dans 2 pages pour l'objet "sys.sysrowsets".
Résultats DBCC pour*'sys.sysallocunits'.
Il y a 220 lignes dans 4 pages pour l'objet "sys.sysallocunits".
Résultats DBCC pour*'sys.sysfiles1'.
Il y a 2 lignes dans 1 pages pour l'objet "sys.sysfiles1".
Résultats DBCC pour*'sys.syspriorities'.
Il y a 0 lignes dans 0 pages pour l'objet "sys.syspriorities".
Résultats DBCC pour*'sys.sysfgfrag'.
Il y a 2 lignes dans 1 pages pour l'objet "sys.sysfgfrag".
Résultats DBCC pour*'sys.sysphfg'.
Il y a 1 lignes dans 1 pages pour l'objet "sys.sysphfg".
Résultats DBCC pour*'sys.sysprufiles'.
Il y a 2 lignes dans 1 pages pour l'objet "sys.sysprufiles".
Résultats DBCC pour*'sys.sysftinds'.
Il y a 0 lignes dans 0 pages pour l'objet "sys.sysftinds".
.
.
.
.
.
.
.
.
.
.
.
.
rien compris

des solutions? :/

Est-ce que tu peux lancer un DBCC CHECKDB de cette manière et nous donner le résultat :

Code:

---

DBCC CHECKDB('mabasebase') WITH NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

---

++

Bonjour,
désolée pour le retard

voilà le résultat (image):

je connais la table et le champs où ya ce problème.
voila quand je sélectionne ce champ :

Code:

---

select * from entete_cde where ID_ENTETE_COMMANDE = 481445

---

cela me donne cette erreur :

Un index endommagé a peut-être été détecté. Exécutez DBCC CHECKDB.

j 'ai exécuté DBCC CHECKDB. , mais après y a rien ..

c'est bon avec quelques recherches j'ai pu résoudre le problème :
1- On exécute la base en mode SINGLE_USER :

Code:

---

1 2 3

ALTER DATABASE maDataBase SET single_user WITH ROLLBACK IMMEDIATE;

---

2-On execute :

Code:

---

DBCC CHECKDB ('maDataBase' ,repair_Rebuild)

---

3- On execute maintenant la base en mode MULTI_USER :

Code:

---

1 2 3

ALTER DATABASE maDataBase SET multi_user WITH ROLLBACK IMMEDIATE;

---

4-et en fin :

Code:

---

DBCC CHECKDB ('maDataBase' ,repair_allow_data_loss)

---

Je ne vois pas bien le numéro d'index à côté de la ligne où est mentionné "repair_Rebuild". Visiblement quelque chose de différent de la valeur 1 ??

Globalement je pense que ton problème est résolu mais du coup tu as certainement perdu des données dans ta table (index 1). Est-ce que je me trompe ?

++

des données genre?

Visiblement certaines pages comme la page 851 ou 82736 identifiées par la commande DBCC CHECKDB étaient corrompues. L'option repair_allow_data_loss supprime en général les pages de données d'index concernées et reconstruit la chaîne entre les pages d'index restantes.

N'as tu pas perdu quelques données sur ta table ayant l'id 1381579960 (d'après ce que je peux voir sur l'image fournie) ?

++

je ne sais pas comment je pourrais le savoir ou les trouver: ..la page 851 , id 1381579960 !!! ><

En principe le nom de ta table tu peux l'avoir avec :

Code:

---

SELECT OBJECT_NAME(1381579960)

---

Ensuite il suffit de voir si tu as bien toutes tes données dans cette table.

++

oui mais je connais déjà la table où y a l'erreur et même le champs .
c'est dans cette table et exactement dans le champ ID_ENTETE_COMMANDE :

Code:

---

select * from entete_cde where ID_ENTETE_COMMANDE = 481445

---

mais je ne sais pas comment je pourrais savoir les données perdues , parce que j'ai plus de 18789 ligne. et je ne peux faire select avant que je corrige l'erreur car j'ai cette erreur d'index comme j' ai mentionné avant :

Un index endommagé a peut-être été détecté. Exécutez DBCC CHECKDB.

Dans ce cas si tu as une sauvegarde récente (avant ton problème d'intégrité) tu peux la remonter et comparer le nombre de lignes que tu as maintenant sur cette table dans un premier temps et voir les lignes manquantes (si manquantes) dans un 2eme temps.

++

oui mais je ne peux pas ,
comme j 'ai dit , lorsque je sélectionne la table pour voir le nombre de ligne on me donne erreur :
Un index endommagé a peut-être été détecté. Exécutez DBCC CHECKDB.

Je n'ai pas compris dans ce cas.

Si je reprends tes posts précédents tu dis :

Citation:

---

c'est bon avec quelques recherches j'ai pu résoudre le problème :

---

.. et tu as mis en résolu le thread.

Donc pour moi tu n'as plus de souci avec ton SELECT, juste ?

++

non après ces modification que j'ai effectuées maintenant je peux sélectionner ma table :)

Citation:

---

non après ces modification que j'ai effectuées maintenant je peux sélectionner ma table

---

Donc tu n'as plus de problème avec ton SELECT :) ... on va y arriver.

Maintenant que tu peux "sélectionner" ta table il faut vérifier que tu n'as pas perdu de données. Pour cela :

- soit tu connais les données et tu sais ce que tu as perdu
- soit ta table est référencée par une clé étrangère et dans ce cas il suffit de regarder dans la table qui concerne la clé étrangère les valeurs manquantes
- soit tu n'as aucune idée de la perte de données et dans ce cas tu peux tenter de restaurer une sauvegarde avant ton problème et comparer les données de ta table restaurée et celle que tu utilises maintenant

++

je ne peux pas comprer puisque je ne peux pas faire select sur ma table au moment où il y a le problème >< et les données de ma table sont nombreux

Donc tu n'as aucune sauvegarde qui remonte à avant le problème ?

non toutes les sauvegardes que j'ai contiennent ce problème

ok donc tu as surement perdu des données sans savoir lesquels...

et y a pas par hasard d'autre solu apart celle là x/

Sans sauvegarde valide ... non malheureusement.

Ce que tu peux faire maintenant c'est de mettre en place une vérification périodique de tes bases de données via un plan de maintenance ou par le biais de la commande DBCC CHECKDB avant d'effectuer tes sauvegardes

++

oui d'accord . Merci :)

Ce qu'il faut dans ton plan de maintenance c'est une période de rétention des sauvegardes supérieur à la fréquence des tests d'intégrité.