Discussion :

[dunkansk8]

bonjour,
nous nous sommes rendu compte aujourd'hui que des déconnexions a la base de données survenaient sur nos applications
apres quelques recherches nous avons identifié la table causant ces déconnexions
en effectuant la commande

DBCC CHECKTABLE ('pics3.mesure_2')

nous obtenons une liste d'erreurs assez longue

Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 0. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 1. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 2. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 3. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 4. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1
Erreur de ligne : Objet ID = 965578478, index ID = 0, page ID = (1:2391), ligne ID = 5. La colonne 'msrepl_tran_version' a été créée NOT NULL, mais est NULL dans la ligne.
Serveur*: Msg 8970, Niveau 16, État 1, Ligne 1...
Il y a 7385707 lignes dans 53297 pages pour l'objet 'pics3.mesure_2'.
CHECKTABLE a trouvé 0 erreurs d'allocation et 33773 erreurs de cohérence dans la table 'pics3.mesure_2' (objet ID = 965578478).
CHECKTABLE a trouvé 0 erreurs d'allocation et 3 erreurs de cohérence dans la table 'pics3.mesure_tpsr' (objet ID = 997578592).
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKTABLE (pcadc3_GestDyn.pics3.mesure_2 ).

comment pouvons nous solder ces erreurs
la commande

DBCC CHECKTABLE ('pics3.mesure_2') ,REPAIR_ALLOW_DATA_LOSS )

peut elle nous aider ?

[mikedavem]

Bonsoir,

Apparemment votre table est publiée dans le cadre d'une réplication transactionnelle pouvant être mise à jour depuis les abonnées ... d'après le nom de la colonne concernée par les messages d'erreur.

Est ce toujours le cas ? Dans le cas d'une réponse négative supprimer tout simplement cette colonne et relancer votre commande CHECKDB

++

[dunkansk8]

en effet cette table fut publié
actuellement elle ne l'est plus
mais dans l'absolu est il envisageable de supprimer cette colonne
de lancer un checkTable et ensuite de re publier la table ?
une tel manipulation peux elle engendre des problèmes ?

[mikedavem]

Non, d'autant plus que si votre table n'est plus publiée, profitez en pour supprimer cette colonne qui pour le moment vous cause ces erreurs inutiles.

Faites un CHECKTABLE par la suite pour voir si vous ne rencontrez effectivement plus d'erreur (sans l'option REPAIR_ALLOW_DATA_LOSS).

Dans le cas d'une nouvelle publication, votre colonne msrepl_tran_version sera recréée donc pas de souci de ce côté là non plus.

++

[dunkansk8]

Bonsoir,
je viens d'effectuer l'alter table et j'ai relancé le checktable
voici le résultat

Serveur*: Msg 8928, Niveau 16, État 1, Ligne 1
Objet ID = 965578478, index ID = 0 : La page (1:3607) ne peut pas être traitée. Pour plus d'informations, consultez les autres erreurs.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 0, page (1:3607). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Serveur*: Msg 8928, Niveau 16, État 1, Ligne 1
Objet ID = 965578478, index ID = 0 : La page (1:7492) ne peut pas être traitée. Pour plus d'informations, consultez les autres erreurs.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 0, page (1:7492). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Serveur*: Msg 8928, Niveau 16, État 1, Ligne 1
Objet ID = 965578478, index ID = 0 : La page (1:12551) ne peut pas être traitée. Pour plus d'informations, consultez les autres erreurs.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 0, page (1:12551). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Serveur*: Msg 8928, Niveau 16, État 1, Ligne 1
Objet ID = 965578478, index ID = 0 : La page (1:12567) ne peut pas être traitée. Pour plus d'informations, consultez les autres erreurs.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
...
Serveur*: Msg 8936, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Discordance de liaison de chaînes dans le B-tree. (1:44778)->suiv. = (1:4181), mais (1:4181)->Préc. = (1:4179).
Serveur*: Msg 8935, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Le lien précédent (1:4181) sur la page (1:4182) ne correspond pas à la page précédente (1:44749) que la page parente (1:4373), slot 2, attend pour cette page.
Serveur*: Msg 8986, Niveau 16, État 1, Ligne 1
Trop d'erreurs trouvées (201) pour l'objet ID = 965578478. Pour voir tous les messages d'erreurs, relancez l'instruction avec 'WITH ALL_ERRORMSGS'.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 997578592, index ID = 0, page (1:43117). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 997578592, index ID = 0, page (1:43186). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Serveur*: Msg 8939, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 997578592, index ID = 0, page (1:44610). Échec du test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode). Les valeurs sont 2057 et -1.
Résultats DBCC pour 'pics3.mesure_2'.
Il y a 7418769 lignes dans 53297 pages pour l'objet 'pics3.mesure_2'.
CHECKTABLE a trouvé 0 erreurs d'allocation et 602 erreurs de cohérence dans la table 'pics3.mesure_2' (objet ID = 965578478).
CHECKTABLE a trouvé 0 erreurs d'allocation et 3 erreurs de cohérence dans la table 'pics3.mesure_tpsr' (objet ID = 997578592).
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKTABLE (pcadc3_GestDyn.pics3.mesure_2 ).

[mikedavem]

Visiblement vous pouvez tenter UN DBCC avec l'option REPAIR_ALLOW_DATA_LOSS mais en prenant soin d'avoir un jeu de sauvegarde sous le coude car cette option comme indiquée peut vous faire perdre certaines données

++

[dunkansk8]

j'ai lancé la commande mais il me reste des erreurs
en voici une liste non exhaustive

Serveur*: Msg 1505, Niveau 16, État 1, Ligne 1
CREATE UNIQUE INDEX s'est arrêtée parce qu'une clé a été trouvée en double pour l'index ID*= 1. La clé primaire la plus significative est '12'.
Serveur*: Msg 8978, Niveau 16, État 1, Ligne 1

...
Erreur de table : Objet ID = 965578478, index ID = 1. Page (1:44737) n'a pas été trouvé dans l'analyse bien que ses parents (1:3022) et (1:2978) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Serveur*: Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Page (1:44738) n'a pas été trouvé dans l'analyse bien que ses parents (1:5917) et (1:5863) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Serveur*: Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Page (1:44739) n'a pas été trouvé dans l'analyse bien que ses parents (1:2443) et (1:2378) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Serveur*: Msg 8978, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. La page (1:44744) n'a pas de référence dans la page précédente (1:8035). Possibilité d'un problème de liaison de chaîne.
Serveur*: Msg 8978, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. La page (1:44858) n'a pas de référence dans la page précédente (1:6399). Possibilité d'un problème de liaison de chaîne.
Serveur*: Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Page (1:66303) n'a pas été trouvé dans l'analyse bien que ses parents (1:12346) et (1:31941) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Serveur*: Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : Objet ID = 965578478, index ID = 1. Page (1:66304) n'a pas été trouvé dans l'analyse bien que ses parents (1:32672) et (1:31938) précédents y font référence. Contrôlez toutes les erreurs précédentes.
Résultats DBCC pour 'pics3.mesure_2'.
Impossible de réparer cette erreur.
Réparer cette erreur impose de réparer d'abord les autres erreurs.
...
Réparer cette erreur impose de réparer d'abord les autres erreurs.
Réparer cette erreur impose de réparer d'abord les autres erreurs.
Réparer cette erreur impose de réparer d'abord les autres erreurs.
Réparer cette erreur impose de réparer d'abord les autres erreurs.
Réparer cette erreur impose de réparer d'abord les autres erreurs.
Il y a 7420439 lignes dans 53368 pages pour l'objet 'pics3.mesure_2'.
CHECKTABLE a trouvé 0 erreurs d'allocation et 501 erreurs de cohérence dans la table 'pics3.mesure_2' (objet ID = 965578478).
repair_rebuild est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKTABLE (pcadc3_GestDyn.pics3.mesure_2 repair_allow_data_loss).
L'instruction a été arrêtée.

notez que la structure de cette table n'est pas pour simplifier la tache, celle ci ne disposant pas d'une clef primaire simple

CREATE TABLE [mesure_2] (
[id_nature_mesure] [int] NOT NULL ,
[date_mesure] [datetime] NOT NULL ,
[valeur] [float] NULL ,
PRIMARY KEY CLUSTERED
(
[id_nature_mesure],
[date_mesure]
) ON [PRIMARY]
) ON [PRIMARY]
GO

j'ai tenté de supprimer cette clé pour en forcer la recéation mais je n'y parviens pas

[mikedavem]

Avez vous un message d'erreur qd vous essayez de la supprimer ?

Avez vous fait un petit chkdsk pour vérifier l'intégrité de vos disques par simple hasard ?

Essayez une suppression + restauration de votre table en dernier recours
++

[dunkansk8]

Bonsoir,
c'est bon j'ai pu supprimer cette clef primaire
j'ai ensuite ajouté une vrai cle unique avec un Identity afin de dédoublonner la table c'est chose faite et le CHECKDB ne rapporte plus aucune erreur
merci encore pour le coup de main