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
Julien Bonnier
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme enregistrements, et d'autres erreurs similaires ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le resultat en serait presque automatiquement douteux. Alors il est pratiquement tout le temps possible (pour ne pas dire tout le temps) de choisir la facon dont les données sont vérouillé le temps de leur acces par un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan! Julien
"Brigitte" wrote in message news:
Bonjour,
Je ne comprend pas comment un process sur un seul thread puisse se bloquer lui même.
Auriez-vous une idée?
Merci
Bonne journée
Brigitte
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme
enregistrements, et d'autres erreurs similaires
ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le
resultat en serait presque automatiquement douteux. Alors il est
pratiquement tout le temps possible (pour ne pas dire tout le temps) de
choisir la facon dont les données sont vérouillé le temps de leur acces par
un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui
ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan!
Julien
"Brigitte" <Brigitte@discussions.microsoft.com> wrote in message
news:2B04E2B8-8856-4ED6-BB0E-1AC35415DC93@microsoft.com...
Bonjour,
Je ne comprend pas comment un process sur un seul thread puisse se bloquer
lui même.
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme enregistrements, et d'autres erreurs similaires ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le resultat en serait presque automatiquement douteux. Alors il est pratiquement tout le temps possible (pour ne pas dire tout le temps) de choisir la facon dont les données sont vérouillé le temps de leur acces par un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan! Julien
"Brigitte" wrote in message news:
Bonjour,
Je ne comprend pas comment un process sur un seul thread puisse se bloquer lui même.
Auriez-vous une idée?
Merci
Bonne journée
Brigitte
Brigitte
Bonsoir,
Je peux apporter une précision sur la configuration de SQL SERVER. On a modifié l'affinity mask à 15 et le max degree of parallelism à 4 Voilà un exemple de sql générant un lock dont le SPID se bloque lui même DECLARE @DAT_PRO varchar(8) SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAME = 'DAT_PRO_VAR')
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme enregistrements, et d'autres erreurs similaires ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le resultat en serait presque automatiquement douteux. Alors il est pratiquement tout le temps possible (pour ne pas dire tout le temps) de choisir la facon dont les données sont vérouillé le temps de leur acces par un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan! Julien
"Brigitte" wrote in message news: > Bonjour, > > Je ne comprend pas comment un process sur un seul thread puisse se bloquer > lui même. > > Auriez-vous une idée? > > Merci > > Bonne journée > > Brigitte
Bonsoir,
Je peux apporter une précision sur la configuration de SQL SERVER.
On a modifié l'affinity mask à 15 et le max degree of parallelism à 4
Voilà un exemple de sql générant un lock dont le SPID se bloque lui même
DECLARE @DAT_PRO varchar(8)
SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAME =
'DAT_PRO_VAR')
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme
enregistrements, et d'autres erreurs similaires
ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le
resultat en serait presque automatiquement douteux. Alors il est
pratiquement tout le temps possible (pour ne pas dire tout le temps) de
choisir la facon dont les données sont vérouillé le temps de leur acces par
un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui
ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan!
Julien
"Brigitte" <Brigitte@discussions.microsoft.com> wrote in message
news:2B04E2B8-8856-4ED6-BB0E-1AC35415DC93@microsoft.com...
> Bonjour,
>
> Je ne comprend pas comment un process sur un seul thread puisse se bloquer
> lui même.
>
> Auriez-vous une idée?
>
> Merci
>
> Bonne journée
>
> Brigitte
Je peux apporter une précision sur la configuration de SQL SERVER. On a modifié l'affinity mask à 15 et le max degree of parallelism à 4 Voilà un exemple de sql générant un lock dont le SPID se bloque lui même DECLARE @DAT_PRO varchar(8) SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAME = 'DAT_PRO_VAR')
Afin d'eviter les erreurs décritures/suppression simultanné sur un meme enregistrements, et d'autres erreurs similaires ex. ecriture/lecture la ou lécriture serait plus long que la lecture, le resultat en serait presque automatiquement douteux. Alors il est pratiquement tout le temps possible (pour ne pas dire tout le temps) de choisir la facon dont les données sont vérouillé le temps de leur acces par un utilisateur.
Maintenant si tes enregistrements reste vérouillé il y a quelque choses qui ne se fait pas bien... Tu peux peut-etre nous mettre en contexte...
Bonne chan! Julien
"Brigitte" wrote in message news: > Bonjour, > > Je ne comprend pas comment un process sur un seul thread puisse se bloquer > lui même. > > Auriez-vous une idée? > > Merci > > Bonne journée > > Brigitte
Med Bouchenafa
http://support.microsoft.com/kb/906344/
-- Bien cordialement Med Bouchenafa
"Brigitte" wrote in message news:
Bonjour,
Je ne comprend pas comment un process sur un seul thread puisse se bloquer lui même.
Auriez-vous une idée?
Merci
Bonne journée
Brigitte
http://support.microsoft.com/kb/906344/
--
Bien cordialement
Med Bouchenafa
"Brigitte" <Brigitte@discussions.microsoft.com> wrote in message
news:2B04E2B8-8856-4ED6-BB0E-1AC35415DC93@microsoft.com...
Bonjour,
Je ne comprend pas comment un process sur un seul thread puisse se bloquer
lui même.
Je ne comprend pas comment un process sur un seul thread puisse se bloquer lui même.
Auriez-vous une idée?
Merci
Bonne journée
Brigitte
SQLpro
On 20 mar, 18:43, Brigitte wrote:
Bonsoir,
Je peux apporter une précision sur la configuration de SQL SERVER. On a modifié l'affinity mask à 15 et le max degree of parallelism à 4
Si vous êtes sur un 16 procs, un paramètre plus correct serait de définir 75% des procs à SQL Server donc 12 pour SQL Server et 4 pour l'OS. De plus veillez a ce que les proc utilisé par SQL Server soit des procs de n° faible (0, 1, 2, 3...) et non les plus haut. En effet le processeur de n° max est généralement utilisé pour les tâches des cartes réseau, seule chose que SQL Server ne fait pas et pour laquelle il se repose sur l'OS.
MAXDOP 4 reste une bonne valeur dans ce cas.
A +
Voilà un exemple de sql générant un lock dont le SPID se bloque lui même DECLARE @DAT_PRO varchar(8) SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAM E = 'DAT_PRO_VAR')
On 20 mar, 18:43, Brigitte <Brigi...@discussions.microsoft.com> wrote:
Bonsoir,
Je peux apporter une précision sur la configuration de SQL SERVER.
On a modifié l'affinity mask à 15 et le max degree of parallelism à 4
Si vous êtes sur un 16 procs, un paramètre plus correct serait de
définir 75% des procs à SQL Server donc 12 pour SQL Server et 4 pour
l'OS. De plus veillez a ce que les proc utilisé par SQL Server soit
des procs de n° faible (0, 1, 2, 3...) et non les plus haut. En effet
le processeur de n° max est généralement utilisé pour les tâches des
cartes réseau, seule chose que SQL Server ne fait pas et pour laquelle
il se repose sur l'OS.
MAXDOP 4 reste une bonne valeur dans ce cas.
A +
Voilà un exemple de sql générant un lock dont le SPID se bloque lui même
DECLARE @DAT_PRO varchar(8)
SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAM E =
'DAT_PRO_VAR')
Je peux apporter une précision sur la configuration de SQL SERVER. On a modifié l'affinity mask à 15 et le max degree of parallelism à 4
Si vous êtes sur un 16 procs, un paramètre plus correct serait de définir 75% des procs à SQL Server donc 12 pour SQL Server et 4 pour l'OS. De plus veillez a ce que les proc utilisé par SQL Server soit des procs de n° faible (0, 1, 2, 3...) et non les plus haut. En effet le processeur de n° max est généralement utilisé pour les tâches des cartes réseau, seule chose que SQL Server ne fait pas et pour laquelle il se repose sur l'OS.
MAXDOP 4 reste une bonne valeur dans ce cas.
A +
Voilà un exemple de sql générant un lock dont le SPID se bloque lui même DECLARE @DAT_PRO varchar(8) SELECT @DAT_PRO = (SELECT VAR_VALEUR FROM ADM_VAR_PARAM WHERE VAR_NAM E = 'DAT_PRO_VAR')
