Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
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
Philippe T [MS]
Bonjour,
Il faut aussi voir les problèmes d'indexation et de volumétrie des tables.
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Bonjour,
Il faut aussi voir les problèmes d'indexation et de volumétrie des tables.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"Pierre Duc" <nospam@nospam.com> wrote in message
news:%23xZHxZq9FHA.4036@TK2MSFTNGP11.phx.gbl...
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
Il faut aussi voir les problèmes d'indexation et de volumétrie des tables.
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Fred BROUARD
Med Bouchenafa a écrit:
Oui, c'est effectivement une cause possible Pour avoir le coeur net, il faut lancer un sp_lock et regarder ce qui se passe Dans SQL Server 2000, le probleme d'une transaction en lecture bloquant une autre en modification est bien connu Il est connu sous le nom "reader-block-writer". SQL Server 2005 apporte une solution par la creation d'un nouveau mode d'isolation: RLV (Row-Level Versioning ).
tu veut dire niveau d'isolation SNAPSHOT...
A +
-- Bien cordialement Med Bouchenafa
"Pierre Duc" <mailto: wrote in message news:% > Je pose ici une question de principe, "vue de haut". > > Soit une base qui est accédée en modification par plusieurs utilisateurs. > > De temps en temps une requête SELECT un peu longue faite par un utilisateur > qui interroge ponctuellement la base pour faire des stats bloque les autres > utilisateurs pendant plusieurs dizaines de secondes. > > Le serveur (RAM, CPU, disque) n'est pas chargé. > A priori, pour rechercher la source du problème, je partirai vers un souci > de verrouillage. > Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les > détails) ? > > Merci ! > > Pierre. > >
-- 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.datasapiens.com ***********************
Med Bouchenafa a écrit:
Oui, c'est effectivement une cause possible
Pour avoir le coeur net, il faut lancer un sp_lock et regarder ce qui se
passe
Dans SQL Server 2000, le probleme d'une transaction en lecture bloquant
une autre en modification est bien connu
Il est connu sous le nom "reader-block-writer".
SQL Server 2005 apporte une solution par la creation d'un nouveau mode
d'isolation: RLV (Row-Level Versioning ).
tu veut dire niveau d'isolation SNAPSHOT...
A +
--
Bien cordialement
Med Bouchenafa
"Pierre Duc" <nospam@nospam.com <mailto:nospam@nospam.com>> wrote in
message news:%23xZHxZq9FHA.4036@TK2MSFTNGP11.phx.gbl...
> Je pose ici une question de principe, "vue de haut".
>
> Soit une base qui est accédée en modification par plusieurs utilisateurs.
>
> De temps en temps une requête SELECT un peu longue faite par un
utilisateur
> qui interroge ponctuellement la base pour faire des stats bloque les
autres
> utilisateurs pendant plusieurs dizaines de secondes.
>
> Le serveur (RAM, CPU, disque) n'est pas chargé.
> A priori, pour rechercher la source du problème, je partirai vers un
souci
> de verrouillage.
> Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
> détails) ?
>
> Merci !
>
> Pierre.
>
>
--
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.datasapiens.com ***********************
Oui, c'est effectivement une cause possible Pour avoir le coeur net, il faut lancer un sp_lock et regarder ce qui se passe Dans SQL Server 2000, le probleme d'une transaction en lecture bloquant une autre en modification est bien connu Il est connu sous le nom "reader-block-writer". SQL Server 2005 apporte une solution par la creation d'un nouveau mode d'isolation: RLV (Row-Level Versioning ).
tu veut dire niveau d'isolation SNAPSHOT...
A +
-- Bien cordialement Med Bouchenafa
"Pierre Duc" <mailto: wrote in message news:% > Je pose ici une question de principe, "vue de haut". > > Soit une base qui est accédée en modification par plusieurs utilisateurs. > > De temps en temps une requête SELECT un peu longue faite par un utilisateur > qui interroge ponctuellement la base pour faire des stats bloque les autres > utilisateurs pendant plusieurs dizaines de secondes. > > Le serveur (RAM, CPU, disque) n'est pas chargé. > A priori, pour rechercher la source du problème, je partirai vers un souci > de verrouillage. > Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les > détails) ? > > Merci ! > > Pierre. > >
-- 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.datasapiens.com ***********************
Pierre Duc
Merci à tous pour vos réponses simples et rapides !
Pierre.
"Pierre Duc" a écrit dans le message de news: #
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Merci à tous pour vos réponses simples et rapides !
Pierre.
"Pierre Duc" <nospam@nospam.com> a écrit dans le message de news:
#xZHxZq9FHA.4036@TK2MSFTNGP11.phx.gbl...
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
Merci à tous pour vos réponses simples et rapides !
Pierre.
"Pierre Duc" a écrit dans le message de news: #
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Bouarroudj Mohamed
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer la possibilité d'utiliser le hint NOLOCK ou READPAST si les deux hints ne peuvent etre utilisées dans votre cas, une replication de la BD sera une autre alternative (la 2eme BD sera utilsée pour des fins de stats)
Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas tout a fait d'accord qu'il va magiquement resoudre nos problemes, je préfere retourner la nouvelle version d'un record (Dirty Read avec NOLOCK) qui a 99 % de chances qu'il sera commité par l'utilisateur que lire l'ancienne valeur d'un record (qui est dans 99% des cas n'est plus valide). Dans une application (sans trop de bugs evidement) le ROLLBACK est une exeception, le COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur ce derniers points :)
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer la
possibilité d'utiliser le hint NOLOCK ou READPAST
si les deux hints ne peuvent etre utilisées dans votre cas, une replication
de la BD sera une autre alternative (la 2eme BD sera utilsée pour des fins
de stats)
Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas tout
a fait d'accord qu'il va magiquement resoudre nos problemes, je préfere
retourner la nouvelle version d'un record (Dirty Read avec NOLOCK) qui a 99
% de chances qu'il sera commité par l'utilisateur que lire l'ancienne valeur
d'un record (qui est dans 99% des cas n'est plus valide). Dans une
application (sans trop de bugs evidement) le ROLLBACK est une exeception, le
COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur ce
derniers points :)
"Pierre Duc" <nospam@nospam.com> wrote in message
news:%23xZHxZq9FHA.4036@TK2MSFTNGP11.phx.gbl...
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer la possibilité d'utiliser le hint NOLOCK ou READPAST si les deux hints ne peuvent etre utilisées dans votre cas, une replication de la BD sera une autre alternative (la 2eme BD sera utilsée pour des fins de stats)
Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas tout a fait d'accord qu'il va magiquement resoudre nos problemes, je préfere retourner la nouvelle version d'un record (Dirty Read avec NOLOCK) qui a 99 % de chances qu'il sera commité par l'utilisateur que lire l'ancienne valeur d'un record (qui est dans 99% des cas n'est plus valide). Dans une application (sans trop de bugs evidement) le ROLLBACK est une exeception, le COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur ce derniers points :)
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
lionelp
Bonjour,
Le blocker script doit aider si la requête bloquante n'est pas identifiée: http://support.microsoft.com/kb/271509/EN-US/
Cordialement, LionelP
"Pierre Duc" a écrit :
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Bonjour,
Le blocker script doit aider si la requête bloquante n'est pas identifiée:
http://support.microsoft.com/kb/271509/EN-US/
Cordialement,
LionelP
"Pierre Duc" a écrit :
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
Le blocker script doit aider si la requête bloquante n'est pas identifiée: http://support.microsoft.com/kb/271509/EN-US/
Cordialement, LionelP
"Pierre Duc" a écrit :
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Med Bouchenafa
Ce n'est pas parceque, tout à tout coup soudain, SQL Server 2005 supporte le "Row Versioning" que je fais faire l'apologie de cette technologie J'ai bien pu m'en passé pendant les dix dernieres années. Mais le sujet est effectivement interessant et suffisamment passionnant. Il a, pendant des années, animé les débats entre les tenants d'Oracle et ceux de SQL Server. L'inclusion de cette technologie dans SQL Server 2005 permettra peut-etre de temperer ces débats. Pour ma part, je reste ouvert à toute technologie qui me permettrait de résoudre au mieux les problemes de mes clients
Bien cordialement Med Bouchenafa
"Bouarroudj Mohamed" a écrit dans le message de news:
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer la possibilité d'utiliser le hint NOLOCK ou READPAST si les deux hints ne peuvent etre utilisées dans votre cas, une replication de la BD sera une autre alternative (la 2eme BD sera utilsée pour des fins de stats) ppor Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas tout a fait d'accord qu'il va magiquement resoudre nos problemes, je préfere retourner la nouvelle version d'un record (Dirty Read avec NOLOCK) qui a 99 % de chances qu'il sera commité par l'utilisateur que lire l'ancienne valeur d'un record (qui est dans 99% des cas n'est plus valide). Dans une application (sans trop de bugs evidement) le ROLLBACK est une exeception, le COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur ce derniers points :)
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
Merci !
Pierre.
Ce n'est pas parceque, tout à tout coup soudain, SQL Server 2005 supporte
le "Row Versioning" que je fais faire l'apologie de cette technologie
J'ai bien pu m'en passé pendant les dix dernieres années.
Mais le sujet est effectivement interessant et suffisamment passionnant.
Il a, pendant des années, animé les débats entre les tenants d'Oracle et
ceux de SQL Server.
L'inclusion de cette technologie dans SQL Server 2005 permettra peut-etre de
temperer ces débats.
Pour ma part, je reste ouvert à toute technologie qui me permettrait de
résoudre au mieux les problemes de mes clients
Bien cordialement
Med Bouchenafa
"Bouarroudj Mohamed" <mbouarroudj@yahoo.com> a écrit dans le message de
news: eAsjsd19FHA.356@TK2MSFTNGP12.phx.gbl...
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer
la possibilité d'utiliser le hint NOLOCK ou READPAST
si les deux hints ne peuvent etre utilisées dans votre cas, une
replication de la BD sera une autre alternative (la 2eme BD sera utilsée
pour des fins de stats)
ppor
Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas
tout a fait d'accord qu'il va magiquement resoudre nos problemes, je
préfere retourner la nouvelle version d'un record (Dirty Read avec NOLOCK)
qui a 99 % de chances qu'il sera commité par l'utilisateur que lire
l'ancienne valeur d'un record (qui est dans 99% des cas n'est plus
valide). Dans une application (sans trop de bugs evidement) le ROLLBACK
est une exeception, le COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur
ce derniers points :)
"Pierre Duc" <nospam@nospam.com> wrote in message
news:%23xZHxZq9FHA.4036@TK2MSFTNGP11.phx.gbl...
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un
utilisateur
qui interroge ponctuellement la base pour faire des stats bloque les
autres
utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé.
A priori, pour rechercher la source du problème, je partirai vers un
souci
de verrouillage.
Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les
détails) ?
Ce n'est pas parceque, tout à tout coup soudain, SQL Server 2005 supporte le "Row Versioning" que je fais faire l'apologie de cette technologie J'ai bien pu m'en passé pendant les dix dernieres années. Mais le sujet est effectivement interessant et suffisamment passionnant. Il a, pendant des années, animé les débats entre les tenants d'Oracle et ceux de SQL Server. L'inclusion de cette technologie dans SQL Server 2005 permettra peut-etre de temperer ces débats. Pour ma part, je reste ouvert à toute technologie qui me permettrait de résoudre au mieux les problemes de mes clients
Bien cordialement Med Bouchenafa
"Bouarroudj Mohamed" a écrit dans le message de news:
Puisque ici la requete est utilisée a des fins des stats, il faut evaluer la possibilité d'utiliser le hint NOLOCK ou READPAST si les deux hints ne peuvent etre utilisées dans votre cas, une replication de la BD sera une autre alternative (la 2eme BD sera utilsée pour des fins de stats) ppor Pour le niveau d'isolation SNAPSHOT de SQL Server 2005 je ne suis pas tout a fait d'accord qu'il va magiquement resoudre nos problemes, je préfere retourner la nouvelle version d'un record (Dirty Read avec NOLOCK) qui a 99 % de chances qu'il sera commité par l'utilisateur que lire l'ancienne valeur d'un record (qui est dans 99% des cas n'est plus valide). Dans une application (sans trop de bugs evidement) le ROLLBACK est une exeception, le COMMIT est la régle
Je vois deja Med et Fred sur leurs claviers repondre a mes alégation sur ce derniers points :)
"Pierre Duc" wrote in message news:%
Je pose ici une question de principe, "vue de haut".
Soit une base qui est accédée en modification par plusieurs utilisateurs.
De temps en temps une requête SELECT un peu longue faite par un utilisateur qui interroge ponctuellement la base pour faire des stats bloque les autres utilisateurs pendant plusieurs dizaines de secondes.
Le serveur (RAM, CPU, disque) n'est pas chargé. A priori, pour rechercher la source du problème, je partirai vers un souci de verrouillage. Voyez-vous d'autres voies de recherche possibles (sans rentrer dans les détails) ?
