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 :

[2005] Transactions : comment ça marche ?


Sujet :

Développement SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Par défaut [2005] Transactions : comment ça marche ?
    Bonjour,

    Est-ce qu'un l'un d'entre vous saurais me dire, si en SQL Server 2005 lorsqu'on définit une transacton (BEGIN jusqu'au COMMIT/ROLLBACK), le server fait une prélécture de l'ensemble du query pour obtenir les accès (paratagés, exclussifs,....) nécessaire avant de commencer l'opération ou si les accès sont obtenus en cours de route (ce qui serait plus dangereux, niveau deadlock) ?

    Merci.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    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 998
    Billets dans le blog
    6
    Par défaut
    Cela dépend du niveau d'isolation que vous choisissez pour la transaction que vous opérez.
    Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/isolation-transaction/
    Un SGBDR n'étant pas un OS, c'est lui qui choisit le type et la granularité des verrous on the fly en fonction de la concurrence et des opérations à réaliser... C'est le rôle du moniteur de verrouillage. Bien entendu vous pouvez forcer les verrous manuellement, mais c'est généralement source des pires contention, puisque le verrouillage n'est plus dynamique !

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

  3. #3
    Membre éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Par défaut
    Concrètement, cela veut dire qu'aujourd'hui, il ne faut absolument plus se soucier des deadlocks soi-même ?

  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 998
    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 998
    Billets dans le blog
    6
    Par défaut
    La possibilité d'obtenir des verrous mortels est lié à trois choses :
    1) le modèle de données
    2) la consistance transactionnelle
    3) la concurrence d'accès

    L'obtention d'un deadlock résulte forcément d'une opération concurrentielle lancée sur des objets identiques dont la séquence de verrouillage n'est pas la même. C'est une probabilité au sens mathématique du terme qui résulte des facteurs exposés ci dessus et pour lequel tout repose sur la durée transactionnelle. Plus une transaction dure, plus la probabilité de survenance d'un deadlock augmente.

    1) modèle :
    Si votre modèle de données respecte à la lettre les formes normale, alors cela signifie qu'aucune anomalie de mise à jour est possible et que le nombre de tuple mis à jour est minimal.
    Moins il y a de données à mettre à jour, plus rapide est la transaction.

    2) consistance
    La durée du traitement augmente en fonction du nombre d'objet présent dans la transaction, de l'étendue des mises à jour à faire et de la nature des mises à jour.

    3) concurrence
    Plus grand est le nombre d'utilisateur voulant mettre à jour la même ressource, plus probable sera le deadlock.

    SQL Server, comme tout ses compatriote analyse en permanence les verrous posés et détecte automatiquement les interblocage. Dès qu'une étreinte fatale survient, il déclenche un ROLLBACK sur le process dont le coût de requête est la plus faible.

    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 éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Par défaut
    Le ROLLBACK dont tu parles, est suivit après délais d'une nouvelle tentative ?

  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 998
    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 998
    Billets dans le blog
    6
    Par défaut
    Absolument pas. C'est à vous de détecter l'erreur et de réagir.

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

Discussions similaires

  1. [TRANSACTION] Comment ca marche ???
    Par kase74 dans le forum Débuter
    Réponses: 6
    Dernier message: 28/06/2004, 16h40
  2. [MFC] list box : comment ça marche
    Par runn2 dans le forum MFC
    Réponses: 4
    Dernier message: 28/01/2004, 12h36
  3. [SYNEDIT] -> Comment ça marche ?
    Par MaTHieU_ dans le forum C++Builder
    Réponses: 2
    Dernier message: 18/01/2004, 19h11
  4. [TP][Turbo Vision] comment ça marche ??
    Par Costello dans le forum Turbo Pascal
    Réponses: 7
    Dernier message: 05/08/2003, 00h24
  5. [update][req. imbriquee] Comment ca marche ??
    Par terziann dans le forum Langage SQL
    Réponses: 3
    Dernier message: 11/07/2003, 12h51

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