Traitement En Masse

Bonjour,

je travaille sur un grosse base oracle et je dois sortir mettre a jour tous les matins des tables qui sont consitutés par l'agregation d'une partie des données de la base.
La volumetrie correspond à plusieurs millions.

Pour cela, j'utilise une procédure stockée (ORACLE) mais qui effectue un select suivi d'un insert into dans des tables cibles. Les indexs sont désactivés durant l'opération.

LE pb c'est que ce traitement prend la nuit et souvent ne fonctionne pas (obligé de killer le process le matin) et que ces reportings doivent impérativement sortir..


Auriez-vous qq conseils sur ce sujet (j'ai deja consulté les posts), sur le moyen peut être de faire du traitement differentiel (difficile lorsque les données proviennent d'une 10e de tables) ou sur des outils ORACLE qui pourraient m'aider.

Merci d'avance,

Du Chieng

Bonjour ,
est ce que tu utilises de vues matérialisées ?

merci de fournir le contexte technique conformément aux régles du forum

Pourrais tu donner également un exemple de procédure? La plupart du temps, nul besoin de faire un select suivit d'un insert, si ce n'est que de l'agrégation de donnée, un

Code:

---

create table as select

---

suffit amplement

Citation:

---

Envoyé par tetedechien

Les indexs sont désactivés durant l'opération.

---

Tu as voulu dire, les Triggers non ?
Si tu désactives les indexes, tes SELECT vont être en TABLE ACCESS FULL.

Oui enfin, il est permis de désactiver les index sur les opérations d'insertion (voire de les supprimer avant l'insertion en masse et les recréer après l'opération)

Hello,

Merci pour votre réactivité.

En fait j'ai créé une procédure stockée effectue le traitement.
Ce traitement se décompose de la manière ssuivante :

1 - création des tables d'aggrégation (y en a plusieurs). Ces tables portent un nom avec un suffixe _E (pour ecriture).

2 - insertion des données dans ces tables par lot d'intervalles (sinon les rollback segment ont mal, c'est pour cela que je n'utilise pas de create table)

3 - renommage des tables avec le suffixe_L (lecture)

4 - creation des indexs sur le stables en _L

Ce système permet de garder les données obtenues la vieille même si la proc plante.

Le problème c'est que les données proviennent de plein de tables différentes et que cela représente + millions de lignes.

Ce système est particulièrement instable.
Les ralentissements et blocages ne sont pas prévisibles (cela varie entre les différentes phases d'agrégation).

Au début je pensais que cela venait d'accès concurrent, mais , meme ,seule la proc n'est pas stable.

J'ai 2 pistes grâce au DBA :
- utiliser des méchanismes de réplication associés à des vues matérialisés
- spécifier un rollback taillé idéalement lors du démarrage de la session


De toutes le sfaçons, je pense qu'a à terme il faudra mettre en place un traitement différentiel.

il faut passer par des vues matérialisés pour ton probléme .

Ceci étant dit il te faut l'explan plan du select pour l'insert peux être que tu peux accéllerer les choses ici

Je ne comprends pas pourquoi ton dba ne te conseille pas de faire un create as car ainsi tu évite d'exploser les RBS

Personnellement, je viens de travailler sur ce genre de scripts, plusieurs millions de lignes brasées, et au final, quelques heures seulement...


Tu as essayé de faire des create as select? Plutot que des inserts ligne à ligne?

Cela fonctionne comment le système avec les vues matérialisées ?

Endymion222, quelle technique as tu utilisée ?

Tu veux créer une table agrégeant les données de plusieurs tables, prenons un exemple simple avec deux tables.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

create table_agregée as select champs1_table1, champs2_table1, champs1_table2 from table1,table2 where table1.pk=table2.fk

---

Cela permet d'agreger très rapidement les données des différentes tables.

Ensuite, si tu as des calculs spécifiques à faire, tu fais des updates pour ajouter des champs précis. C'est assez rapide, et permet une maintenance assez aisée.

Je pense que la personne qui a fait le boulot avant moi avait testé.

Mais je vais essayer.

Je vous tiens au courant.