Discussion :

[fulub]

Bonjour,

J'ai une base infocentre hébergée sur un serveur Windows 2003 SP2. Ma version d'oracle est la 10.1.0.5.

Un traitement prend en charge le rafraîchissement de cette base toutes les nuits. Depuis un mois, Le temps de traitement a explosé. Auparavant, le traitement se terminait vers 9h le matin, maintenant il ne se termine pas avant 14h. La durée est passée de 5h à plus de 10h.

En fait, c'est le rafraîchissement d'une table qui me pose problème (plus de 80% du temps de traitement). Cette table contient, une fois l'alimentation terminée, 11 millions de lignes (200 colonnes). Le traitement commence par faire un delete ligne par ligne d'environ 3,5 millions de lignes, puis exécute un sqlldr d'un nombre équivalent de lignes.

Via le grid control, j'ai constaté que la session correspond au process LGWR bloque la session en charge de l'alimentation (voir pièce jointe).

D'autre part, j'ai également des alertes liées à des waits sur des opérations commit (cf. deuxième pièce jointe).

La taille de mes redos logs est de 500Mo.

Je ne sais pas où chercher pour améliorer cette alimentation et je suis preneur de toutes informations.

D'avance merci de votre aide.

Cordialement

Philippe

[orafrance]

C'est surement le DELETE qui est long, tu peux pas supprimer les 3.5 millions de lignes d'un coup (éviter 3.5 millions de DELETE quoi) ? Tes stats sont bien à jour ?

[Waldar]

J'ajouterai au message d'orafrance que si vous devez supprimer 3.5M de lignes sur une table d'11M, vous feriez mieux au choix :

• de recréer une table sans ces lignes, supprimer l'originale et remettre les droits et tout le reste
• ou de supprimer tous les index (sauf celui de la clef du DELETE) et de les reconstruire après votre insert

[orafrance]

Ca peut aussi valoir le coup de s'intéresser aux vues matérialisées

[fulub]

Merci de vos réponses.

Effectivement, si le delete est long, elle reste quand même plus rapide que le sqlldr. La phase de delete dure environ 3 heures, alors que le sqlldr dure 5h.

Là où je suis bloqué, c'est que je ne maîtrise pas l'alimentation de l'infocentre. Je suis d'accord avec vous pour dire qu'un delete global serait préférable, ou une suppression et recréation des index, mais cete interface est fournie par un éditeur. Je ne peux qu'intervenir sur le tuning de la base de données.

Philippe

[Waldar]

Ou vous pouvez faire le Jean-Pierre Coffe auprès de votre fournisseur

[orafrance]

Il n'y a pas de magie, si le développement est mal fait, aucun tuning ne pourra parfaitement combler ses carences

Pour SQLLOADER, essaye le direct path

[fulub]

Il n'y a pas de magie, si le développement est mal fait, aucun tuning ne pourra parfaitement combler ses carences

Pour SQLLOADER, essaye le direct path

Je suis d'accord, mais ce que je ne m'explique pas, c'est pourquoi le temps de traitement a doublé pratiquement du jour au lendemain, alors que les volumes à traiter sont identiques et que rien n'a été modifié au niveau des serveurs.

J'avais mis en place le direct path pour le sqlldr, mais le problème est qu'il écrit toujours au dessus de la marque, ce qui fait que le tablespace grossit de façon conséquente et qu'il faut réinitialiser la base pour récupérer l'espace perdu (sauf erreur de ma part).

Philippe

[Waldar]

Le vase a fini par déborder quelque part.
De mon côté - développeur ETL, jamais je ne me permettrai de livrer un traitement qui dure 5h pour gérer 3.5 millions de lignes.
C'est un peu la honte quand même.

Pour vous donner un ordre d'idée (dans un contexte différent, des machines différentes), un recalcul quotidien d'une partie d'une table agrégée, volumétrie quotidienne d'environ 5M de lignes, ça prend quatre minutes.

[orafrance]

Je suis d'accord, mais ce que je ne m'explique pas, c'est pourquoi le temps de traitement a doublé pratiquement du jour au lendemain, alors que les volumes à traiter sont identiques et que rien n'a été modifié au niveau des serveurs.

Si la table grossit le DELETE est de plus en plus long. Vérifie les stats et surtout l'indexation

J'avais mis en place le direct path pour le sqlldr, mais le problème est qu'il écrit toujours au dessus de la marque, ce qui fait que le tablespace grossit de façon conséquente et qu'il faut réinitialiser la base pour récupérer l'espace perdu (sauf erreur de ma part).

Pourquoi ne pas faire le SQLLDR dans une autre table que tu peux tronquée avant (et donc libéré les blocs) ? En plus, ça permettrait de paralléliser les 2 taches chargement et delete

Le vase a fini par déborder quelque part.
De mon côté - développeur ETL, jamais je ne me permettrai de livrer un traitement qui dure 5h pour gérer 3.5 millions de lignes.
C'est un peu la honte quand même.

Parfois on est tributaire des contraintes applicatives, c'est pas toujours évident de faire dans des délais raisonnables. Il n'y a rien d'honteux là-dedans