Pb de performance sqlldr

Version imprimable

27/04/2009, 12h26
fulub

Pb de performance sqlldr

Bonjour,

J'ai un souci lors de l'exécution du procédure dont l'objet est le rafraîchissement d'une base infocentre par rapport à une base de production. Cette procédure met à jour 50 tables pour une durée de traitement de 9 heures. Mais, sur les 9h, elle passe 5h pour mettre à jour une salle table.

La procédure commence par supprimer environ 3 millions de ligne (delete ligne par ligne via script généré par programme), puis exécute un sqlldr d'environ 3 millions de lignes. Ma table contient plus de 8 millions de lignes et n'est donc pas vide lors du lancement du sqlldr (si j'ai bien compris, je ne peux donc pas utiliser l'option direct).

La base est hébergée sur un serveur Windows 2003 avec Oracle 10.1.0.5 (ps : lors du chargement de cette table, le serveur semble ne rien faire et n'est pas en charge). La procédure d'alimentation est lancée à partir d'un serveur HP-UX Itanium 64bits HP-UX 11.23 (utilisation de la couche Net8)

Pour information, la table est composée de 200 colonnes, chaque colonne ayant une taille de 22 caractères.

En vous remerciant par avance, si vous aviez des pistes et/ou des conseils pour remédier à cette lenteur.

Philippe
27/04/2009, 13h35
iSylvain

Bonjour,

Cette table a t elle des index ?
Si oui, avant le traitement il faudrait les desactiver et les reconstruire une fois le traitement fait.

Sinon il n'y a pas un moyen de partitionner la table de facon à faire un truncate d'une partition contenant 3 millions de lignes plutot que 3 millions de delete ?
ça permettrais de faire redescendre le HWM.

Option direct : http://jaouad.developpez.com/sqlldr/#LIII-C-1

Sinon il est peut etre envisageable de desactiver les archives log pendant ce traitement ou du moins de passer la table en mode nologging :?
27/04/2009, 15h32
fulub

Citation:

Envoyé par iSylvain

Bonjour,

Cette table a t elle des index ?
Si oui, avant le traitement il faudrait les desactiver et les reconstruire une fois le traitement fait.

Sinon il n'y a pas un moyen de partitionner la table de facon à faire un truncate d'une partition contenant 3 millions de lignes plutot que 3 millions de delete ?
ça permettrais de faire redescendre le HWM.

Option direct : http://jaouad.developpez.com/sqlldr/#LIII-C-1

Sinon il est peut etre envisageable de desactiver les archives log pendant ce traitement ou du moins de passer la table en mode nologging :?

Bonjour,

Merci de votre réponse.

1. Non, cette table n'a pas d'index. Il a juste une primary key composée de deux champs
2. J'ai bien pensé au partitionnement. Mais, la tranche des données à supprimer est fluctuant à chaque jour (date -x jours).
3. Merci pour la documentation sur le mode direct. Mais d'après ce que j'en ai compris, ma table doit être vide (mode TRUNCATE), ce qui n'est pas mon cas.
4. Ma base n'est pas en mode archivelog. Je pense faire un test en passant ma table en mode nologging.

Si vous avez d'autres propositions, je suis preneur

Cordialement

Philippe
28/04/2009, 08h23
fulub

Bonjour,

J'ai passé l'ensemble des tables de mon schéma en mode nologging. A priori, je pense avoir gagné un tout petit peu en durée, mais cela est encore insuffisant.

De plus, j'ai toujours des switchs fréquents de mes redos alors que les tables de mon schéma (et uniquement de mon schéma) sont en nologging. D'où pourrez venir ces switchs?

D'avance merci de votre aide

Philippe
28/04/2009, 08h57
pifor

Il faudrait commencer par analyser avec la trace SQL et TKPROF l'exécution de SQLLDR pour savoir ce qui se passe vraiment dans la session base de données correspondante.

Je ne serais pas surpris si la session de SQLLDR passe un certain temps en attente de type SQL*Net message from client. Dans ce cas, il faudrait penser à faire le chargement en local càd sur la machine qui héberge l'instance. A confirmer avec la trace SQL et TKPROF.
28/04/2009, 09h28
Laurent_du_78

Citation:

Envoyé par fulub

Bonjour,

J'ai passé l'ensemble des tables de mon schéma en mode nologging. A priori, je pense avoir gagné un tout petit peu en durée, mais cela est encore insuffisant.

De plus, j'ai toujours des switchs fréquents de mes redos alors que les tables de mon schéma (et uniquement de mon schéma) sont en nologging. D'où pourrez venir ces switchs?

D'avance merci de votre aide

Philippe

Le mode NOLOGGING trace quand même les transactions notamment le DELETE, d'où les switch sur les REDO.

Ce qui n'est pas tracé concerne les CREATE as SELECT, les modes APPEND ou DIRECT PATH.

Tu peux essayer ton SLQ*Loader en mode DIRECT PATH, l'inconvénient est qu'il va invalider la PK le temps du chargement et le reconstruire en fin
28/04/2009, 10h06
fulub

Citation:

Envoyé par pifor

Il faudrait commencer par analyser avec la trace SQL et TKPROF l'exécution de SQLLDR pour savoir ce qui se passe vraiment dans la session base de données correspondante.

Je ne serais pas surpris si la session de SQLLDR passe un certain temps en attente de type SQL*Net message from client. Dans ce cas, il faudrait penser à faire le chargement en local càd sur la machine qui héberge l'instance. A confirmer avec la trace SQL et TKPROF.

Merci Pifor de ces renseignements. Je te rejoins sur le fait qu'il doit être en attente car comme je l'indiquais dans un précédent post, j'ai l'impression que le serveur ne fait rien.

Par contre, j'avoue mon ignorance quand à l'utilisation des traces SQL et de TKPROF. Si vous pouviez me guider, ce serait gentil.

Philippe
28/04/2009, 10h10
fulub

Citation:

Envoyé par Laurent_du_78

Le mode NOLOGGING trace quand même les transactions notamment le DELETE, d'où les switch sur les REDO.

Ce qui n'est pas tracé concerne les CREATE as SELECT, les modes APPEND ou DIRECT PATH.

Tu peux essayer ton SLQ*Loader en mode DIRECT PATH, l'inconvénient est qu'il va invalider la PK le temps du chargement et le reconstruire en fin

Merci. C'est dommage que le DELETE soit tracée car cela constitue 50% de traitement de ma table soit près de 2h30 sur un traitement de 5h.

Par contre, je pensais ne pas pouvoir utiliser le mode DIRECT dans mon sqlldr, dans la mesure où ma table, lors de chargement, n'est pas vide. Ai je tort ou ai je mal interprété le fait que le mode TRUNCATE doit être utilisé? Le fait que ma contrainte soit désactivé ne me dérange pas car le chargement se fait de nuit et je n'ai pas d'utilisateur.

Merci.

Philippe
28/04/2009, 10h29
pifor
Voir le tutoriel http://oracle.developpez.com/guide/tuning/tkprof/.

Je recommande avec Oracle 10 d'utiliser DBMS_MONITOR de la façon suivante (section III du tutorial):
Code:

1 2 EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE( session_id => <sid>, serial_num => <ser>, waits => TRUE, binds => TRUE);
Pour retrouver <sid> et <ser>:

Code:

select sid, serial# from v$session where ...
28/04/2009, 11h45
Laurent_du_78

Citation:

Envoyé par fulub

Merci. C'est dommage que le DELETE soit tracée car cela constitue 50% de traitement de ma table soit près de 2h30 sur un traitement de 5h.

Par contre, je pensais ne pas pouvoir utiliser le mode DIRECT dans mon sqlldr, dans la mesure où ma table, lors de chargement, n'est pas vide. Ai je tort ou ai je mal interprété le fait que le mode TRUNCATE doit être utilisé? Le fait que ma contrainte soit désactivé ne me dérange pas car le chargement se fait de nuit et je n'ai pas d'utilisateur.

Merci.

Philippe

Tu peux faire du DIRECT PATH avec du APPEND/TRUNCATE/REPLACE.
Le direct path ressemble au INSERT /* APPEND*/, :
- utilisation de nouveau block (perte de place)
- invalidation des index et contraintes, puis recréation (et pas reconstruction)
- pas de trace dans les REDO, donc recover difficile.
- etc... (voir doc)
29/04/2009, 08h46
fulub

Bonjour,

Merci à vous deux pour votre aide.

J'ai d'abord mis toutes les tables de mon schéma en mode nologging le temps du traitement. gain de1h sur un traitement de 9h.

Puis, pour la table qui me pose problème, j'ai fait un sqlldir direct=yes et en fin de traitement, j'ai réactivé la contrainte. Maintenant mon traitement global dure moins de 6h et surtout, il est terminé pour 8h donc cela me convient tout à fait. En plus, je ne l'ai fait que sur une table (la plus lourde => moitié du temps d'exécution) et je peux encore gagner un peu car il me reste 49 tables.

Merci à Pifor pour les liens sur tkprof. Je vais m'y mettre car j'ai une grosse lacune de ce côté. Il est possible que j'ai besoin d'aide pour l'interprétation les premiers temps.

Encore merci et bonne journée

Philippe
02/06/2009, 08h49
fulub

Performance sqlldr

Bonjour,

Je rouvre ce post que l'installation du mode direct pose un problème sur la volumétrie. Depuis son utilisation, j'avais mes datafiles qui explosaient en terme d'espace.

En regardant sur le net, j'ai cru comprendre (mais je n'en suis pas sûr), que ce mode impliquait une écriture au delà de la HWM. Ce qui expliquerait mon souci. En un moi, je suis passé de 15Go de données à 64Go

Ne pouvant continuer comme cela, j'ai donc supprimé le mode direct de mon sqlldr et exporter/importer mon tablespace pour qu'il retrouve sa taille d'origine. Du coup, mes traitements ont à nouveau des performances déplorables.

Ma question est la suivante. Y a t'il un moyen de pallier à ce souci d'espace afin que je puisse à nouveau utiliser le mode direct.

D'avance merci de votre aide

Philippe