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

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut Isolation transactionnelle ne bloquant pas les écritures

    Bonjour à tous,
    Je pensais avoir trouvé la solution à mon problème avec le niveau d'isolation transactionnel SNAPSHOT. Mais c'est encore pire. Sûrement que je ne fais pas quelque chose correctement

    Mon problème en question :
    J'écris dans une table à une cadence d'une ligne par seconde.
    De temps à autres, j'interroge cette table avec des requêtes assez lourdes, ce qui fait que l'écriture est bloquée pendant quelques secondes. Je me retrouve donc avec des trous qui peuvent aller jusqu'à 4 ou 5 secondes.
    J'ai compris que le niveau d'isolation SNAPSHOT permettait de ne pas bloquer les écritures.
    https://docs.microsoft.com/fr-fr/sql...ql-server-2017

    Après avoir modifié la base :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ALTER DATABASE DBName SET ALLOW_SNAPSHOT_ISOLATION ON,
    et vérifié :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT name, snapshot_isolation_state_desc from sys.databases where name = 'DBName'
    Je lance la requête :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT champs FROM TableName SNAPSHOT WHERE prédicat ORDER BY ordre ASC;
    Ca ne change rien, ça freeze les écritures sur TableName

    Si quelqu'un pouvait me dire ce que je ne fais pas correctement...
    Pas changer assiettes pour fromage.

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    19 003
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 003
    Points : 44 655
    Points
    44 655

    Par défaut

    Tout simplement parce que le niveau d'isolation par défaut est READ COMMITTED.

    En lançant la commande :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ALTER DATABASE DBName SET ALLOW_SNAPSHOT_ISOLATION ON;
    Vous n'avez fait qu'autoriser d'utiliser le niveau d'isolation SNAPSHOT ce qui est un premier pas.

    Pour ensuite passer au mode d’isolation SNAPSHOT, il faut lancer la commande :
    SET TRANSACTION ISOLATION SNAPSHOT;
    avant de lancer votre requête, afin que votre session soit placée dans ce mode d’isolation.

    Vous pouvez encapsuler le tout dans une procédure stockée...

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Oups , en fait, j'ai bien lancé
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    SET TRANSACTION ISOLATION SNAPSHOT;
    avant de faire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    SELECT champs FROM TableName SNAPSHOT WHERE prédicat ORDER BY ordre ASC;
    J'ai juste oublié de l'écrire dans le msg.
    Comme punition, je vais tout vérifier, ça m'apprendra.
    Pas changer assiettes pour fromage.

  4. #4
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    J'ai bien fait de vérifier , il n'en veut pas de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SET TRANSACTION ISOLATION SNAPSHOT;
    Ni dans Delphi, ni dans MSM. Il renvoie une erreur de syntaxe
    Pas changer assiettes pour fromage.

  5. #5
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Ah ben d'accord, il faut faire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT
    Sûr d'avoir pris ça sur le site de MS
    Bon, j'essaie...
    Pas changer assiettes pour fromage.

  6. #6
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Pour être sûr que le cache est bien vide :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    DBCC DROPCLEANBUFFERS;
    DBCC FREEPROCCACHE;
    Bon ben... le SET
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
    puis le select sur la table dans laquelle une autre transaction écrit toutes les secondes.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    SELECT *
    FROM NOMTABLE SNAPSHOT
    WHERE PREDICAT
    ORDER BY ORDER
    Donc
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    DBCC DROPCLEANBUFFERS;
    DBCC FREEPROCCACHE;
     
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
     
    SELECT *
    FROM NOMTABLE SNAPSHOT
    WHERE PREDICAT
    ORDER BY ORDER
    Le select dure plus d'une minute, et bloque les écritures. Le résultat est le même que sans LEVEL SNAPSHOT

    Je ne sais pas ce que je ne fais pas bien.
    Pas changer assiettes pour fromage.

  7. #7
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    J'ai fini par me dire qu'il n'y a pas de miracle, il lui faut le temps de ramener les données. Plus de 80000 lignes.

    Mais non, j'ai essayé, cette fois sans vider le cache,
    de ne changer que le prédicat. Il ne ramène donc pas les mêmes lignes (mais le même nombre environ 80000).
    Le select ne prend qu'une seconde !

    C'est donc (ou pas) l'établissement du plan de requête qui prend du temps (ou pas).
    Est-ce que ce que je viens d'écrire a un quelconque lien avec la réalité ?
    Pas changer assiettes pour fromage.

  8. #8
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    19 003
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 003
    Points : 44 655
    Points
    44 655

    Par défaut

    Vider le cache pour faire des tests est une idée absurde car un SGBDR effectue tous ses traitements en mémoire !

    je comprends mal ce que vous voulez faire...

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #9
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Très simple, je veux être sûr que ma requête de lecture ne gèle jamais les écritures dans la table.
    Je dois donc m'affranchir de l'optimisation de SQLServer, qui fausse mes essais.
    Car celle-ci permet, en effet, d'exécuter cette requête instantanément, mais pas toujours. Si je relance la lecture quelques heures plus tard, elle gèle à nouveau les écritures.

    Je dois donc trouver le moyen d'exécuter cette lecture de façon à ne pas geler les écritures, et pour être sûr de la validité du résultat, je dois m'affranchir de l'optimisation du système.

    L'isolation SNAPSHOT, d'après sa description, donnerait la solution à mon problème. Mais il y a manifestement quelque chose que je ne fais pas, car les écritures sont gelées de la même manière que par défaut.

    PS: La table contient 16 millions de lignes...
    Pas changer assiettes pour fromage.

  10. #10
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    19 003
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 003
    Points : 44 655
    Points
    44 655

    Par défaut

    Vous n'avez donc pas du tout compris comment fontionnait un SGBDR car le fait de vider le cache ne sert strictement à rien dans ce cas (sinon pourrir les performances)
    En effet les écritures de données sont toujours logique (donc en mémoire) lors de l'exécution d'une requête, c'est à dire que seule la mémoire est mise à jour et non le disque.
    Les données ne seront physiquement écrites sur les disques que de temps à autres au bon vouloir de SQL Server !

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  11. #11
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Donc, je vais essayer de reformuler :
    J'ai une table dans laquelle est écrite une ligne par seconde. A l'heure actuelle, cette table contient 16 millions de lignes.
    De façon totalement aléatoire, en fonction des besoins, cette table est interrogée par une requête qui dure 30s.
    Cette requête bloque les écritures dans la table. SAUF, quand elle est relancée peu de temps après, car, du coup, elle est quasi instantanée. Mais quand elle est relancée plusieurs heures plus tard, elle re-bloque les écritures.
    Jusque là, aucun besoin de connaissance particulière pour comprendre.

    Je dois donc trouver un moyen de faire en sorte que l'interrogation de cette table ne bloque JAMAIS les écritures dans la table. (Là débute l'aventure).

    {mise au point avant de continuer l'aventure
    Afin de faire mes essais, je vide EVIDEMMENT le cache avant de lancer le select en question.
    Car je constate, n'en déplaise aux spécialistes, que la requête dure toujours environ 30s après vidange du cache, sans la vidange du cache, elle est instantanée (je précise tout de suite que cela me semble tout à fait naturel).
    Ce qui me permet donc de m'affranchir de l'optimisation, pour valider mes essais.
    }
    reprise de l'aventure :
    Mes essais en question concerne la tentative d'utiliser l'isolation transactionnelle SNAPSHOT qui, d'après la doc, ne bloque pas les écritures.

    Là où en j'en suis :
    Après avoir fait :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ALTER DATABASE DBName SET ALLOW_SNAPSHOT_ISOLATION ON;
    Je lance :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    DBCC DROPCLEANBUFFERS;
    DBCC FREEPROCCACHE;
     
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
     
    SELECT *
    FROM NOMTABLE SNAPSHOT
    WHERE PREDICAT
    ORDER BY ORDER
    (Et donc, bien pris soin de vider le cache afin de ne pas me faire berner par l'optimisation du système, qui ferait que ma requête soit instantanée)
    Cette requête dure environ 30s et bloque les écritures, comme avec l'isolation par défaut

    Je n'ose pas poser de question précise, mais si quelqu'un pouvait m'expliquer pourquoi il n'y a pas de différence dans le comportement de SQLServer, j'en connais au-moins un qui serait très intéressé. Mille fois merci d'avance.
    Pas changer assiettes pour fromage.

  12. #12
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    19 003
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 003
    Points : 44 655
    Points
    44 655

    Par défaut

    Ce que vous faites est stupide et n'a aucun intérêt en pratique. Vous conclusions sont donc à côté de la plaque et ne montrent rien du tout.

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  13. #13
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 679
    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 : 4 679
    Points : 11 892
    Points
    11 892
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par cestpasmoinonplus Voir le message
    Donc, je vais essayer de reformuler :
    J'ai une table dans laquelle est écrite une ligne par seconde. A l'heure actuelle, cette table contient 16 millions de lignes.
    De façon totalement aléatoire, en fonction des besoins, cette table est interrogée par une requête qui dure 30s.
    Cette requête bloque les écritures dans la table. SAUF, quand elle est relancée peu de temps après, car, du coup, elle est quasi instantanée. Mais quand elle est relancée plusieurs heures plus tard, elle re-bloque les écritures.
    Jusque là, aucun besoin de connaissance particulière pour comprendre.
    Il faut au contraire des explications complémentaires, si la durée d'exécution change, c'est que le contexte change.
    • d'autres threads concurrents sont parfois actifs en plus de ceux vous mentionnez
    • la charge CPU ou la RAM disponible ne sont pas au même niveau entre les deux exécutions
    • la table est partitionnée en fonction du créneau horaire, différer la lecture permet de consulter une partition sur laquelle il n'y a pas d'écriture sauf si on attend trop longtemps et que du coup on boucle sur le même créneau horaire
    • ou tout simplement, quand la lecture se passe bien, il n'y a plus d'écriture concurrente
    • ...

  14. #14
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Ok.
    En tout cas, il faut que je sois sûr que la lecture ne freeze pas la table. Ce qui est systématiquement le cas quand la requête est relancée après un certain temps.
    D'où mon intérêt pour l'isolation SNAPSHOT.
    Donc si quelqu'un ayant déjà usité cet isolation passait dans le coin, je lui serais très reconnaissant de m'expliquer ce qui ne va pas dans ce que je fais.
    Pas changer assiettes pour fromage.

  15. #15
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 802
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 802
    Points : 5 496
    Points
    5 496

    Par défaut

    Je n'utilise pas Sqlserver, mais je me demande s'il ne vous manque pas juste un begin transaction :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
    GO
    BEGIN TRANSACTION;
    GO
    SELECT *
    FROM NOMTABLE SNAPSHOT
    WHERE PREDICAT
    ORDER BY ORDER;
    GO
    COMMIT TRANSACTION;
    GO
    Vous pouvez aussi regarder du côté du paramètre READ_COMMITTED_SNAPSHOT.
    Choosing Row Versioning-based Isolation Levels

  16. #16
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    En fait je lance les requêtes, pour l'instant, directement depuis MSM studio et non depuis une procédure stockée.
    Ce qui explique l'absence des bornes.
    Merci pour ton observation.

    You knnow what ? Je crois que je vais essayer avec une procédure stockée. Qui sait quel comportement je vais en tirer ? Peut-être pas grand monde
    Pas changer assiettes pour fromage.

  17. #17
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Citation Envoyé par skuatamad Voir le message
    Vous pouvez aussi regarder du côté du paramètre READ_COMMITTED_SNAPSHOT.
    Choosing Row Versioning-based Isolation Levels

    Oui, tout à fait, j'y ai pensé, et j'ai même mis la base de donnée en READ_COMMITTED_SNAPSHOT .
    Sans changement. (dans le contexte de mes essais foireux )
    Pas changer assiettes pour fromage.

  18. #18
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Non, pareil via une procédure stockée
    Pas changer assiettes pour fromage.

  19. #19
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 855
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 855
    Points : 15 611
    Points
    15 611

    Par défaut

    Si vous avez confiance dans vos inserts, faites des dirty read avec nolock.
    Considérez que votre requête a 0,00x% de marge d'erreur.

    C'est le meilleur mauvais conseil que je puisse vous donner.

  20. #20
    Nouveau membre du Club
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    janvier 2019
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2019
    Messages : 165
    Points : 39
    Points
    39

    Par défaut

    Merci Waldar, c'est un si bon conseil que j'avais commencé par là car ça je pourrais me contenter du résultat.
    Mais ça bloque les écritures, (je n'y puis rien ).
    Ca fait des trous de 10, 12, 4, 2, 4, 3, 2, 2, 2 secondes avant de revenir à 1 seconde. Bien sûr ça varie légèrement à chaque fois.
    En fait ça donne le même résultat que sans nolock.

    Il y a peut-être un problème de configuration de la base...
    Pas changer assiettes pour fromage.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Réponses: 0
    Dernier message: 06/04/2015, 13h35
  2. Soit la lecture, soit l'écriture,.. pas les deux!
    Par kenny49 dans le forum Fonctions
    Réponses: 2
    Dernier message: 06/03/2007, 00h48
  3. probleme avec requete sql aime pas les strings
    Par lil_jam63 dans le forum Bases de données
    Réponses: 3
    Dernier message: 24/02/2004, 14h45
  4. TASM ne connaît pas les registres FS et GS
    Par forthx dans le forum Assembleur
    Réponses: 4
    Dernier message: 07/06/2003, 00h56

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