Discussion :

[nuke_y]

Bonjour,

je dois réaliser une migration d'un ancien système vers un système sous Oracle. J'importe des fichiers plats sous oracle avec SQLLoader dans une table temporaire de chargement et je dois ensuite retraiter certaines données (enlever des charactères parasites, concaténer 2 champs, etc...) puis les dispatcher dans les nouvelles tables.

J'utilise des batchs pour toute la phase création/importation mais pour la phase de retraitement des données puis leur dispatching, vous me conseillez de continuer en batchs qui lancent des scripts .sql avec SQL*Plus ou alors de créer des procédures stockées et des package sur le serveur et juste de les appeller avec les batchs (au niveau perf, maintenabilité, réutilisation, etc.) ?

J'ai un petit nombre d'enregistrements : 4 * 90 000 environ avec des retraitements assez basiques. Je suis sous Oracle 9i et je précise qu'il ne s'agit pas de migrations régulières. la migration aura lieu en une seule fois donc le côté possibilité de programmer l'import/triatement de manière répétitive n'est pas intéressant. par contre l'import/traitement peut avoir à être répété plusieurs fois d'affilées avec des modifications entre elles (par exemple on refait le chargement parce qu'on s'est aperçu d'un oubli dans un traitement, etc...).

Merci

[CD]

Il vaut mieux que cela soit fait en SQL plutot qu'en PL/SQL quand c'est possible.

[nuke_y]

Donc? scripts SQL lancés par batchs plutôt que procédures stockées si je comprend bien?

[echoes]

L'avantage des procédures tockées sur des scripts sql+ est (entre autre) la rapidité et le fait que le code source se trouve dans la base oracle et non pas dans des fichiers sql+ quelque part sur une machine.

[Yorglaa]

L'avantage des procédures tockées sur des scripts sql+ est (entre autre) la rapidité et le fait que le code source se trouve dans la base oracle et non pas dans des fichiers sql+ quelque part sur une machine.

j'abonde...

j'ajouterais aussi qu'avec les procédures stockées, ton code sera sauvegardé avec le reste de ta base lors des backups...

[CD]

L'avantage des procédures tockées sur des scripts sql+ est (entre autre) la rapidité et le fait que le code source se trouve dans la base oracle et non pas dans des fichiers sql+ quelque part sur une machine.

Oui, d'accord avec le fait que le code source se trouve quelque part sur la base oracle, ce qui est plus pratique notamment pour les sauvegardes, mais pas sur le fait que ce soit plus rapide...

[Fabien Celaia]

Oui, d'accord avec le fait que le code source se trouve quelque part sur la base oracle, ce qui est plus pratique notamment pour les sauvegardes, mais pas sur le fait que ce soit plus rapide...

Et pourquoi donc ? le fait que le code soit précompilé et parsé dans une procédure stockée est effectivement plus rapide que le lancement depuis un batch.

[nuke_y]

Toujours dans la même idée, la création de packages est-elle déconseillée ou plutôt conseillée au niveau des perfs? Ou alors est-ce que ça ne change rien ?

[Loko]

Bonjour

Et pourquoi donc ? le fait que le code soit précompilé et parsé dans une procédure stockée est effectivement plus rapide que le lancement depuis un batch.

Le gain n'est peut etre sensible qu'a partir d'"un plus grand nombre d'enregistrements ?

[Yorglaa]

je crois que pour répondre efficacement il faudrait connaître la totalité du contexte...

on sait, d'une manière générale que le SQL est plus rapide que le PL/SQL...

mais si il faut appeler un script SQL à travers le réseau, 3 noeuds sur 2 domaines différents et transférer le tout par FTP (bon là j'abuse un peu mais c'est pour l'exercice de style), alors là je suis CERTAIN que la procédure en PL sur la base sera plus rapide...

de plus rien n'empêche, à mon sens, de faire du SQL (donc rapide) dans du PL ... par exemple encapsuler un update massif entre un Begin et un End ne nous causera pas de grosses baisses de perf... par contre il sera plus lent de faire du PL pur, c'est à dire un curseur, un loop et un update individuel des lignes du curseur...

[Pomalaix]

Oui, d'accord avec le fait que le code source se trouve quelque part sur la base oracle, ce qui est plus pratique notamment pour les sauvegardes, mais pas sur le fait que ce soit plus rapide...

Et pourquoi donc ? le fait que le code soit précompilé et parsé dans une procédure stockée est effectivement plus rapide que le lancement depuis un batch.

Comme le disait CD, si on peut se passer du PL/SQL pour une certaine tâche, alors autant la faire en SQL pur. Ca sera très nettement meilleur pour les performances, car l'exécution de SQL depuis du PL/SQL provoque un "changement de contexte" coûteux.

Après, si on a impérativement besoin de PL/SQL, on a 2 choix : un bloc anonyme qui ne sera pas précompilé, ou une procédure/fonction, qui sera stockée en base et précompilée.
Là où il y aura un gain, c'est si la procédure est très fréquemment réutilisée, comme c'est le cas dans une application transactionnelle.

Dans le cas qui nous occupe, les procédures seront certainement peu réutilisées, et l'effet de la précompilation sera a priori négligeable.

Dans les débats qu'on a souvent ici sur les performances, on oublie très souvent un détail important : savoir dans quelles proportions telle ou telle technique est meilleure (ce qu'on est bien souvent incapable d'évaluer).
Si une méthode n'apporte que 0.5% d'amélioration, ce n'est sans doute pas sur elle qu'il faut se concentrer...

[echoes]

Le seul vrai intérêt que je vois au procédures stockées c'est de mettre à l'abri le code dans la base... pour pouvoir comprendre pourquoi ça a merdé des années aprés

[Yorglaa]

ou pour comprendre comment avait fait ce super DBA que tout le monde regrette...

[orafrance]

L'avantage des procédures tockées sur des scripts sql+ est (entre autre) la rapidité et le fait que le code source se trouve dans la base oracle et non pas dans des fichiers sql+ quelque part sur une machine.

PL/SQL + rapide que SQL

alors là ça dépend énormémement du script... en tout cas un code SQL simple doit être fait en SQL... le pl/sql ajoutant une surcouche couteuse

[Pomalaix]

L'avantage des procédures tockées sur des scripts sql+ est (entre autre) la rapidité et le fait que le code source se trouve dans la base oracle et non pas dans des fichiers sql+ quelque part sur une machine.

PL/SQL + rapide que SQL ?

Mais il parlait de procédures toquées, c'est sans doute pour ça

[nuke_y]

Houla, bon euh merci à tous.
Je crois que je vais relire calmement les tutoriels SQL et PL/SQL parce que là je commence à tout mélanger : procédures stockées, packages, SQL et PL/SQL.
Thx

[Pomalaix]

Houla, bon euh merci à tous.
Je crois que je vais relire calmement les tutoriels SQL et PL/SQL parce que là je commence à tout mélanger : procédures stockées, packages, SQL et PL/SQL.
Thx

Peut-être qu'un résumé rapide vous évitera des heures de lecture...

Bon, le SQL, je suppose que vous savez ce que c'est. On peut l'illustrer par le fameux SELECT.

Le PL/SQL, c'est une extension du SQL. Il ajoute des capacités procédurales, notamment l'usage des variables et l'exécution conditionnelle (IF THEN ELSE), ce qui autorise des traitements complexes impossibles en SQL pur.

Le code PL/SQL peut être stocké dans la base, sous la forme de procédures ou de fonctions. C'est utile quand un certain code doit être réutilisé maintes fois, et on fera alors un CREATE FUNCTION ou CREATE PROCEDURE, et il suffira d'appeler ladite fonction par son nom, sans devoir retaper tout le code.

Mais si un code PL/SQL est à usage unique, il n'y a aucun intérêt à le stocker dans la base. On aura alors un simple bloc BEGIN...END, (dit anonyme car il ne porte pas de nom de fonction/procédure). Mais une fois qu'on l'a exécuté, il est perdu, et si on ne l'a pas conservé quelque part, il faut tout retaper.

Quant aux paquetages, ils permettent de regrouper un ensemble de fonctions ou procédures qui remplissent des tâches apparentées.

[nuke_y]

Mais alors, on ne peut pas stocker en base une requête SQL "pur" ? Toute procédure stockée et tout package est obligatoirement en PL/SQL (donc moins rapide qu'un équivalent en SQL) ?

[Yorglaa]

si c'est "juste" pour un Select tu peux créer un vue ou un snapshot...

[nuke_y]

Non c'est pour un insert qui sert à importer dans une table les données modifiées d'une autre table.
Genre :

Code :

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

insert into new_table (champ1,...champn) (select old_table.champ1A||old_table.champ1B,...,old_table.champnA||old_table.champnB FROM old_table)

Mais comme il y a un certain nombre de modifications (et qu'il sera surement impossible de tout faire en 1 seul passage) je me renseigne sur les moyens de l'optimiser.