Suivi des erreurs de type "Cannot insert duplicate key row"

Bonjour,

Je souhaiterais pouvoir surveiller toutes les erreurs de type " Cannot insert duplicate key row ..... with unique index ....." (message erreur 2601), le serveur étant sous SQL Server 2000.

D'une part, ce type d'erreur n'est pas référencé dans le journal des erreurs SQL de l'Entreprise Manager.

D'autre part, il n'y a même pas de log ERRORLOG sur ce serveur !

Merci d'avance pour votre aide

une erreur logique (viol de contrainte) n'étant pas une erreur critique, mais fonctionnelle, elle ne sera jamais journalisée.

Vous pouvez utiliser le profileur SQL pour trapper ce genre d'erreur.

A +

Bonjour Frédéric

Merci pour cette réponse.

En passant, est-ce que l'absence d'un ERRORLOG sous SQL 2000 est normal ?

Merci d'avance.

En principe je dirais non.

Que se passe t'il lorsque vous essayez d'ouvrir ce journal avec Entreprise Manager ?

++

Bon, j'ai mis en place une trace. Mais comme un message d'erreur est une ligne à part entière qui suit la requête (ou tout autre action) qui l'a entraîné, je suis obligé d'intercepter toutes les requêtes, même celles qui se passent très bien.

En effet, sous SQL 2000, aucun champ discriminant n'existe pour permettre de filtrer les requêtes sans erreur.
Je vais juste me retrouver avec un volume de log de 100Mo par jour .......:evilred:

Dans Entreprise Manager, il y a bien un journal de log qui est "peuplé".

Mais le répertoire ...\Program Files\Microsoft SQL Server\MSSQL\Log n'existe pas et je ne trouve pas de fichier ERRORLOG.

Il faudrait regarder la commande démarrage du SQL Server (via le SQL Server Manager). Suivez le chemin donné par l'option -e, c'est là qu'il est 8-)

Citation:

---

En effet, sous SQL 2000, aucun champ discriminant n'existe pour permettre de filtrer les requêtes sans erreur.

---

As-tu essayé par exemple l'évènement SQL:BatchCompleted filtré sur le champ Error=2601 ?

Salut

Oui, mais cela ne change pas grand chose.

Une illustration ci-dessous.

http://img33.imageshack.us/img33/697...shot001gpg.jpg

La requête avec SELECT s'exécute sans pb

La requête avec INSERT génère une erreur

Mais l'erreur n'est pas rapportée au niveau de la ligne comportant le INSERT mais dans une ligne supplémentaire.
Et aucune des colonnes de la ligne avec INSERT n'indique qu'elle comporte une erreur.

Note que la ligne d'erreur ne contient que la référence de l'erreur et rien sur la séquence SQL l'ayant entraîné.

Donc je suis obligé de capturer toutes les transactions (ou à tout le moins les requêtes de modif/ajout).

Ce qui fait du monde (environ 5-10Mo tous les 1/4h).

Je vais plutôt tâcher de les enregistrer dans une table et par proc stockée d'appliquer un nettoyage périodique.

Merci

Avec les événements étendues disponibles avec SQL Server 2008 vous auriez pû facilement trapper ce genre d'erreurs .. mais bon avec les versions antérieures il est vrai que la tâche est beaucoup plus rébarbative ...

++

Dommage !

Pour mieux comprendre ton contexte : est-ce que ces clés en double surviennent sur toutes les tables ou seulement sur une bien précise ?

Est-ce que tu en es à localiser la commande fautive dans un code ou tu cherches à localiser la machine ou l'appli qui pose pb ?

merci

Salut

En fait, nous avons eu récemment deux gros plantages applicatifs, très bizarres (car ne touchant pas tout le monde) sans que l'on puisse en identifier la cause. Mais après analyse du pb, tout me portait à croire qu'il ne s'agissait pas d'un problème d'infrastructure mais plutôt un souci au niveau de la base de données de type pb de verrou qui mettait le client applicatif en vrac (du genre un pb non anticipé par l'éditeur.......).

J'en suis donc à monitorer les transactions de ce progiciel pour corroborer notre problème avec une erreur au niveau de la base de données. Vaste sujet : 11 000 tables à surveiller, 40 clients, des requêtes à la pelle .....

J'ai fait une proc stockée qui répond pas trop au problème :
> Le profile monitor écrit ses logs dans une table
> toutes les heures la ps épure les 40-50 Mo de logs inutiles en ne conservant que les lignes d'erreur et les 5 lignes de requêtes qui les précèdent.
> Création d'une alerte si apparition d'une erreur

C'est sûr que si l'onglet du Profiler correspond au filtrage était un peu moins basique, et que les résultats étaient un peu plus détaillés (ex: le champ "Success" n'est pas renseigné !!!) ça serait beaucoup plus facile de filtrer en amont.

Ok, c'est un progiciel donc le code n'est pas entre tes mains.

N'y-a-til pas de possbilité d'activité une trace SQL côté clients ? Je ne sais pas de quel progiciel il s'agit mais on trouve de plus en plus des possibilités de lancer les clients en mode trace ou debug pour une avoir la liste de tous les ordres SQL générés par l'appli. Il suffirait de l'installer sur un pc d'un utilisateur pour lequel le pb survient souvent.

Comme tu le dis, les possibilités de trace sous SQL 2000 sont limités.

1) pour remonter la ligne SQL correcte en erreur, il suffit de prendre le même spid
2) dans certains cas, si transaction, c'est aussi le même ClientProcessId/RquestId/TransactionID

A +

Citation:

---

Envoyé par FMJ

D'une part, ce type d'erreur n'est pas référencé dans le journal des erreurs SQL de l'Entreprise Manager.

---

Hello,

Pour faire logger les messages serveur dans l'errorlog, tu peux modifier les propriétés du message pour lui indiquer de logger spécifiquement l'erreur dans l'errorlog:

Code:

---

1 2	exec sp_altermessage @message_id=2601,@parameter='WITH_LOG',@parameter_value='TRUE'; GO

---

David B.

OK, merci pour la précision

Attention, car si les utilisateurs courant n'ont pas le privilège sysadmin, vous risquez de générer des erreurs supplémentaires en utilisant le WITH LOG...

A +

OK, je vais vérifier.

Par contre, je rencontre plusieurs problèmes avec ma petite technique d'enregistrement et d'épuration des logs dans une table :

> L'écriture des logs dans la table par le Profiler est interrompue par ma requête de suppression des logs sans erreurs
"Echec de l'enregistrement des données de trace dans la table"
--> J'ai donc voulu passer par 2 tables : Une table "TRACE" pour l'enregistrement de tous les logs et une autre "ERROR" pour la copie des logs d'erreur à conserver. L'idée serait d'arrêter deux fois par jour l'écriture de la trace dans la table "TRACE", de faire en suivant la copie dans la table "ERROR", puis de relancer la trace dans "TRACE" (cette action entraîne la suppression de tous les logs déjà enregistrés).

> Le problème, c'est qu'il est visiblement pas possible d'automatiser la trace avec enregistrement dans une table. Lorsque j'enregistre le script SQL correspondant à la trace, j'obtiens le code et les commentaires suivants :
-- Writing to a table is not supported through the SP's

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

/****************************************************/ /* Created by: SQL Profiler */ /* Date: 27/07/2010 16:46:10 */ /****************************************************/     -- Create a Queue declare @rc int declare @TraceID int declare @maxfilesize bigint set @maxfilesize = 5   -- Please replace the text InsertFileNameHere, with an appropriate -- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension -- will be appended to the filename automatically. If you are writing from -- remote server to local drive, please use UNC path and make sure server has -- write access to your network share   exec @rc = sp_trace_create @TraceID output, 0, N'InsertFileNameHere', @maxfilesize, NULL if (@rc != 0) goto error   -- Client side File and Table cannot be scripted   -- Writing to a table is not supported through the SP's   -- Set the events declare @on bit set @on = 1 exec sp_trace_setevent @TraceID, 11, 1, @on exec sp_trace_setevent @TraceID, 11, 3, @on exec sp_trace_setevent @TraceID, 11, 10, @on exec sp_trace_setevent @TraceID, 11, 11, @on [etc...................] exec sp_trace_setevent @TraceID, 82, 34, @on exec sp_trace_setevent @TraceID, 82, 35, @on exec sp_trace_setevent @TraceID, 82, 40, @on     -- Set the Filters declare @intfilter int declare @bigintfilter bigint   set @intfilter = 10 exec sp_trace_setfilter @TraceID, 3, 1, 0, @intfilter   set @intfilter = 0 exec sp_trace_setfilter @TraceID, 31, 0, 1, @intfilter       -- Set the trace status to start exec sp_trace_setstatus @TraceID, 1   -- display trace id for future references select TraceID=@TraceID goto finish   error: select ErrorCode=@rc   finish: go

---

Donc je suis un peu coincé ..... Je ne peux laisser la table "LOGS" grossir de 1Go par jour.

Vous n'auriez pas une idée ?

Chez un de mes anciens clients, on utilisé un processus qui était le suivant :

1er job : (Serveur de prod)
- Démarrage d'une trace à une heure déterminée
2eme job : (Server de prod)
- Arrêt de la trace XX heures après le redémarrage
- Déplacement du fichier de trace sur un serveur qui enregistre les log
3eme job : (sur le serveur de log)
- Si fichier trace présent alors insertion des logs dans une table

Vous pourriez par exemple définir pour le 3eme job un traitement supplémentaire pour copier les requêtes concernées.

++

Citation:

---

-- Writing to a table is not supported through the SP's

---

Je n'ai jamais compris cette limitation. Permettre la génération dans une table via le programme et l'interdire lorsqu'on passe par les traces SQL Server, cela me semble quelque illogique. Si qqn a une explication, je suis preneur :ccool:

Comme l'indique mikedavem, il vous suffit de charger le fichier résultat de la trace comme suit :

Code:

---

SELECT * into TABLE FROM :: fn_trace_gettable (N'z:\monfichiet.trc', 1)

---

Vous pouvez également créer la table en avance si besoin.

Citation:

---

Envoyé par kagemaru

Si qqn a une explication, je suis preneur :ccool:

---

Ca peut venir du fait que la création et l'insertion d'events dans la table se fait via des méthodes de classes (une CTraceTableWriter:: notamment) qui ne sont exposées que dans profiler90.exe ou sa dll, donc pas accessibles en dehors du contexte de Profiler, sauf s'il existe un objet COM à partir de cette dll, je n'en ai pas trouvé. Si tu checkes avec sys.dm_os_loaded_modules, tu verras qu'elle n'est pas chargée dans le process address space de sqlservr. Pour moi ce n'est pas le problème de l'interdire c'est plutôt que la méthode n'est pas disponible depuis l'extérieur. Après, je dis ça, je ne suis pas sûr mais ça semblerait logique.

Note: Ci joint la stack d'un thread de profiler pendant une insertion dans la table de trace.

David B.