Discussion :

[wolf06]

J'ai une application serveur qui push en permanence vers la base de données .
De temps en temps d'apres les logs du serveur, certaine requêtes ( SP ou statement) partent en time out
Je voudrais savoir comment faire pour avoir une vue de l'activité de la base données au momment ou j'obtient ces timeout. Existe il une journal d'historisation d'activtée ou autre
Afin de trouver le ou les applications qui satureraient la base.

Ceci se passe sur un site en production ou il y a plusieurs applications qui utilisent la base de données en même temps.

Merci

[SILO]

As tu essayer le profiler ?

[wolf06]

As tu essayer le profiler ?

Bonjour,

Merci pour ta sugestion

Effectivement j'ai essayé le profiler sans succès sur 12 heures car je n'ai pas eu le problème ce jour là.
Je ne voulais pas laisser tourner le profiler toute la semaine car je crais de surcharger la Base de données avec le profiler.

D'ailleurs d'après vos expériences faut-il mieux laisser tourner le profiler sur le serveur de DB ou le laisser tourner sur un autre PC ( le réseaux utilise des switch)

Le profiler surcharge t il la charge du server db ? ( cpu , etc)

Merci

[rudib]

Bonjour,

Bien sûr le profiler consomme, c'est un équilibre à trouver entre la nécessité d'identifier et résoudre ton problème, et la charge que cela peut représenter. En général, c'est vivable.
Pour diminuer la charge : limite le nombre d'événements tracés, sauve le résultat de la trace dans un fichier plutôt que dans une table, lance-la en script directement sur ton serveur par commandes SQL.

[wolf06]

Bonjour,

Bien sûr le profiler consomme, c'est un équilibre à trouver entre la nécessité d'identifier et résoudre ton problème, et la charge que cela peut représenter. En général, c'est vivable.
Pour diminuer la charge : limite le nombre d'événements tracés, sauve le résultat de la trace dans un fichier plutôt que dans une table, lance-la en script directement sur ton serveur par commandes SQL.

Que pensez vous de ceci , avez vous déjà testé :

SQL Server supports a trace property referred to as a Blackbox Trace. Basically it is similr to a flight data recorder on a plane, writting potential issues to a trace file based on activity in SQL Server. If you are getting intermittent issues with your server halting it may not be feasible to monitor with profiler directly 24/7 but with the blackbox trace you now have a tool to go back and look at what was happening before the server reached that state. Blackboxes can be used for any number of situations and the output is a standard trace file you can view in Profiler utility.

The following information is excerpted from SQL BOL (Books Online)

SQL 2000

--------------------------------------------------------------------------------
Use sp_trace_create with the TRACE_PRODUCE_BLACKBOX option to define a trace that appends trace information to a blackbox.trc file in the \Data directory. Once the trace is started, trace information is recorded in the blackbox.trc file until the size of the file reaches 5 megabytes (MB). The trace then creates another trace file, blackbox_1.trc, and trace information is written to the new file. When the size of blackbox_1.trc reaches 5 MB, the trace reverts to blackbox.trc. Thus, up to 5 MB of trace information is always available.

[SILO]

D'ailleurs d'après vos expériences faut-il mieux laisser tourner le profiler sur le serveur de DB ou le laisser tourner sur un autre PC ( le réseaux utilise des switch)

A mon avis, Et c'est ce que je fais au trvail, il faut mieux laisser tourner le profiler sur un autre PC que le serveur de bases de données si x'est possible. Dans ce cas là et selon la charge du PC le profiler pourra tourner une semaine ...

Cordialement.

[rudib]

Je ne connaissais pas, merci de me le faire découvrir !

Ca ne semble pas correspondre à ton besoin : cette trace blackbox conserve les dernières commandes SQL reçues avant un crash du service. Dans ton cas il n'y a pas de crash, simplement le timeout de requêtes.

Il est important de connaître le contexte de ces timeouts. Cela peut venir d'une requête trop gourmande se lançant durant une période chargée, ou l'effet de verrous sur les tables requêtées.