Discussion :

[farenheiit]

Ce fichier est-il créé ?
Quel est son rythme de croissance ?
Est-il régulièrement mis à jour ?

j'ai arrêté mon traitement car mon espace disque se réduisait sensiblement alors que je n'avais rien dans mon répertoire udump.
Depuis que j'ai arrêté le traitement j'ai retrouvé mon espace disk (environ 2Go en plus) mais toujours aucune trace du fichier trace.

je pense qu'oraFrance a raison plus de 5 millions d'insert à chaque fois c'est dément et ça coûte.


question:
le fait de faire une boucle For ALL ça ne fait qu'un seul appel au moteur SQL au lieu de 5 millions n'est ce pas? est ce que ça revient au même que de faire un insert-select? je demande ça pour les cas où il est obligatoire de faire une boucle (quand il y'a des traitement à effectuer pour chaque ligne du curseur)

[orafrance]

question:
le fait de faire une boucle For ALL ça ne fait qu'un seul appel au moteur SQL au lieu de 5 millions n'est ce pas? est ce que ça revient au même que de faire un insert-select? je demande ça pour les cas où il est obligatoire de faire une boucle (quand il y'a des traitement à effectuer pour chaque ligne du curseur)

ça ne revient pas au même mais ça peut être plus performant... si FORALL n'est pas assez performant ça peut être avantageusement remplacé par une table temporaire. En effet, charger 6 millions de lignes en mémoire c'est pas non plus anodin

[farenheiit]

même pas, les disques ne suivront pas notamment les logs

tu parles des redo là?

[orafrance]

tu parles des redo là?

oui, parce que ton problème aussi c'est qu'à faire des inserts unitaires tu sollicites d'avantage les redos

[farenheiit]

A quel moment est il interessant de faire un bulk collect plutot qu'un curseur?

(je suis en train de recalculer les stats sur la table TTAB_AMO_BCE_CV2_LDR pour voir si le plan d'execution donne tjr un FTS sur cette table au lieu d'utiliser l'index)

[orafrance]

A quel moment est il interessant de faire un bulk collect plutot qu'un curseur?

il n'est jamais intéressant de faire un curseur... On ne traite ligne à ligne que si des traitements spécifiques doivent être fait sur chaque ligne. Dans ton cas, ça peut être intéressant de faire une requête par anomalie possible et une requête sans ano pour faire tous les inserts en masse sans passer par les curseurs. Ta requête dure moins d'une minute c'est pas des conditions en plus qui vont aggraver sensiblement ses perfs.

[farenheiit]

j'ai refait un analyze sur TTAB_AMO_BCE_CV2_LDR et TCONCOURS et le plan d'execution me donne tjr 2 FTS.
comment est-ce possible????

[orafrance]

comment est-ce possible????

si l'index n'est pas intéressant parce qu'il ramène quasiment toutes les lignes, Oracle considère que son utilisation est inutile.

En l'occurence, tu raménes 1/3 des lignes donc bon... il n'a peut-être pas tord

[farenheiit]

effectivement il met 46 secondes sans utiliser d'index et 66 secondes en utilisant l'index..pas con l'optimiseur dis donc

[pifor]

Si lire 16 millions de lignes pour en sélectionner 6 millions, faire quelques calculs sur ces 6 M de lignes et les insérer dans une autre table prend 5 heures, il y a peut-être un autre problème (les redo logs comme déjà indiqué ou autre chose) vu le faible nombre de colonnes (à moins que des colonnes aient un type de données particulier comme CLOB).

[Tracnac]

pifor

C'est un sujet mainte fois abordé en programmation et en algorithmie... Il y a dans ce cas 5,6 millions d'iteration même en étant optimisé il y a un temps qui deviens imcompressible (Accès disques, accès mémoire etc...) car n'est pas dépendant de ta logique mais de la physique...

Il y a ici un problème d'algorithmie... et l'aide ne peut venir que des developpeurs (Qui ont toutes les billes au niveau cahier des charges...)

[farenheiit]

non il n' y a pas de CLOB dans nos tables...

[farenheiit]

Si lire 16 millions de lignes pour en sélectionner 6 millions, faire quelques calculs sur ces 6 M de lignes et les insérer dans une autre table prend 5 heures, il y a peut-être un autre problème (les redo logs comme déjà indiqué ou autre chose) vu le faible nombre de colonnes (à moins que des colonnes aient un type de données particulier comme CLOB).
__________________
Pierre Forstmann

le fait d'être en mode archivelog peut il expliquer ça?
Si j'augmente la taille des redo logs ça peut aider?

[orafrance]

Non, seul la refonte du code peut aider... le soucis c'est qu'en faisant plusieurs transactions tu stresses d'avantage les redos... peu importe leur taille

[farenheiit]

on m'a parlé des insert en mode nologging et append.
comment on peut mettre ça en place au niveau d'une requête insert?
Faut-il au préalable mettre la table en mode nologging ou bien peut'on mettre un hint au niveau de la requete?

[orafrance]

ça ne vaut que pour les insertions de masses et le NOLOGGING est assez risqué

[farenheiit]

c'est risqué seulement si on a peur que la base tombe non? Dans mon traitement je truncate toutes les tables au départ, si y'a un pb je relance mon chargement.

[pifor]

le fait d'être en mode archivelog peut il expliquer ça?
Si j'augmente la taille des redo logs ça peut aider?

Je ne fais qu'une hypothèse qu'il faut confirmer avec des éléments comme la trace complète sur la partie de code concernée qui dira entre autres s'il y a goulot d'étranglement lié aux redo logs. Le fichier alert.log de l'instance peut également donner des renseiglnment s'il y a des messages du type "checkpoint not complete" ou "cannot allocate new log".

Je ne vous conseille pas de faire des modifications sans avoir une idée précise de la cause de vos problèmes de performances. Cela peut-être beaucoup de temps perdu.

A propos des 5 heures en question, j'ai fait un petit test sur mon PC avec Oracle 10.2.0.1(et non Oracle 9) sur Linux et un Athlon 3400 (machine sortie il y a un peu plus de 2 ans). La base a été créée par DBCA et a 3 redo logs de 50 Mo et est en mode ARCHIVELOG. Insérer 6 millions de lignes dans une table de 6 colonnes (3 colonnes NUMBER, 2 DATE et 1 VARCHAR2) m'a pris 30 minutes.

[farenheiit]

Insérer 6 millions de lignes dans une table de 6 colonnes (3 colonnes NUMBER, 2 DATE et 1 VARCHAR2) m'a pris 30 minutes.

oui mais ce sont 6 millions d'insert successifs? ou 1 insert de 6 millions de lignes?

[pifor]

Dans mon test, il s'agit bien de 6 millions d'INSERT dans un bloc PL/SQL avec une boucle du style:

Code :

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

1
2
3
4
for i in 1..6000000
loop
insert ...
end loop;

et dans 1 seule transaction comme dans votre cas à priori.