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 :

Cursor lock de table [2016]


Sujet :

Développement SQL Server

  1. #1
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Février 2004
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Service public

    Informations forums :
    Inscription : Février 2004
    Messages : 477
    Points : 223
    Points
    223
    Par défaut Cursor lock de table
    Bonjour à tous,

    Je ne suis pas certain mais j'ai le sentiment que dans l'utilisation de mon curseur je LOCK les tables qui sont utilisées dans celui-ci.
    Est ce que c'est possible ? Si oui, comment est ce qu'on résout ce problème.

    Pour info, dans mon curseur je fais ceci:

    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
     
     
     OPEN c_cursor_cpt
          FETCH NEXT FROM c_cursor_cpt INTO @cpt_id
     
          -- Pour chaque compteur
          -- --------------------
          WHILE @@FETCH_STATUS = 0
          BEGIN
     
                SELECT * FROM xxxx
     
                SELECT * FROM xxxx
     
                IF xxxxxxx 
                BEGIN 
     
                INSERT INTO xxxxx
     
                END
     
    FETCH NEXT FROM c_cursor_cpt INTO @cpt_id

  2. #2
    Invité
    Invité(e)
    Par défaut
    il y a 99.9 % de chance que vous pourriez vous passez d'un cursor en réécrivant votre code

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 086
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 086
    Points : 38 378
    Points
    38 378
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Le type de verrouillage dépend du déclare cursor. S'il est "for read only" les threads concurrents peuvent lire les tables.
    Ensuite, il faut vérifier le type d'isolation de la transaction, si vous êtes en "UR" (très peu probable), aucun verrou n'est posé, sinon consultez la documentation ici

    Les verrous liés au curseur sont libérés au CLOSE CURSOR ou au COMMIT ou ROLLBACK de la transaction.

    J'ose espérer que le SELECT * dans le curseur n'est pas conforme à la réalité

    Et, comme suggéré par 7gyY... si vous pouvez vous passer d'un curseur, ce sera beaucoup, beaucoup, mais alors beaucoup plus rapide !

  4. #4
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Février 2004
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Service public

    Informations forums :
    Inscription : Février 2004
    Messages : 477
    Points : 223
    Points
    223
    Par défaut
    J'entends de plus en plus qu'il faut réécrire les procédure stockée avec un curseur.
    Mais je me pose alors la question, pourquoi Microsoft prévoit les curseurs si au final on ne les utilise pas ?

    J'ose espérer que le SELECT * dans le curseur n'est pas conforme à la réalité
    Non bien entendu c'était uniquement à titre d'exemple.

    Voici comment je fais le déclare de mon curseur:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    DECLARE
                   c_cursor_cpt CURSOR FOR
                      SELECT compteur_id FROM @cpt_table
    Du coup là est ce que je suis en "for read only" ?

  5. #5
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Pfeffer Voir le message
    J'entends de plus en plus qu'il faut réécrire les procédure stockée avec un curseur.
    Parce que c'est le MAL ! Il y a plein d'exemples sur les internets qui montrent comment ça plomble énormément les performances
    Par exemple : https://www.sqlshack.com/using-sql-s...disadvantages/
    Citation Envoyé par Pfeffer Voir le message
    Mais je me pose alors la question, pourquoi Microsoft prévoit les curseurs si au final on ne les utilise pas ?
    J'imagine que 1) c'est dans la norme SQL et 2) il y a quelques cas où on ne peut pas s'en passer (requête dynamique sur plusieurs bases de données)

  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
    Par défaut les curseur sont ouvert dans le pire des modes :
    live sur les données, donc verrous
    mise à jour possible à travers le curseur
    curseur scrollable
    scope à travers les routines


    Généralement un curseur :
    LOCAL FORWARD_ONLY STATIC READ_ONLY
    Suffit et économise des ressources et des verrous

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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 10/06/2011, 10h59
  2. Alter Constraint et lock des tables
    Par elkamaro dans le forum Administration
    Réponses: 7
    Dernier message: 04/01/2011, 15h44
  3. Réponses: 0
    Dernier message: 29/01/2010, 16h15
  4. Lock de table et SQL Management studio
    Par The eye dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 21/08/2007, 18h30
  5. Thread et lock de tables
    Par babylone7 dans le forum Oracle
    Réponses: 6
    Dernier message: 27/06/2006, 18h31

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