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
Fred BROUARD
Bonjour,
Xavier a écrit:
J'utilise une base de données sur laquelles viennent se connecter un gd nb d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance : "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
-- 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 ***********************
Bonjour,
Xavier a écrit:
J'utilise une base de données sur laquelles viennent se connecter un gd nb
d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe
"SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance :
"SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et
je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server
sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous
devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer
telle ou telle manière de faire.
Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est
le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
--
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 ***********************
J'utilise une base de données sur laquelles viennent se connecter un gd nb d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance : "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
-- 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 ***********************
Xavier
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit: > J'utilise une base de données sur laquelles viennent se connecter un gd nb > d'utilisateur qui doivent bloquer des données en lecture et écriture. > > Pour cela, j'utilise la syntaxe > "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___" > > Pour le premier de ces enreg, j'ouvre une transaction puis je lance : > "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___" > > Lorsque le traitement de cet enreg est terminé, je ferme la transaction et > je relance. > > Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server > sur la deuxième requête. > > J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
> > Merci de vos suggestions.
-- 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 ***********************
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient
visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit:
> J'utilise une base de données sur laquelles viennent se connecter un gd nb
> d'utilisateur qui doivent bloquer des données en lecture et écriture.
>
> Pour cela, j'utilise la syntaxe
> "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
>
> Pour le premier de ces enreg, j'ouvre une transaction puis je lance :
> "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
>
> Lorsque le traitement de cet enreg est terminé, je ferme la transaction et
> je relance.
>
> Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server
> sur la deuxième requête.
>
> J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous
devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer
telle ou telle manière de faire.
Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est
le meilleur moyen de pourrir l'accès à une base.
A +
>
> Merci de vos suggestions.
--
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 ***********************
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit: > J'utilise une base de données sur laquelles viennent se connecter un gd nb > d'utilisateur qui doivent bloquer des données en lecture et écriture. > > Pour cela, j'utilise la syntaxe > "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___" > > Pour le premier de ces enreg, j'ouvre une transaction puis je lance : > "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___" > > Lorsque le traitement de cet enreg est terminé, je ferme la transaction et > je relance. > > Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server > sur la deuxième requête. > > J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
> > Merci de vos suggestions.
-- 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 ***********************
Fred BROUARD
Rien...
SQL le gère tout seul et heureusement !
A +
Xavier a écrit:
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit:
J'utilise une base de données sur laquelles viennent se connecter un gd nb d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance : "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
-- 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 ***********************
-- 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 ***********************
Rien...
SQL le gère tout seul et heureusement !
A +
Xavier a écrit:
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient
visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit:
J'utilise une base de données sur laquelles viennent se connecter un gd nb
d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe
"SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance :
"SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et
je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server
sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous
devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer
telle ou telle manière de faire.
Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est
le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
--
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 ***********************
--
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 ***********************
Comment puis-je faire mon blocage afin que les enreg "bloqués" ne doient visibles que par des requêtes "WITH NOLOCK" en SELECT ?
Merci.
"Fred BROUARD" a écrit :
Bonjour,
Xavier a écrit:
J'utilise une base de données sur laquelles viennent se connecter un gd nb d'utilisateur qui doivent bloquer des données en lecture et écriture.
Pour cela, j'utilise la syntaxe "SELECT ___ FROM T1,T2,T3 WITH (READPAST UPDLOCK) WHERE ___"
Pour le premier de ces enreg, j'ouvre une transaction puis je lance : "SELECT ___ FROM T1,T2,T3 WITH (UPDLOCK) WHERE ___"
Lorsque le traitement de cet enreg est terminé, je ferme la transaction et je relance.
Or, il arrive de plus en plus régulièrement des erreur de blocage SQL Server sur la deuxième requête.
J'en viens à me poser des questions sur la validité de mon code.
effectivement... Vous utiliser un verrou d'UPDATE pour faire un SELECT...
A moins de bien avoir fait une étude de la concurrence de traitement, vous devriez laisser SQL Server poser lui même les verrous plutôt que de lui imposer telle ou telle manière de faire. Le mieux est de gérer une transaction avec un niveau d'isolation adapté.
Forcer des verrous sans une étude préalable suivi d'un audit en production est le meilleur moyen de pourrir l'accès à une base.
A +
Merci de vos suggestions.
-- 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 ***********************
-- 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 ***********************
