Bonjour,
Quelqu'un pourrait-il me confirmer que la durée tracée dans le Profiler pour
les événements "SP:Completed" englobe le temps nécessaire au réseau pour
transmettre les RecordSets au client?
Merci d'avance.
JN.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro
Non. Les durée sont les durées d'exécution et non les temps réseau. Sauf si la procédure fait appel à une ressource externe dans son code.
A +
On 17 oct, 10:30, Jean-Nicolas BERGER wrote:
Bonjour, Quelqu'un pourrait-il me confirmer que la durée tracée dans le Profil er pour les événements "SP:Completed" englobe le temps nécessaire au rése au pour transmettre les RecordSets au client? Merci d'avance. JN.
Non. Les durée sont les durées d'exécution et non les temps réseau.
Sauf si la procédure fait appel à une ressource externe dans son code.
A +
On 17 oct, 10:30, Jean-Nicolas BERGER
<JeanNicolasBER...@discussions.microsoft.com> wrote:
Bonjour,
Quelqu'un pourrait-il me confirmer que la durée tracée dans le Profil er pour
les événements "SP:Completed" englobe le temps nécessaire au rése au pour
transmettre les RecordSets au client?
Merci d'avance.
JN.
Non. Les durée sont les durées d'exécution et non les temps réseau. Sauf si la procédure fait appel à une ressource externe dans son code.
A +
On 17 oct, 10:30, Jean-Nicolas BERGER wrote:
Bonjour, Quelqu'un pourrait-il me confirmer que la durée tracée dans le Profil er pour les événements "SP:Completed" englobe le temps nécessaire au rése au pour transmettre les RecordSets au client? Merci d'avance. JN.
Jean-Nicolas BERGER
bonjour,
Non. Les durée sont les durées d'exécution et non les temps réseau. Sauf si la procédure fait appel à une ressource externe dans son code.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisant en sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne pas, j'ai des Durées différentes entre un PC client sur un bon réseau et un PC client sur un réseau pourri (et bien sûr l'écart est toujours dans le même sens...) Quelqu'un aurait-il une piste? Merci d'avance. JN.
bonjour,
Non. Les durée sont les durées d'exécution et non les temps réseau.
Sauf si la procédure fait appel à une ressource externe dans son code.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisant en
sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne
pas, j'ai des Durées différentes entre un PC client sur un bon réseau et un
PC client sur un réseau pourri (et bien sûr l'écart est toujours dans le même
sens...)
Quelqu'un aurait-il une piste?
Merci d'avance.
JN.
Non. Les durée sont les durées d'exécution et non les temps réseau. Sauf si la procédure fait appel à une ressource externe dans son code.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisant en sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne pas, j'ai des Durées différentes entre un PC client sur un bon réseau et un PC client sur un réseau pourri (et bien sûr l'écart est toujours dans le même sens...) Quelqu'un aurait-il une piste? Merci d'avance. JN.
SQLpro
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
SET NOCOUNT ON permet d'éviter l'apparition des messages "n ligne traitées" à chaque execution d'ordre SQL. C'est une recommandation forte de désactiver ce comportement par défaut pour tout développement (paramètre de session).
A +
On 17 oct, 11:02, Jean-Nicolas BERGER wrote:
bonjour,
> Non. Les durée sont les durées d'exécution et non les temps rés eau. > Sauf si la procédure fait appel à une ressource externe dans son co de.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisan t en sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne pas, j'ai des Durées différentes entre un PC client sur un bon rése au et un PC client sur un réseau pourri (et bien sûr l'écart est toujours da ns le même sens...) Quelqu'un aurait-il une piste? Merci d'avance. JN.
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un
envoi d'information technique pour chaque ordre SQL de la PS.
SET NOCOUNT ON permet d'éviter l'apparition des messages
"n ligne traitées"
à chaque execution d'ordre SQL.
C'est une recommandation forte de désactiver ce comportement par
défaut pour tout développement (paramètre de session).
A +
On 17 oct, 11:02, Jean-Nicolas BERGER
<JeanNicolasBER...@discussions.microsoft.com> wrote:
bonjour,
> Non. Les durée sont les durées d'exécution et non les temps rés eau.
> Sauf si la procédure fait appel à une ressource externe dans son co de.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisan t en
sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne
pas, j'ai des Durées différentes entre un PC client sur un bon rése au et un
PC client sur un réseau pourri (et bien sûr l'écart est toujours da ns le même
sens...)
Quelqu'un aurait-il une piste?
Merci d'avance.
JN.
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
SET NOCOUNT ON permet d'éviter l'apparition des messages "n ligne traitées" à chaque execution d'ordre SQL. C'est une recommandation forte de désactiver ce comportement par défaut pour tout développement (paramètre de session).
A +
On 17 oct, 11:02, Jean-Nicolas BERGER wrote:
bonjour,
> Non. Les durée sont les durées d'exécution et non les temps rés eau. > Sauf si la procédure fait appel à une ressource externe dans son co de.
Alors j'ai du mal à comprendre pourquoi, sur une même PS et en faisan t en sorte (relancer plusieurs fois la PS) que la notion de cache n'intervienne pas, j'ai des Durées différentes entre un PC client sur un bon rése au et un PC client sur un réseau pourri (et bien sûr l'écart est toujours da ns le même sens...) Quelqu'un aurait-il une piste? Merci d'avance. JN.
Jean-Nicolas BERGER
> Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON. Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce point.
Cordialement. JN BERGER
> Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un
envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON.
Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau
lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce
point.
> Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON. Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce point.
Cordialement. JN BERGER
Philippe TROTIN [MS]
Bonjour,
Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Jean-Nicolas BERGER" a écrit dans le message de groupe de discussion :
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON. Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce point.
Cordialement. JN BERGER
Bonjour,
Utilisez vous une authentification Windows ou SQL Server ?
Windows va solliciter le contrôleur de domaine alors que SQL va solliciter
votre base master.
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a écrit
dans le message de groupe de discussion :
F9F97F1C-6B4E-4D79-809D-5AB432121074@microsoft.com...
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un
envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON.
Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau
lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce
point.
Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Jean-Nicolas BERGER" a écrit dans le message de groupe de discussion :
Avez vous mis SET NOCOUNT ON dans votre procédure ? Si non, il y a un envoi d'information technique pour chaque ordre SQL de la PS.
Le SET NOCOUNT est bien positionné à ON. Quoi qu'il en soit, la différence de durée observées (3 secondes en réseau lent contre 1 en réseau rapide) ne semble pas pouvoir s'expliquer par ce point.
Cordialement. JN BERGER
Jean-Nicolas BERGER
> Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Nous utilisons une authentification SQL SERVER. D'autres idées? Merci d'avance. JN.
> Utilisez vous une authentification Windows ou SQL Server ?
Windows va solliciter le contrôleur de domaine alors que SQL va solliciter
votre base master.
Nous utilisons une authentification SQL SERVER.
D'autres idées?
Merci d'avance.
JN.
> Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Nous utilisons une authentification SQL SERVER. D'autres idées? Merci d'avance. JN.
Philippe TROTIN [MS]
Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE GO DBCC DROPCLEANBUFFERS GO
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Jean-Nicolas BERGER" a écrit dans le message de groupe de discussion :
Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Nous utilisons une authentification SQL SERVER. D'autres idées? Merci d'avance. JN.
Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer
que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a écrit
dans le message de groupe de discussion :
D90D1021-C534-46A9-BBD8-C90144FC5D8C@microsoft.com...
Utilisez vous une authentification Windows ou SQL Server ?
Windows va solliciter le contrôleur de domaine alors que SQL va
solliciter
votre base master.
Nous utilisons une authentification SQL SERVER.
D'autres idées?
Merci d'avance.
JN.
Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE GO DBCC DROPCLEANBUFFERS GO
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Jean-Nicolas BERGER" a écrit dans le message de groupe de discussion :
Utilisez vous une authentification Windows ou SQL Server ? Windows va solliciter le contrôleur de domaine alors que SQL va solliciter votre base master.
Nous utilisons une authentification SQL SERVER. D'autres idées? Merci d'avance. JN.
Jean-Nicolas BERGER
> Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE GO DBCC DROPCLEANBUFFERS GO
Nous n'avons pas vidé le cache, mais nous avons d'abord lancé une fois la PS (histoire que le cache s'en imprègne) et ensuite chacun notre tour lancé la même PS, avec les mêmes paramètres. Et le résultat est toujours du même ordre de grandeur, toujours dans le même sens. Plus ça vient, moins je comprends... JN.
> Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer
que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
Nous n'avons pas vidé le cache, mais nous avons d'abord lancé une fois la PS
(histoire que le cache s'en imprègne) et ensuite chacun notre tour lancé la
même PS, avec les mêmes paramètres.
Et le résultat est toujours du même ordre de grandeur, toujours dans le même
sens.
Plus ça vient, moins je comprends...
JN.
> Avez vous utiliser le code suivant entre vos deux appels (pour vous assurer que cela n'est pas lié au cache de SQL) ?
DBCC FREEPROCCACHE GO DBCC DROPCLEANBUFFERS GO
Nous n'avons pas vidé le cache, mais nous avons d'abord lancé une fois la PS (histoire que le cache s'en imprègne) et ensuite chacun notre tour lancé la même PS, avec les mêmes paramètres. Et le résultat est toujours du même ordre de grandeur, toujours dans le même sens. Plus ça vient, moins je comprends... JN.
Jean-Nicolas BERGER
> Plus ça vient, moins je comprends...
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le plus gros. Et si elle attendait que le client ait reçu les résultat du premier SELECT avant de poursuivre ou de lancer le suivant? JN.
> Plus ça vient, moins je comprends...
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le
plus gros.
Et si elle attendait que le client ait reçu les résultat du premier SELECT
avant de poursuivre ou de lancer le suivant?
JN.
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le plus gros. Et si elle attendait que le client ait reçu les résultat du premier SELECT avant de poursuivre ou de lancer le suivant? JN.
Fred BROUARD
Jean-Nicolas BERGER a écrit :
Plus ça vient, moins je comprends...
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le plus gros. Et si elle attendait que le client ait reçu les résultat du premier SELECT avant de poursuivre ou de lancer le suivant? JN.
oui !
a +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Jean-Nicolas BERGER a écrit :
Plus ça vient, moins je comprends...
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le
plus gros.
Et si elle attendait que le client ait reçu les résultat du premier SELECT
avant de poursuivre ou de lancer le suivant?
JN.
oui !
a +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Une piste toutefois : la PS effectue plusieurs SELECT, le premier étant le plus gros. Et si elle attendait que le client ait reçu les résultat du premier SELECT avant de poursuivre ou de lancer le suivant? JN.
oui !
a +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
