Précédent   Forum des professionnels en informatique > Bases de données > Oracle > PL/SQL
PL/SQL Forum d'entraide sur le PL/SQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 13/01/2011, 18h25   #1
Invité de passage
 
Inscription : octobre 2010
Messages : 10
Détails du profil
Informations forums :
Inscription : octobre 2010
Messages : 10
Points : 2
Points : 2
Par défaut Optimisation écriture fichier

Bonjour,

J'utilise ORACLE 11, j'ai une procédure stockée qui écrit dans un fichier. A l'heure actuelle, j'écris en utilisant UTL_FILE.PUT_LINE avec un buffer de 32k (qui est le max autorisé). J'ai beaucoup de volume à écrire (dans les 50 mo). Y-a-t-il un moyen d'écrire avec un plus gros buffer en utilisant autre chose que UTL_FILE.PUT_LINE ? Ou connaissez vous d'autre moyen d'optimiser l'écriture sur fichier en PLSQL ?

Merci pour vos réponses

Jacques
jjjjjggggg est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/01/2011, 10h20   #2
Expert Confirmé Sénior
 
Avatar de mnitu
 
Homme Marius Nitu
Ingénieur développement logiciels
Inscription : octobre 2007
Messages : 3 311
Détails du profil
Informations personnelles :
Nom : Homme Marius Nitu
Localisation : France, Marne (Champagne Ardenne)

Informations professionnelles :
Activité : Ingénieur développement logiciels
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : octobre 2007
Messages : 3 311
Points : 5 808
Points : 5 808
D'abord ça dépend de votre algorithme, est-il optimisé ?
mnitu est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/01/2011, 15h24   #3
Invité de passage
 
Inscription : octobre 2010
Messages : 10
Détails du profil
Informations forums :
Inscription : octobre 2010
Messages : 10
Points : 2
Points : 2
J'ai une procédure principale de parcours d'une table et une sous procédure qui écrit par bloc de 32k.

En terme d'optimisation, pour l'instant je fais en sorte de faire une seule ouverture / fermeture de fichier et de passer le même pointeur pour tous les appels de la sous procédure d'écriture. Je fais aussi en sorte de remplir le plus possible mon buffer avant de le flusher dans le fichier disque (c'est du xml je fais aussi en sorte de pas couper la ligne à l'intérieur d'une balise).

La sous procédure d'écriture est donc appelée environs 1600 fois pour un fichier de 50mo. C'est l'option "petit buffer, beaucoup d'appel à la sous procédure".

Ca m'a pu plus performant que de tout charger dans une variable clob et de faire un seul appel à une procédure d'écriture qui elle découperait le clob par bloc de 32k et ferait ses écritures, option "gros buffer, 1 seul appel à la sous procédure".

Mais j'avoue de ne pas être vraiment sûr que ce soit plus performant, peut-être qu'une solution intermédiaire sera à étudier, vos avis ?
jjjjjggggg est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/01/2011, 16h21   #4
Expert Confirmé Sénior
 
Avatar de mnitu
 
Homme Marius Nitu
Ingénieur développement logiciels
Inscription : octobre 2007
Messages : 3 311
Détails du profil
Informations personnelles :
Nom : Homme Marius Nitu
Localisation : France, Marne (Champagne Ardenne)

Informations professionnelles :
Activité : Ingénieur développement logiciels
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : octobre 2007
Messages : 3 311
Points : 5 808
Points : 5 808
Si chaque appel de la procédure UTL_FILE.PUT se fait avec un buffer rempli de 32K c’est OK.
mnitu est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/01/2011, 21h41   #5
McM
Expert Confirmé Sénior
 
Inscription : juillet 2003
Messages : 3 437
Détails du profil
Informations forums :
Inscription : juillet 2003
Messages : 3 437
Points : 4 173
Points : 4 173
Comment est géré le buffer de 32K dans la procédure : Un clob ?
J'ai réduit un traitement de 1h à 5mn en changeant des || du clob par des affectations dans un varchar et en || au clob une seule fois à la fin de chaque petit traitement.
__________________
More Code : More Bugs. Less Code : Less Bugs
McM est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/01/2011, 00h01   #6
Invité de passage
 
Inscription : octobre 2010
Messages : 10
Détails du profil
Informations forums :
Inscription : octobre 2010
Messages : 10
Points : 2
Points : 2
J'ai améliorer mes perfs en utilisant notamment une fonction qui écrit d'un coup le contenu d'un clob dans un fichier.

cf http://www.oracle-developer.net/display.php?id=425
jjjjjggggg est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/01/2011, 11h51   #7
Expert Confirmé Sénior
 
Avatar de mnitu
 
Homme Marius Nitu
Ingénieur développement logiciels
Inscription : octobre 2007
Messages : 3 311
Détails du profil
Informations personnelles :
Nom : Homme Marius Nitu
Localisation : France, Marne (Champagne Ardenne)

Informations professionnelles :
Activité : Ingénieur développement logiciels
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : octobre 2007
Messages : 3 311
Points : 5 808
Points : 5 808
Citation:
Envoyé par jjjjjggggg Voir le message
J'ai améliorer mes perfs en utilisant notamment une fonction qui écrit d'un coup le contenu d'un clob dans un fichier.

cf http://www.oracle-developer.net/display.php?id=425
Je me demande si vous avez bien compris

Citation:
We can summarise our findings as follows:

•we can achieve good performance gains by using a buffer to reduce our I/O operations;

•using a CLOB reduces our file I/O to a single operation and in serial mode can perform as well as UTL_FILE;

•the buffering APIs in UTL_FILE (PUT, FFLUSH, NEW_LINE) do not perform as well as our own PL/SQL variable buffering;

•our time savings from buffering are proportional to the time spent in file-writing only. If most of the routine's time is spent in data fetching (i.e. an intensive source cursor), the overall impact of UTL_FILE tuning will be reduced;

•dividing the workload by using parallel pipelined functions can provide significant performance increases (six times faster with our sample data in this article). This can also reduce the overall time it takes to access all of the source data;

care should be taken over the resources required by the CLOB technique, particularly in PQ scenarios where it becomes unscalable.
mnitu est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/01/2011, 23h29   #8
Invité de passage
 
Inscription : octobre 2010
Messages : 10
Détails du profil
Informations forums :
Inscription : octobre 2010
Messages : 10
Points : 2
Points : 2
J'ai pas vraiment pris le temps de benchmarker la solution clobtofile versus utl_file et ayant fait d'autres modifs dans le processus d'écriture, je peux pas être sûr à 100% que ce soit dû seulement au changement de méthode. Mais les perfs se sont améliorées de manière significatives et le gain en I/O me semble vraiment valoir la chandelle.
jjjjjggggg est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité Cette discussion est résolue.
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 17h05.


 
 
 
 
Partenaires

Hébergement Web