Discussion :

[LEK]

Bonsoir,
je viens de parcourir la traduction d'un article de ce monsieur sur le site de Pachot concernant les traitements batch pour les mises à jour de données en masse... J'ai envoyé quelques questions à l'auteur restées sans réponses (pour l'instant) aussi je voulais vous les soumettre :
L'article affirme :

Les update (et delete) de masse sont à proscrire

La question que je me pose est donc comment faire sans.

Les techniques utilisées par l'auteur (d'après son blog) :

Instead of bulk UPDATES/DELETES, use set theory to create the compliment via CTAS (or similar). That is, for DELETE recreate what you want to keep, for UPDATE, recreate with the modifications.

There are a few reasons for this:
1) Compression – UPDATES/DELETES are more expensive with compression and they generally leave the data in a much less compressed format
2) Logging – Both UPDATE and DELETE are logging operations and a NOLOGGING CTAS or INSERT /*+ APPEND */ are not.

As a result, it is often faster and better (from a compression point of view) to recreate the segment.

Savez vous comment mettre en oeuvre ces techniques ?
Mais si on a une base opérationnelle de production avec potentiellement un utilisateur loggué
peut-on se permettre ce genre de manoeuvre...
Ou trouver un exemple de ces utilisations pour mises à jour en masse ?

" j’ai codé complètement un flux de donnée qui travaille de manière ensembliste, avec juste une poignée de requêtes SQL (et pas de PL/SQL). "

J'imagine qu'il se retrouve avec un seul upsert au final, mais comment traite-t-il ses erreurs potentielles ?
Comment récupère-til les lignes en erreur ?

Merci pour votre avis sur la question,
Lek.

[pachot]

Bonjour,

Le mieux est de mettre un commentaire dans le blog

J'essaierai de détailler plus tard, mais les idées sont:

Au lieu d'un delete ou d'un update -> créer une nouvelle table avec seulement les données voulues (CREATE TABLE AS SELECT)

Au lieu d'inserts ligne à ligne -> inserts en bulk (INSERT /*+ APPEND */)

Pour la gestion d'erreur: soit faire un select avant pour vérifier les données, soit utiliser DML error logging ( INSERT ... LOG ERRORS INTO )

Mais si on a une base opérationnelle de production avec potentiellement un utilisateur loggué

Non. Personne ne doit lire dans la base cible pendant qu'on charge avec ces techniques.

Cordialement,
Franck.

[mnitu]

...
Pour la gestion d'erreur: soit faire un select avant pour vérifier les données, soit utiliser DML error logging ( INSERT ... LOG ERRORS INTO )
...

Vous devez être très à la bourre ce matin pour dire ça.

[pachot]

@mnitu
Pas compris la dernière remarque.

Pour préciser: le contexte est le chargement massif batch/datawarehouse.
Il vaut parfois mieux lire les données une première fois en bulk pour les valider, et/ou pour mettre à jour les dimensions avant de charger les faits, plutôt que de faire du traitement ligne à ligne avec rejets, rollbacks, etc.
Cordialement,
Franck.

[skuatamad]

Mais si on a une base opérationnelle de production avec potentiellement un utilisateur loggué

Non. Personne ne doit lire dans la base cible pendant qu'on charge avec ces techniques.

Ou utiliser le package DBMS_REDEFINITION

[LEK]

Bonsoir, et désolé pour ce retour tardif.
En tous cas merci pour vos retours nombreux.

@pachot :

Le mieux est de mettre un commentaire dans le blog

Je n'hésiterais pas à l'occasion ;-)

Personne ne doit lire dans la base cible pendant qu'on charge avec ces techniques.

Vu que l'on crée une seconde table en parallèle de la première et qu'au dernier moment on lui ajoute les contraintes et qu'on la renomme : qu'est ce que l'on risque vraiment si ce n'est la possibilité de perdre des données qui auraient pû être insérées/modifiées pendant notre opération... En fait si je me pose ces questions c'est que personnellement j'ai une base opérationnelle standard qui doit permettre des imports relativement massif (en journée) mais sans pour autant s'arrêter de fonctionner (au moins en lecture car comme dans la plupart des cas ma base et plus utilisée en lecture qu'en écriture)... Il doit bien y avoir de tels systèmes en production de part le monde : ont-ils tous des systèmes plus ou moins complexes de redondance/conciliaton de données ou que sais-je ? et ne pourrais-je pas vraiment avec ces techniques alimenter ma base "à chaud" ?

@mnitu : je n'ai pas compris non plus : le select serait-il à éviter dans ce cas?

@ojo77, @skuatamad :
mille merci pour ces liens : je me plonge dans la lecture de suite ;-) et reviens vers vous en cas de questions.

Merci encore,
Lek.

[mnitu]

Lire les données avant le chargement pour les valider implique soit un niveau d'isolation serializable, soit une garantie que les données ne bougent pas pendant la transaction. Si le traitement batch s'exécute dans une fenêtre de non utilisation de l'application autrement dit mono-utilisateur ça devrait ne pas poser des problèmes.

[LEK]

Merci je comprends mieux la remarque.
Donc si je te suis bien tu renforce l'idée qu'on ne peut en aucun cas utiliser ce type de traitements dans un environnement multi-utilisateurs même si les transactions de mises à jours de ces mêmes utilisateurs sont plus que rare ? (je sais que ce n'est pas en insistant qu'on me dira oui mai j'essayes de trouver une solution ..)

[ojo77]

Savez vous comment mettre en oeuvre ces techniques ?
Mais si on a une base opérationnelle de production avec potentiellement un utilisateur loggué
peut-on se permettre ce genre de manoeuvre...
Ou trouver un exemple de ces utilisations pour mises à jour en masse ?

Quelques exemples dans cet article : http://blog.easyteam.fr/2011/11/22/p...ng-sql-update/