Discussion :

[fulub]

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

[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

[fulub]

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

[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

[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.

[fulub]

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

[Laurent_du_78]

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

[fulub]

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