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 :

Transaction / Triggers : Juste pour être sûr [2012]


Sujet :

Développement SQL Server

  1. #1
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut Transaction / Triggers : Juste pour être sûr
    Bonjour,

    Voilà, nous avons eu une grosse maintenance au niveau de notre gestion des prix.
    Sur le principe, il n y a rien a signaler, en revanche, je dois maintenant créer les relations ventes prix rétroactivement sur les 30 dernière années.

    Si je lance ma requête d'update j'ai estimer à ~80 jours de travail non stop en me basant sur le traitement de 50'000 records.
    C'est bien évidement inenvisageable d'avoir une requête bloquante qui tourne pendant 80 jours (même 30 secondes en journée c'est trop).

    Du coup j'ai fais une mesure en désactivant tous les triggers on update de cette table. Là je descend à ~6 jours.

    Pour réglé le problème du blocage j’exécute des requêtes successives qui durent entre 2 et 4 secondes dans une séries de job du SQL Agent.
    Je n'ai malheureusement qu'un créneau de 4h par nuit ou je suis certains de pouvoir coupé les triggers sans risque.

    Je me demande donc si en englobant l'activation et la désactivation des trigger dans une même transaction, mon système restera fiable ?
    J'imagine une requête du genre :
    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
    begin transaction T1;
    disable trigger [Trigger1] on [La table des ventes];
    disable trigger [Trigger2] on [La table des ventes];
     
    WITH V AS (SELECT top 1000 IdVente,Ref,IdPrix from [La table des ventes]WHERE IdPrix is null)
    Update V SET V.IdPrix=Px.IdPrix
    FROM V
    left JOIN [Le nouveau prix] P on P.Ref=V.Ref;
     
    enable trigger [Trigger1] on [La table des ventes];
    enable trigger [Trigger2] on [La table des ventes];
     
    commit Transaction T1;
     
    GO 10000;

  2. #2
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Bonjour,
    • que font les trigger?
    • le top 1000 il est là pourquoi?
    • est ce qu'on pourrait avoir les scripts ddl des 2 tables(pk et fk incluses)?
    • AS tu des index, si oui lesquels?

    cordialement,
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  3. #3
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Citation Envoyé par Bernardos Voir le message
    Bonjour,
    • que font les trigger?
    • le top 1000 il est là pourquoi?
    • est ce qu'on pourrait avoir les scripts ddl des 2 tables(pk et fk incluses)?
    • AS tu des index, si oui lesquels?

    cordialement,
    Bonjour,
    dans l'ordre :

    Les triggers maintiennent une table de stock et une table d'erreurs de prix
    Le top 10000 est est utiliser pour subdiviser ma requête en plusieurs itérations afin d'éviter un blocage trop long.
    Malheureusement la politique de ma société m’interdit de communiquer ce genre d'information.
    Sans trop en dire, j'ai plusieurs indexes sur les références ainsi qu'un index sur IdPrix

    Je sais, ça aide pas beaucoup...

  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,

    Attention, les performances d'une BDD ne sont pas linéaires : une requete mettant à jour toute une table ne mettra probablement pas deux fois plus de temps que la même requete qui mets à jour la moitié de la table. Comment avez vous fait vos calculs ? et surtout combien de milliards de lignes avez vous dans vos tables pour en arriver à de telles durées ?

    Outre les triggers, les index peuvent ralentir la mises à jour (ou les accélérer dans certains cas, s'ils sont utiles à la requete de MAJ). Il pourrait donc être utile de faire le point sur les index sur ces tables et en désactiver certains le temps de la mise à jour. Pensez également aux vues indexées (voir les dépendances sur la table concernée pour être exhaustif)

    Ne pouvez vous pas anonymiser les noms des objets pour nous fournir les DDL ? Connaitre la structure des deux tables et les index est indispensable pour vous aider efficacement.

  5. #5
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

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

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 757
    Points : 10 695
    Points
    10 695
    Billets dans le blog
    21
    Par défaut
    Bonjour,

    Il serait effectivement intéressant d'avoir une information sur la volumétrie. Cela permettra de se faire une idée des problèmes de performances : est-ce que le traitement est long parce qu'il y a une énorme volumétrie, ou est-ce qu'il est long car les requêtes sont lentes (trop d'index à mettre à jour, ou index manquant si, comme le signalait aieeeuuuuu ils peuvent être utile lors de la mise à jour, les triggers (qui dans votre cas particulier multiplie par 10 vos temps de traitement), mauvais schéma, etc...).

    Par exemple, vous avez fait une extrapolation à partir du traitement de 50000 enregistrements. Combien de temps cela vous a-t-il pris ?

    Ensuite, je ne peux qu'approuver encore une fois ce que dis aieeeuuuuu, à savoir que le traitement n'est pas linéaire. Eventuellement, auriez-vous une base de tests sur laquelle vous pourriez faire des essais ?
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  6. #6
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Malheureusement la politique de ma société m’interdit de communiquer ce genre d'information.
    compréhensible, mais du coup ca va être plus dur pour t'aider.

    Ne pouvez vous pas anonymiser les noms des objets pour nous fournir les DDL ? Connaitre la structure des deux tables et les index est indispensable pour vous aider efficacement.
    ce serait une excellente idée! nous n'avons pas besoin de toutes les colonnes, juste celles utilisées par ta requête,participant à une clé primaire ou étrangère, et celles liées aux index . et du coup index, Clés primaires et clé étrangères.

    Ce qu'ont veut pouvoir analyser :
    • Manque de clés primaires
    • Mauvaises clés primaires
    • Manque de clés étrangère
    • une éventuelle sous indexation
    • une éventuelle sur indexation

    Cordialement,
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  7. #7
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Re,

    C'est toujours compliqué de donner suffisamment d'information pour avoir de l'aide et rester dans le clous de ce qu'on a le droit de dire.

    Il faut imaginé que tout ce qui peut être fait comme erreur (de schèma, de concepte, de designe, etc... ) ont été faite... plusieurs fois... pendant 20 ans..
    La on essai de redresser un peu la barre dans la limite du réalisable pour notre structure.

    La table de ventes contient ~60 millions de lignes, la table de prix ~3 millions.
    Mon problème de triggers est qu'ils sont cascader. On traine plusieurs années de développement hasardeux.

    Jusqu’à présent les prix étaient séparer des ventes et le seul moyen de retrouver le prix était de sélectionner le prix le plus récent pour chaque référence.
    Ce qui rend les requêtes statistiques complexes et peu fiables car les dates peuvent changer etc...
    Du coup j'ai profiter du projet de refonte des prix pour avoir une vrai relation entre la vente et le prix.

    Dans la requête d'exemple il manque des bout dans la jointure qui la rendent forcément compliqué et lente.
    La requête global serait du genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    begin transaction T1;
    disable trigger [Trigger1] on [La table des ventes];
    disable trigger [Trigger2] on [La table des ventes];
     
    Update V SET V.IdPrix=Px.IdPrix
    FROM [La table des ventes] AS V
    left JOIN [Le nouveau prix] AS P on P.Ref=V.Ref AND V.dtVente between P.DateDebut and P.dateFin AND P.TypeDuPrix = CASE [trois clauses] END
    WHERE V.IdPrix is null
     
    enable trigger [Trigger1] on [La table des ventes];
    enable trigger [Trigger2] on [La table des ventes];
     
    commit Transaction T1;
    Je n'ai pas pu tester l'Update complet sur un environnement de test car cela sature le fichier de LOG.
    Au bout de 18h le système plante et entame un rollback.
    Mon test sur 50000 lignes à mis ~4.5 minutes.
    (cependant je n'ai pas tester la totalité sans les trigger, ça tourne en ce moment même en test)

    J'ai des clé primaires simples dans mes deux tables.
    J'ai un index dans la table des ventes sur IdPrix.
    Un dans le table des prix sur Ref,DateDebut et datefin.
    Mes deux tables ont d'autres indexes sans importance dans ce contexte.

    Et les trigger contiennent tous des curseurs ce qui ralentis à mort raison pour laquelle je les désactive.

    A+

  8. #8
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

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

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 757
    Points : 10 695
    Points
    10 695
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Mon test sur 50000 lignes à mis ~4.5 minutes.
    C'est 4.5 minutes de trop ! Une mise à jour, avec une jointure et s'il y a les bons index, prend au plus 1s (et je vois large, très très large) pour ce genre de volumétrie.

    Citation Envoyé par Donpi Voir le message
    Il faut imaginé que tout ce qui peut être fait comme erreur (de schèma, de concepte, de designe, etc... ) ont été faite... plusieurs fois... pendant 20 ans..
    La on essai de redresser un peu la barre dans la limite du réalisable pour notre structure.

    La table de ventes contient ~60 millions de lignes, la table de prix ~3 millions.
    Mon problème de triggers est qu'ils sont cascader. On traine plusieurs années de développement hasardeux.
    Et la grosse difficulté va être de pouvoir t'aider sans avoir le détail de ces développements hasardeux. Le problème est visiblement dans le schéma même de la bd, avec une dette technique qui semble énorme. Hormis donner des généralités, je ne vois pas trop ce qu'il est possible de faire d'autres...

    Tu as déjà désactivé les triggers (une bonne chose), tu peux éventuellement désactiver les index impactés le temps de la requête pour les réactiver ensuite. Tu peux aussi vérifier la fragmentation de tes index. Si ça fait 20 ans qu'ils n'ont pas été défragmentés, il y a peut être des surprises de ce côté là !
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  9. #9
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Re,
    il y a un truc qui m'inquiète dans ce que tu dis. A aucun moment tu ne parles de clés étrangères (foreign Key)... rassure moi sur ce point : tu as bien des clés étrangères?
    Cordialement,
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  10. #10
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Citation Envoyé par Bernardos Voir le message
    Re,
    il y a un truc qui m'inquiète dans ce que tu dis. A aucun moment tu ne parles de clés étrangères (foreign Key)... rassure moi sur ce point : tu as bien des clés étrangères?
    Cordialement,
    ... Assied toi bien... et met ta ceinture... serre fort, ça va secouer...

    Quand j'ai commencer à travaillé ici, il n'y avait ni clé étrangères ni clé primaires.
    Cela par ce que je cite : "Les clé étrangères ça ne sert a rien et ça fait tout le temps planter les programmes".
    J'ai beaucoup ris le jour ou on m'as dit ça, ensuite j'ai pleuré, re ris et re pleurer etc...

    Bref dans le cas qui nous intéresse, il s'agit bien de créer une clé étrangère entre prix et ventes.
    Pour ce faire, j'ai une clé étrangère (ref) via la table produits et les dates.

  11. #11
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    ... Assied toi bien... et met ta ceinture... serre fort, ça va secouer...
    en règle général, quand je pose ce genre de question, je connais déjà la réponse don cj'étais déjà préparé

    "Les clé étrangères ça ne sert a rien ".
    un jour(pas très lointain) un collègue linuxien (booooooooooooooooooh non je n'ai pas de préjugé) m'expliquait que dans son précédent boulot, ils utilisaient une base sql server, pour laquelle un "décideur" (probablement un vieux cobolosiste) avait dit qu'il était interdit de faire des clés étrangères, primaires etc... que tout devait se faire au niveau applicatif....
    Là je m'insurge et je luis dis que c'est n'importe quoi...et la réponse :" mais ca fonctionnait très bien..." Je suis très curieux d'aller voir plusieurs années plus tard comment sa fonctionne bien et l'intégrité des données.

    Autre petite anecdote, dans mon premier boulot, j'étais analyse programmeur en delphi(et on ne rit pas dans la salle ) sous sql server (6.5). Le directeur informatique était justement un vieux coboliste qui disait pareil. pour lui les clés primaires, étrangères etc... ca n'était que des emmerdes. il disait que le relationnel était une mode comme une autre et que ca passerait... mdr...
    ben là du haut de mes 25 ans, j'ai rassemblé tous mes collègues dont 1 ou 2 qui avaient de la bouteille et on lui a préparé une démonstration... ben tu sais quoi, le mec il a été convaincu.
    et ça fait tout le temps planter les programmes
    Alors ca c'est plutot un truc de dévellopeur, que ca fait chier de devoir respecter les contraintes d'intégrité, parceque c'est chiant qu'on peut pas créer la ligne

    et le corolaire de tout ca, c'est que je te dirais bien d'ajouter les clés étrangères (d'ailleurs je pense que tu n'as pas le choix) par contre, en 20 ans, à mon avis tu vas avoir un paquet d'incohérence à gérer.

    Pour ce faire, j'ai une clé étrangère (ref) via la table produits et les dates.
    tu as déjà ajouté la foerign key ou tu vas le faire?

    cordialement,
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  12. #12
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

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

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 757
    Points : 10 695
    Points
    10 695
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Quand j'ai commencer à travaillé ici, il n'y avait ni clé étrangères ni clé primaires.
    Cela par ce que je cite : "Les clé étrangères ça ne sert a rien et ça fait tout le temps planter les programmes".
    J'ai beaucoup ris le jour ou on m'as dit ça, ensuite j'ai pleuré, re ris et re pleurer etc...
    Tiens, j'ai connu ça sur un projet que j'ai repris ! Et je suis sur que tu avais aussi des données dupliquées parce que "ça va plus vite, ça évite des jointures"

    En tout cas, je comprends un peu mieux les problèmes de perf... (je ne suis plus du tout étonné !).

    Si vraiment les perfs sont un problème, il serait plus que temps d'envisager de faire une auscultation complète de la base de données, ne serait-ce que pour respecter les principes de base...
    Non seulement vous y gagneriez en rapidité, mais aussi en cohérence (sans clé étrangère pendant 20 ans, cela m'étonnerait qu'il n'y ait pas de données perdues qui trainent...). Après, ce n'est pas toujours évident si plusieurs applications utilisent la même base de données, mais il est possible de réaliser une couche de compatibilité à base de vues...
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  13. #13
    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
    Citation Envoyé par Donpi Voir le message
    Un dans le table des prix sur Ref,DateDebut et datefin.
    Il serait certainement utile d'y ajouter, au moins en colonne incluse, la colonne "TypeDuPrix" afin de couvrir la condition de jointure.
    Il faut aussi vérifier qu'il est en bon état (fragmentation, stats à jour)

    Concernant l'index sur IdPRix dans la table des ventes, il devra être mis à jour lors de la requete UPDATE en question, mais peut cependant aider (cf la clause WHERE).

    Qu'est ce que ça donne en le désactivant ?
    et en le remplaçant par un index filtré WHERE idPrix IS NULL ?

  14. #14
    Membre éclairé
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    Décembre 2007
    Messages
    327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : Décembre 2007
    Messages : 327
    Points : 674
    Points
    674
    Par défaut
    ça me fait penser a des contexte que j'ai rencontrés en audit votre probleme ...

    Effectivement je pense qu'il y a un gros probleme de modélisation et après comme il a déjà été dit.

    Supprimez les index(s) et identifiés les index(s) nécessaire pour la réalisaiton de votre update ...

    Au hasard je metterai les index(s) suivants :

    table des ventes :
    • IdPrix
    • Ref
    • dtVente




    table des nouveaux prix
    • IdPrix
    • Ref
    • DateDebut
    • dateFin
    • TypeDuPrix filtré sur les 3 clauses



    Objectif realiser des index couvrants permettant de diminuer le nombre de lecture logique et optimiser au maximum la mise a jour.


    Après dans second temps mon chantier serais :

    1. Travailler sur la modélisation
    2. Optimiser le Plan de maintenance ( comme il a été dit taux de fragmentation des index(s) exsistant ? Mise a jour des stats ... ) Bref il y a du boulot
    3. Documenter
    4. Former les utilisateurs et réaliser des points d'avancement régulier



    Bon courage
    MCSA SQL SERVER |MCT | MVP Data Platform

  15. #15
    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
    Question bête, qui vaut le coup d'être posée : avez vous vérifié le plan d’exécution ?

    En plus des choses habituelles, vous pourriez y débusquer - notamment après 20 ans de développement - quelques surprises auxquelles vous ne pensez pas :

    - actions déclenchées par des trigger auxquels vous n'auriez pas pensé
    - mise à jour d'index auxquels vous n'auriez pas pensé non plus, comme par exemple sur des colonnes calculées s'appuyant sur le prix, ou sur des vues indexées...

  16. #16
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    Par défaut
    Je me permets de recentrer la discussion sur la question originale telle que je la comprends et qui m'intéresse à titre de culture générale :
    Citation Envoyé par Donpi Voir le message
    Je me demande donc si en englobant l'activation et la désactivation des trigger dans une même transaction, mon système restera fiable ?
    Je comprends que vous souhaitez désactiver les triggers juste pour votre session (au sein de votre transaction) afin de passer les updates aussi en journée, mais sans impacter les applications de production qui continueront à exécuter le code du trigger, est-ce bien ça ?

    Je ne connais pas vraiment sqlserver, je ne peux donc pas être catégorique sur l'approche de désactivation au sein de la transaction.
    Mais je ne pense pas que ce soit possible (sur Oracle ça ne fonctionnerait pas), il faut a priori plutôt modifier le code du trigger pour lui permettre de ne pas s'exécuter dans un contexte particulier :
    https://www.mssqltips.com/sqlservert...nt-or-session/

    Je laisse les experts sqlserver donner leurs avis plus avisés que le mien.

  17. #17
    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
    En relisant, je me rend compte que quelque chose ne va pas !

    pourquoi une jointure externe sur la table des prix ?
    1/ s'il n'y a pas de correspondance, alors l'UPDATE ne fera que remplacer NULL par... NULL, ce qui manque certainement d’intérêt
    2/ pire, cela signifie que certaines lignes resteront a NULL, et seront donc traitée à chacune de vos boucles. En clair, si vous avez lancé 50 fois votre boucle pour votre test sur 50000 lignes, il se peut que ayez mis à jour 50 fois les mêmes lignes...

    donc, remplacez par une jointure interne, et reposez vous sur un autre critère de "partitionnement" comme par exemple en effectuant sur des plages de valeurs de la colonne Ref.

    Par ailleurs, toujours d'un point de vue logique, et vue la situation que vous décrivez, il est fort probable que la jointure trouve parfois de multiples correspondance. N'avez vous pas de règle de gestion à implémenter dans ce cas pour le choix du bon IdPrix ?



    Par curiosité, que donne une simple requete SELECT en temps d’exécution :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    SELECT V.idPRix, P.idPrix
    FROM [La table des ventes] AS V
    left JOIN [Le nouveau prix] AS P on P.Ref=V.Ref AND V.dtVente between P.DateDebut and P.dateFin AND P.TypeDuPrix = CASE [trois clauses] END

  18. #18
    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
    Citation Envoyé par skuatamad Voir le message
    Je me permets de recentrer la discussion sur la question originale telle que je la comprends et qui m'intéresse à titre de culture générale :
    C'est vrai que cette question pourtant intéressante était passée à l'as

    Citation Envoyé par skuatamad Voir le message
    Je ne connais pas vraiment sqlserver, je ne peux donc pas être catégorique sur l'approche de désactivation au sein de la transaction.
    Mais je ne pense pas que ce soit possible (sur Oracle ça ne fonctionnerait pas), il faut a priori plutôt modifier le code du trigger pour lui permettre de ne pas s'exécuter dans un contexte particulier :
    https://www.mssqltips.com/sqlservert...nt-or-session/
    sous SQL Server, il est possible de placer du code DDL dans une transaction. (tant que la cible reste au sein de la base de données)

    Pour répondre donc à la question, il est en effet possible de désactiver le déclencheur le temps de la transaction. Cela aura pour effet de poser un verrou de modification de schéma sur la table, empêchant par ailleurs toute opération sur celle-ci (y compris un simple SELECT même en READ UNCOMMITTED, puisqu'il sera alors impossible d'acquérir un verrou de stabilité de schéma).
    De fait, l’intégrité sera donc assurée.

  19. #19
    Membre éclairé
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    Décembre 2007
    Messages
    327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : Décembre 2007
    Messages : 327
    Points : 674
    Points
    674
    Par défaut
    Et avec ce select que donne le plan d'execution ?
    MCSA SQL SERVER |MCT | MVP Data Platform

  20. #20
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    Pour répondre donc à la question, il est en effet possible de désactiver le déclencheur le temps de la transaction. Cela aura pour effet de poser un verrou de stabilité de schéma sur la table, empêchant par ailleurs toute opération sur celle-ci (y compris un simple SELECT même en READ UNCOMMITTED, puisqu'il sera alors impossible d'acquérir un verrou de modification de schéma).
    De fait, l’intégrité sera donc assurée.
    Merci pour l'info bien détaillée.
    Du coup je comprends mieux pourquoi personne n'abordait ce sujet

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

Discussions similaires

  1. [2008R2] Transact-SQL, syntaxe pour interruption d'un trigger.
    Par XDeus dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 26/03/2014, 18h33
  2. trigger delete pour plusieurs lignes
    Par Shabata dans le forum Langage SQL
    Réponses: 6
    Dernier message: 30/09/2009, 02h00
  3. Juste pour savoir qu'elle direction je dois prendre
    Par Antoine1183 dans le forum VB 6 et antérieur
    Réponses: 5
    Dernier message: 09/08/2005, 21h03
  4. [xsl] xsl juste pour faire copie d'un xml
    Par peppena dans le forum XSL/XSLT/XPATH
    Réponses: 4
    Dernier message: 17/02/2004, 17h17
  5. Réponses: 2
    Dernier message: 21/03/2002, 00h01

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