Discussion :

[vinch999]

Bonjour,
Je me pose une question que voici:

Ma table est un listing de personnes avec leurs propriétés.

Exemple de schema pour la table personne:
personne_id (PK), pr_1_id (FK), pr_2_id (FK)

Est-il possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE personne SET pr_1_id =10 WHERE personne_id =1

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE personne SET pr_2_id =50 WHERE personne_id =1

simultanément?

J'imagine qu'il y a une table lock lors de l'exécution du premier update et que de ce fait le second UPDATE ira en ERROR ,est-ce bien le cas?
Si oui, existe-il un moyen de contourner, sans risque?
Mon objectif est d'augmenter les perfs d'intégration de données en exécutant des jobs écrivant (update) dans la même table, en // .

Merci d'avance pour l'aide .

[Waldar]

La virgule est votre amie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
UPDATE personne
   SET pr_1_id     = 10
     , pr_2_id     = 50
 WHERE personne_id = 1;

[SQLpro]

Est-il possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE personne SET pr_1_id =10 WHERE personne_id =1

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE personne SET pr_2_id =50 WHERE personne_id =1

simultanément?

Oui

J'imagine qu'il y a une table lock lors de l'exécution du premier update et que de ce fait le second UPDATE ira en ERROR ,est-ce bien le cas?

Vous imaginez mal... Il y a effectivement un verrou posé par chacune des sessions. Donc l'un attendra que l'autre finisse et les commandes s’exécuteront en séquence.

Si oui, existe-il un moyen de contourner, sans risque?

heureusement non !!!

Mon objectif est d'augmenter les perfs d'intégration de données en exécutant des jobs écrivant (update) dans la même table, en // .

Faites des tests !

A +

[vinch999]

La virgule est votre amie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
UPDATE personne
   SET pr_1_id     = 10
     , pr_2_id     = 50
 WHERE personne_id = 1;

Si seulement je pouvais faire ça...

[vinch999]

Vous imaginez mal... Il y a effectivement un verrou posé par chacune des sessions. Donc l'un attendra que l'autre finisse et les commandes s’exécuteront en séquence.

Ok merci pour l'info c'est ce point qui m'inquiétait.

[SQLpro]

Si seulement je pouvais faire ça...

Qu'est ce qui vous en empêche ?

A +

[Waldar]

Je n'y avais pas réfléchi, mais je suppose qu'il s'agit de deux transactions distinctes par deux personnes distinctes dans une application ou deux jobs différents.

[vinch999]

Pour clarifier, j'effectue ces updates via des jobs TALEND. je ne peux pas merger les updates...
Je veux améliorer les perfs d'exécution des jobs en les parallélisant.
Et j'arrive donc potentiellement à cette problématique.

[Waldar]

Alors un conseil tiré de mes quinze ans de développement ETL : une même table ne doit être modifiée que par un ou un seul job (mapping, module, process).
Faites le travail nécessaire en amont, revoyez éventuellement votre modélisation mais ne passez pas deux fois sur la même table en écriture.

J'exclue de cette affirmation les tables de log et de paramétrages.

[vinch999]

Tu parles bien dans le cadre de la parrallélisation je suppose?

Donc tu me déconseilles, d'exécuter en // 2 jobs qui doivent faire des updates dans une même table.
Pourquoi? A ton avis, en cas de concurrence, la ligne bloquée serait rejetée et donc pas traitée?

[Waldar]

Non, principalement parce que vous n'agissez pas sur votre table cible de manière ensembliste.

J'ai réalisé une mission d'optimisation sur l'alimentation d'un datamart qui durait plus de 12h, un contexte BI donc.

Il était disponible pour les utilisateurs vers 16h ce qui n'était pas vraiment pratique.
La personne qui l'avait implémentée ne construisait pourtant que deux tables agrégées avec au total une dizaine de métriques.

Sauf que sa méthode d'alimentation faisant une insertion de tous les axes d'analyse, puis une deuxième passe avec le calcul d'un indicateur qui du coup était alimenté à coup d'update (avec des boucles bien entendu), puis un troisième module avec le calcul d'un autre indicateur, et cetera.

J'ai écrit une seule requête SQL qui faisait d'office tout le boulot : une vue, un insert, pas d'update avec un peu de modélisation pour que ce soit possible et au passage un peu de compression et de partitionnement (sur Oracle 10g).

Temps d'exécution après mon intervention : trente minutes pour un calcul complet du datamart et deux minutes en alimentation quotidienne.

Les utilisateurs qui étaient avertis par mail à la fin du chargement ont d'abord pensé qu'il s'agissait d'un bug quand ils ont reçu les mails à 4h du matin au lieu de 16h.

[SQLpro]

... vous n'agissez pas sur votre table cible de manière ensembliste.

J'ai réalisé une mission d'optimisation ...

Les utilisateurs qui étaient avertis par mail à la fin du chargement ont d'abord pensé qu'il s'agissait d'un bug quand ils ont reçu les mails à 4h du matin au lieu de 16h.

C'est un grand classique. Mais comme on enseigne plus ce que sont les opérations ensemblistes, alors on repart sur les imbécilités itératives !!!!

A +

[vinch999]

Merci pour ces infos.
Autre Question: Existe-il un timeout lorsque l'on tente un update mais que la table est lockée?

Je viens de tenter pour le fun d'exécuter les 2 jobs en // , le 2eme ne fait rien tant que l'autre job n'a pas terminé ses updates. Dès que le 1er a terminé , le 2eme commence.
Cela semble fonctionner mais y a-t-il selon vous un risque que le second job crash car il aurait du attendre trop longtemps? (je sais pas si je suis assez clair ) .

Ca m'arrangerait de laisser ces 2 jobs en // car ils travaillent également sur des tables qui elles sont indépendantes. J'ai donc tout de même un certain gain de perf.
(Je deviens un peu hors scope du sujet de base donc si je dois aller recréer un sujet autre part pas de problème.)

[SQLpro]

Existe-il un timeout lorsque l'on tente un update mais que la table est lockée?

Cela dépend de votre application. Le timeout peut être défini par défaut à une valeur (par exemple 30 secondes) comme mise en attente infinie.

y a-t-il selon vous un risque que le second job crash car il aurait du attendre trop longtemps? (je sais pas si je suis assez clair ) .

D'un point de vue transactionnel, il n'y a jamais de crash, même en cas de panne de la machine (arrêt brutal, coupure électrique, CPU qui flambe....) sauf à perdre le fichier du journal des transactions. Donc, soit la seconde transaction est finalisée par un COMMIT ou un ROLLBACK, soit elle est en attente de libération des ressources de la première.

A +

[vinch999]

Après réflexion, pour contourner le problème de parallélisme, j'ai stocké les résultats à updater dans des fichiers temporaires (écriture sur le disque, pas top mais pas d'autre choix) plutôt que d'updater directement.

Ensuite je merge tous les fichiers dans le but d'updater chaque entrée une seule fois. Cela semble performant.

[SQLpro]

C'est déjà mieux ! L'idéal serait de "merger" les requêtes pour n'avoir grosso modo plus qu'une seule requête par table.....

A +