Discussion :

[Franck.jobard]

Bonjour

Chez un client, nous avons de gros ralentissements qui se terminent bien souvent par des timeout
Au niveau du moniteur d'activité, je vois les processus en cours et notamment ceux qui sont bloqués mais pour plus de précision sur ce qui se passe, j'aurai voulu lancer une trace avec SQL Server Profiler

Quand je créé les traces, je vois défiler les évènements mais uniquement sur une base qui ne m'intéresse pas
J'ai donc créé une deuxième trace filtrée sur DataBaseName et le profiler ne me rend rien, hormis de temps en temps 'exec sp_reset_connection'

Pourquoi n'ai je rien dans le SQL Server profiler alors que le moniteur d'activité me dit que des utilisateurs travaillent sur cette base ?

[mikedavem]

Est-ce que tu peux nous donner la définition de ta trace ?

++

[Franck.jobard]

Il n'y a pas de définition (même si je ne suis pas sur du sens)

Je lance le profiler et je lui demande de tracer tout ce qui passe sur l'instance SQL Server
Il me donner toutes les traces sur la base de données 1 mais aucune sur la base de données 2

Si je fais une autre trace avec un filtre sur le databasename de la base 2, je n'ai rien d'autres que des sp_reset_connection

[darkelend]

Quand tu ouvres le profiler dans l'onglet "Events Selection", Il faut que tu coches à minima
- Stored Procedures\RPC:Completed
- TSQL\SQL:BatchCompleted (ou Starting)

[Franck.jobard]

Tout est coché par défaut

Si je demande à voir le détail, je coche tout ce qui concerne Lock, T-SQL, Transaction, je ne vois rien de plus

[darkelend]

Peut etre que je comprends mal mais est ce que tu as la case "Show All Events" (en bas à droite) de cochée ? Si non, coches là et choisis les évènements qui t’intéresse.

[Franck.jobard]

Avec ou sans cette coche, j'ai le même résultat

[mikedavem]

Vu ce que tu nous dit il y a plusieurs solutions :

- Tu n'es pas connecté au bon serveur sql avec le profiler
- Tu n'es pas connecté au bon serveur sql depuis ton application
- Tu as un filtre dans la trace que tu as créé et qui n'est pas le bon

++

[SQLpro]

Il me donner toutes les traces sur la base de données 1 mais aucune sur la base de données 2
Si je fais une autre trace avec un filtre sur le databasename de la base 2, je n'ai rien d'autres que des sp_reset_connection

La plupart des commandes SQL n'ont pas de base de données relative. Supprimez ce filtre et vous verrez alors apparaître les requêtes dans le profiler.

ATTENTION : sur un serveur en production il ne faut pas utiliser l'interface graphique, ni stocker les traces dans une table. Utilisez les procédures stockées et alimentez des fichiers par rotation.

A +

[Franck.jobard]

Merci pour vos réponses mais malheureusement aucune des pistes proposées ne m'aident beaucoup

La base 1 (auquel nous accédons aux traces) a en effet la même structure que la base 2 (qui ne rend aucune trace)
Nous accédons à ces bases, par la même application, donc beaucoup de requêtes communes, que nous voyons donc dans les traces de la base 1 et pas de trace dans la base 2
Les deux bases sont sur la même instance SQL et lorsque nous ne filtrons pas sur un databasename, nous ne voyons que la base 1
Enfin, le premier test que j'avais fait sur le profiler était de voir toutes les traces de toutes l'instances, et je ne vois rien sur la base 2

Petites précisions que j'aurai du mettre précédemment :
Il a SQL Server Std 2055 SP2
Mon client passe par un citrix pour ces applications
Il utilise un SAN pour ces disques (je ne sais pas si cela peu jouer)

[SQLpro]

Dans SSMS voyez-vous les 2 bases en faisant la requête suivante :
SELECT * FROM sys.databases
?

N'avez vous pas 2 instances avec chacune 1 base ?

A +

[mikedavem]

Pour tester d'abord la trace je ferai effectivement ce que dit SQLPro : un simple test depuis SSMS pour voir effectivement si je vois mes requêtes passer dans le profiler.

++

[Franck.jobard]

Les deux bases sont en production chez mon client et sont donc parfaitement fonctionnelles
Le moniteur d'activité me donne bien les verrous posés sur les bases, et un clic sur l'ID process me donne la requête sur la connexion en cours
D'un point de vue SSMS, tout semble normal, c'est uniquement le profiler qui refuse de me tracer les évènements de la base 2

PS : Nous avons appelé Microsoft mais mon client est en 2005 SP2, pas de maintenance du coup de la part de l'éditeur qui exige le SP4

[aieeeuuuuu]

Bonjour,

La base 1 (auquel nous accédons aux traces) a en effet la même structure que la base 2 (qui ne rend aucune trace)
Nous accédons à ces bases, par la même application, donc beaucoup de requêtes communes, que nous voyons donc dans les traces de la base 1 et pas de trace dans la base 2
Les deux bases sont sur la même instance SQL et lorsque nous ne filtrons pas sur un databasename, nous ne voyons que la base 1
Enfin, le premier test que j'avais fait sur le profiler était de voir toutes les traces de toutes l'instances, et je ne vois rien sur la base 2

Avez vous regardé les requêtes sur la base1 ?
Il se peut que votre application se connecte toujours sur la base1, et fasse des requêtes sous la forme

Code :

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

1
2
3
 
SELECT ...
FROM Base2.Schema.Table

Dans ce cas, c'est les tables de la base2 qui sont visées, mais elle sont lancées depuis Base1, et c'est Base1 qui sera remonté par le profiler dans la colonne DatabaseName.

[Franck.jobard]

Le moniteur d'activité me dit que mes requêtes sont correctes, sans préfixage de serveur ou de schéma