IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

blocage (transaction verouillée)


Sujet :

Développement SQL Server

  1. #1
    Membre à l'essai
    Inscrit en
    Novembre 2004
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : Novembre 2004
    Messages : 30
    Points : 24
    Points
    24
    Par défaut blocage (transaction verouillée)
    bonjour tout le monde.
    j ai une application qui tourne avec une base dans sql server 2005, parfois j ai des requettes sql qui échoue sachant que se sont des simple requettes de mise à jour . je donne un exemple
    j ai une table personne avec une colonne nom
    j arrive à modifier correctement tout les noms , mai à un moment donnée un nom spécifique , une ligne précise dans ma table se bloque .
    on cherchant un peu dans le net j ai trouvé qu il s agit peut etyre d'un problème de verou.
    parceque une fois je redemmare mon appli tout marche bien avec cette ligne , mais je retombe encore sur une autre ligne qui se bloque.
    la requette est :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    SELECT
    *
     FROM
     master.dbo.sysprocesses PROCESSLIST
     INNER JOIN master.dbo.sysdatabases DATABASELIST
     ON PROCESSLIST.dbid = DATABASELIST.dbid
     WHERE
     (DATABASELIST.name = N'VISION_DB')
    je débute avec sql server et je sais pas comment faire pour ne pas avoir se blocage à chaque fois
    voila le resultat qu il me retourne lorseque c est bloquer
    Images attachées Images attachées  

  2. #2
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour,

    Votre requête ne donne pas suffisamment de détails pour que vous puissiez trouver l'origine du blocage.
    N'utilisez pas la table master.dbo.sysprocesses qui est obsolète depuis SQL Server 2005 et remplacée par sys.sysprocesses.
    sys.dm_exec_requests vous y aidera

    Je vous donne le FROM, à vous de trouver les colonnes qui vont bien pour trouver le code qui n'est pas performant

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    FROM sys.dm_exec_sessions ES
    JOIN sys.dm_exec_connections EC ON ES.session_id = EC.session_id
    JOIN sys.dm_exec_requests ER ON ES.session_id = ER.session_id
    JOIN sys.sysprocesses SP ON SP.spid = ES.session_id
    @++

  3. #3
    Membre à l'essai
    Inscrit en
    Novembre 2004
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : Novembre 2004
    Messages : 30
    Points : 24
    Points
    24
    Par défaut
    Merci beaucoup elsuket,
    j ai essayé votre FROM mais franchement j arrive pas à m en sortir, y a beaucoup d'information que j arrive pas à comprendre ; et ce que je comprend pas aussi, pourquoi sql server block des enregistrements ?
    et comment éviter ce blocage sachant qu il a un temps d'attente infinie pour ma connexion?
    et comment faire pour contrôler ce blocage ?

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    pourquoi sql server block des enregistrements ?
    D'abord il n'existe pas d'enregistrement dans une base de données. On parle de lignes qui sont des unités logique de table. Pour ce qui est des verrous, c'est SQL Server qui les posent sur des lignes, des pages, des extensions, des plages de clefs et des tables en fonction de la demande de lecture ou d'écriture qui est faite au serveur.

    Les blocages sont normaux, comme le sont les feux rouges pour réguler la circulation des voitures en ville.
    Ce qui n'est pas normal, ce sont :
    1) des blocages qui durent
    2) des interblocages (verrous mortels, étreintes fatales, dead locks) trop fréquents

    Cela est principalement du :
    1) a un mauvais modèle de données (pas de respect du modèle relationnel et en particulier des formes normales)
    2) à une sous indexation de la base de données
    3) a l'exécution de requêtes ou de procédures stockées mal écrite
    4) à une mauvaise gestion des transactions.

    Il n'y a pas de remèdes miracle : il faut auditer ce qui cloche et y remédier.

    Lisez les articles que j'ai écrit au sujet de l'optimisation : http://sqlpro.developpez.com/optimisation/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre à l'essai
    Inscrit en
    Novembre 2004
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : Novembre 2004
    Messages : 30
    Points : 24
    Points
    24
    Par défaut
    merco SQLpro,
    effectivement je crois qu il s'agit d'une mauvaise gestion des transactions, alors j ai pensé à faire ceci afin de libérer les verrous aprés chaque transaction.
    c'est l'utilisation de commit ou rollback
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
     
    SqlTransaction transaction = null;
     
            try
            {
     
     
                transaction = connection.BeginTransaction();
     
                // Assign Transaction to Command
                command.Transaction = transaction;
     
                // Execute  Command 
                command.CommandText = "......";
                command.ExecuteNonQuery();
     
                transaction.Commit();
            }
            catch
            {
                transaction.Rollback();
                throw;
            }
    mais j ai rencontré un autre problème;
    c'est qu il y a un conflit entre les threads, sachant que mon application et multithreading
    le message d'erreur et le suivant:
    Une nouvelle transaction n'est pas autorisée parce que d'autres threads sont en cours d'exécution dans la session.

    je sais pas comment m'ensortir avec cette histoire de verrous.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    1) évitez le multi threading avec des transactions. Ceci est Strictement impossible et totalement absurde. En effet le but du multi threading est de répartir une charge donc la parraléliser tandis que le but d'une transaction est au pire de la sérialiser pour la rendre atomique. Bref vous faite une chose et son contraire.
    2) évitez de faire des transaction côté client. C'est la pire des choses. Faites des procédures stockées transactionnées.
    3) si votre commande SQL ne comporte qu'une seule instruction, c'est déjà une transaction en auto commit, le fait de rajouter une transaction explicite ne sert à rien.
    4) si vous ne testez pas les conditions d'annulation d'une transaction, à quoi sert-elle ?
    Imaginez que je mette un feu rouge. Vous ne le regardez pas et continuez avec votre voiture... Que va t-il se passer ???

    Une solide révision de votre culture bases de données et en particulier ce qu'est une transaction me parait fortement souhaitable ! Lisez les articles que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
    http://sqlpro.developpez.com/isolation-transaction/
    http://sqlpro.developpez.com/cours/s...ns-imbriquees/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Membre à l'essai
    Inscrit en
    Août 2009
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 18
    Points : 15
    Points
    15
    Par défaut procédure stockée avec valeur de retour
    Bonjour,
    j'ai ce même problème lorsque je teste mon application avec plusieurs clients:
    Aléatoirement, à l'insertion d'une ligne, j'ai une SqlException : "Une nouvelle transaction n'est pas autorisée parce que d'autres threads sont en cours d'exécution dans la session."

    j'ai lu avec intérêt les posts de ce topic, ainsi que les liens de SQLpro...
    J'ai donc créé une procédure stockée:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
     
    CREATE PROCEDURE usr_CreateNewILT
    	-- Add the parameters for the stored procedure here
    	@ProductID int, 
    	@SerialID nchar(50),
    	@UserID int
    AS
     
    DECLARE @date datetime
    DECLARE @ILTID int
     
    BEGIN
    	-- SET NOCOUNT ON added to prevent extra result sets from
    	-- interfering with SELECT statements.
    	SET NOCOUNT ON;
    	SET IDENTITY_INSERT dbo.ILT OFF
     
        -- Insert statements for procedure here
    	BEGIN TRANSACTION
    	-- Is the product ID exist?
    	IF NOT EXISTS (SELECT * FROM [APRProduction].[dbo].[Product] WHERE [ID]=@ProductID)
    	BEGIN
    		ROLLBACK TRANSACTION
    		RETURN -1
    	END
     
     
    	SELECT @date = GETDATE()
        --SELECT @UserID = [ID] FROM [APRProduction].[dbo].[Utilisateur] WHERE [Username]=@Username
     
    	INSERT INTO dbo.ILT  WITH (TABLOCKX) (ProductID, SerialID, Date, Score, nbimpacts, Utilisateur_ID ) 
    	VALUES (@ProductID, @SerialID, @date, 0, 0, @UserID)
     
    	IF (@@ERROR <> 0) OR (@@ROWCOUNT = 0)
    		GOTO ROLLBACK_ON_ERROR
     
    	SELECT @ILTID = SCOPE_IDENTITY()
     
    	COMMIT TRANSACTION
     
    	RETURN @ILTID 
     
    	ROLLBACK_ON_ERROR:
    		ROLLBACK TRANSACTION
    		RETURN -1
    END
    GO
    Cette procédure me permet d'ajouter proprement une ligne dans la table, et de récupérer l'ID de cette ligne. Ca fonctionne très bien sous SQL server...
    Mais pour appeler cette procédure stockée depuis le C#... C'est beaucoup moins simple... car je ne récupère que l'ID... Du coup, je ne peux pas importer la fonction depuis mon code C#...
    voir ci-dessous:
    http://msdn.microsoft.com/fr-fr/libr...(v=vs.90).aspx
    Remarque
    Si la valeur de Type de retour est un type simple, Visual Basic ou C# n'est pas généré automatiquement pour le Function Import.
    Je n'ai vu qu'un article en anglais expliquant qu'il "suffit" de créer des tables contenant uniquement un int et de transférer les résultats vers cette table...
    http://thedatafarm.com/blog/data-acc...f-ef-designer/
    Quelqu'un aurait un début d'idée pour m'aider?

    merci d'avance,

Discussions similaires

  1. [2008R2] Blocage de transaction
    Par Fredo02 dans le forum SSIS
    Réponses: 6
    Dernier message: 23/01/2012, 20h10
  2. Transaction et blocage
    Par J0r_x dans le forum Développement
    Réponses: 6
    Dernier message: 21/05/2010, 19h18
  3. Blocage de transaction (NOLOCK ?)
    Par Liloye dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 04/05/2010, 10h01
  4. blocage d'une transaction
    Par richard038 dans le forum Bases de données
    Réponses: 2
    Dernier message: 16/11/2005, 13h00
  5. Apropos des Transactions au sein d'un Stored Procedure
    Par Sarbacane dans le forum Connexion aux bases de données
    Réponses: 6
    Dernier message: 16/11/2004, 09h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo