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

Administration SQL Server Discussion :

Ordre de kill spid


Sujet :

Administration SQL Server

  1. #1
    Membre du Club
    Homme Profil pro
    test
    Inscrit en
    Octobre 2016
    Messages
    134
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Tunisie

    Informations professionnelles :
    Activité : test
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2016
    Messages : 134
    Points : 49
    Points
    49
    Par défaut Ordre de kill spid
    bonjour a tous

    Si je suis devant ce scénario de blocage (deadlook)

    avec quel SPID Je doit commencer l'opération kill

    kill 53 ou kill 68 ou celle du 79 ? je ne sais pas qui attend qui

    merci pour vos explication
    Images attachées Images attachées  

  2. #2
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Points : 1 736
    Points
    1 736
    Par défaut
    Tout d'abord tu n'es pas face à un Deadlock mais à un blocked process. Car un deadlock est tué toutes les 5 secondes.

    C'est quoi le 68?
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  3. #3
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2003
    Messages : 733
    Points : 1 668
    Points
    1 668
    Billets dans le blog
    8
    Par défaut
    La session 53 est bloquée par la session n° 68
    La session 79 est bloquée par la session n° 53

    Plus généralement,
    - La colonne session_id représente l'ID de la session" associée à la tâche en attente de certaines ressources.
    - La colonne blocking_session_id représente l'ID de la session qui bloque la demande de ressource.

    Maintenant que vous êtres au clair, pour le "Kill" plusieurs choix s'offrent à vous, et ce, en fonction de la session que vous voulez interrompre (la session "victime")
    par exemple :
    - un kill 53 préservera les sessions 79 et 68
    - un kill 68 préservera et déloquera les sessions 53 et par ricochet la session 79

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  4. #4
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Bonjour,

    Et pour résumer et compléter les deux réponses, vu qu'il ne s'agit en effet pas de deadlock, n'effectuer aucun kill devrait préserver les trois sessions.

    Du coup, la question de janlouk reste ouverte
    C'est quoi le 68?
    ,
    ou plutôt que fait-elle ? Même si elle est longue, il est possible de la laisser terminer, ce qui devrait débloquer les autres.

    Enfin au final le choix dépend du contexte et du besoin.

  5. #5
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Points : 1 736
    Points
    1 736
    Par défaut
    Si tu veux savoir depuis quand elles tournent, je te conseille d'utiliser sp_whoisactive : http://whoisactive.com/downloads/
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  6. #6
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2003
    Messages : 733
    Points : 1 668
    Points
    1 668
    Billets dans le blog
    8
    Par défaut
    Les remarques de janlouk et de aieeeuuuuu concernant les deadLock et les Kill (kill qui dans le cas présent ne sont pas nécessaires ), sont très justes et je n’aurais pas dû vous suggérer de faire des Kill Session (mea cupla !).

    L'interblocage (deadlock) est souvent confondu avec le blocage ordinaire (blocked process). Lorsqu'une transaction demande un verrou sur une ressource verrouillée par une autre transaction, elle attend que le verrou soit libéré. Par défaut, les transactions SQL Server n'ont pas de délai d'expiration, à moins que LOCK_TIMEOUT ne soit activé (1). La transaction qui demande le verrou est bloquée. La transaction qui détient le verrou va finir par se terminer et libérer le verrou. La transaction en attente pourra alors obtenir son verrou et s'exécuter normalement.

    (1) ATTENTION : Modifier le paramètre LOCK_TIMEOUT peut avoir des conséquences très grave si les applications ne gèrent pas correctement les erreurs 1222. En effet, le paramètre LOCK_TIMEOUT permet à une application de définir la durée maximale pendant laquelle une instruction reste en attente sur une ressource bloquée. Si l'attente d'une instruction dépasse la valeur du paramètre LOCK_TIMEOUT, l'instruction bloquée est automatiquement annulée (ATTENTION "annulé" ne signifie pas faire ROLLBACK !), et le message d'erreur 1222 (Lock request time-out period exceeded) est retourné à l'application. Toute transaction contenant la commande n'est toutefois pas restaurée (c.à.d. il n'y a pas forcément un ROLLBACK) ou annulée par SQL Server. L'application doit donc posséder un gestionnaire d'erreurs capable d'intercepter le message d'erreur 1222. Si une application ne gère pas cette erreur, elle peut continuer en ignorant que l'une des instructions de la transaction a été annulée. Des erreurs, y compris les erreurs fonctionnelles, métiers, peuvent se produire lorsque les instructions ultérieures dans la transaction dépendent de l'instruction qui n'a jamais été exécutée.

    L'implémentation d'un gestionnaire d'erreurs qui intercepte le message d'erreur 1222 permet à une application de prendre les mesures conséquentes au délai d'expiration, par exemple soumettre à nouveau l'instruction qui été bloquée ou restaurer toute la transaction (c.à.d. effectuer un ROLLBACK).

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  7. #7
    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 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par hmira Voir le message
    ...Par défaut, les transactions SQL Server n'ont pas de délai d'expiration, à moins que LOCK_TIMEOUT ne soit activé (1). ...
    Non... ce paramètre ne sert qu'à attendre l'acquisition du premier verrou et ne contrôle pas la durée de la transaction qui n'a en pratique aucune limite et aucune possibilité de limiter...

    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/ * * * * *

  8. #8
    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 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Vous pouvez utiliser la requête que j'ai donné dans cet article :
    https://blog.developpez.com/sqlpro/p...stance-bloquee
    pour déterminer quelle sont les sessions à annuler en premier.

    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/ * * * * *

  9. #9
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2003
    Messages : 733
    Points : 1 668
    Points
    1 668
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Non... ce paramètre ne sert qu'à attendre l'acquisition du premier verrou et ne contrôle pas la durée de la transaction qui n'a en pratique aucune limite et aucune possibilité de limiter...

    A +
    Oui c'est exact. Merci SQLPro pour cette précision. Il manquait aussi de la ponctuation dans ma phrase initiale.

    Il fallait je crois que je reformule comme ceci :
    "Par défaut, les demandes de verrous sur les ressources, émises par les transactions SQL Server, n'ont pas de délai d'expiration.
    A moins que LOCK_TIMEOUT ne soit activé (1), la transaction qui demande un verrou sur une ressource est bloquée, elle est en attente de la libération de ce verrou détenu par une autre transaction. La transaction qui détient le verrou va finir par se terminer et libérer le verrou. La transaction en attente pourra alors obtenir son verrou et s'exécuter normalement....."

    ET rappeler aussi comme tu l'as fait justement :
    "Les transactions elle-mêmes n'ont pas de délai d'expiration, en d'autres termes, une transaction n'a en pratique aucune limite de temps et il n'existe aucun moyen permettant de limiter dans le temps la durée d'une transaction".

    J'espère que cette fois-ci il n' y a pas d'erreur et c'est clair pour tout le monde

    Merci.

    A+



    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

Discussions similaires

  1. [9.1] Différence entre pg_cancel_backend (SPID) et kill SPID
    Par sihem_info dans le forum Administration
    Réponses: 2
    Dernier message: 26/09/2017, 17h38
  2. Kill spid ne marche pas
    Par MASSAKA dans le forum Adaptive Server Enterprise
    Réponses: 3
    Dernier message: 02/06/2010, 23h31
  3. [SQL 2000] Kill sur SPID qui veut pas
    Par zooffy dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 08/11/2007, 12h06
  4. Ordre de parcours de l'arbre...
    Par Sylvain James dans le forum XML/XSL et SOAP
    Réponses: 3
    Dernier message: 01/12/2002, 19h41
  5. [] Tri d'un tableau par ordre alphabétique
    Par cafeine dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 17/09/2002, 09h43

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