Discussion :

[nc_dvlp]

Bonjour,

Je fais actuellement des tests de performance sur des procédures stockées qui sont très longues.
Je suis surpris par le temps d'execution d'une procédure d'update d'une table qui prend plus de 30 minutes lors de la première execution, et qui prend moins de 2 minutes si je la relance une deuxième fois.

Ma procédure fonctionne sur le modèle suivant :
------------------------------------
cursor gc_cus is
select *
from TABLE_REF;
...
for gci in gc_cus
loop
update TABLE_UPDATE
set COL_A = gci.COL_A,
COL_B = gci.COL_B,
UPDATE_D = sysdate,
UPDATED_BY = 'sys'
where SYSID = gci.SYSID;
commit;
end loop;
------------------------------------
SYSID est une colonne indexée (clé primaire).

Je suppose que la deuxième exécution de la procédure est beaucoup plus rapide car mes blocks de données ont été mis dans le buffer cache. Est-ce bien cela?

Quelle peut être la solution pour que la procédure soit plus rapide la première fois? Faut-il chercher plutôt au niveau de la structure de la table/indexes ou des paramètres Oracle?

Je travaille en Oracle 8.1.7

Merci d'avance pour votre aide.

[orafrance]

c'est bon signe, ça veut juste dire que la 1ere fois toutes les données montent dans le cache et qu'ensuite c'est plus le disque qui est sollicité mais la mémoire

La solution : mettre TABLE_REF dans le cache BUFFER

Ensuite, faudrait que tu m'expliques l'intérêt d'utiliser un curseur

[nc_dvlp]

Mettre TABLE_REF dans le cache BUFFER...
Comment faire pour qu'elle soit dans le buffer à la première execution?

Sinon j'utilse un curseur, parce que... Heu
La seule autre solution qui me vient à l'esprit est la suivante :

update TABLE_UPDATE T
set COL_A = (select COL_A from TABLE_REF where where SYSID = T.SYSID),
COL_B = (select COL_A from TABLE_REF where where SYSID = T.SYSID),
UPDATE_D = sysdate,
UPDATED_BY = 'sys'
where SYSID IN (select SYSID from TABLE_REF);

C'est plus rapide? ou ce n'est pas ça?

[orafrance]

ça ne marche pas ça ?

Code :

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

1
2
3
4
5
update TABLE_UPDATE T
set (COL_A,COL_B) = (select COL_A,COL_B from TABLE_REF where SYSID = T.SYSID)
UPDATE_D = sysdate,
UPDATED_BY = 'sys'
where SYSID IN (select SYSID from TABLE_REF);

Sinon : http://download.oracle.com/docs/cd/B...09.htm#i997450

Code :

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

ALTER TABLE table_ref STORAGE (BUFFER_POOL KEEP)

[nc_dvlp]

Merci beaucoup pour tes réponses. Je vais comparer les temps d'exécution.

Sinon, quelques questions :
- pourquoi avoir proposé de mettre TABLE_REF dans le cache, et pas la table que j'update?
- Est-ce recommandé/déconseillé de laisser en cache des grosses tables (plus d'un million de lignes)?
- Si l'on ne veut pas laisser les tables en cache, il faut sans doute chercher du côté de l'optimisation des I/O disque? Si on on a plusieurs CPUs,augmenter le db_writer_processes est-il une possibilité? Si l'on a qu'un CPU, comment faire?

[13thFloor]

Merci beaucoup pour tes réponses. Je vais comparer les temps d'exécution.

Sinon, quelques questions :
- pourquoi avoir proposé de mettre TABLE_REF dans le cache, et pas la table que j'update?
- Est-ce recommandé/déconseillé de laisser en cache des grosses tables (plus d'un million de lignes)?
- Si l'on ne veut pas laisser les tables en cache, il faut sans doute chercher du côté de l'optimisation des I/O disque? Si on on a plusieurs CPUs,augmenter le db_writer_processes est-il une possibilité? Si l'on a qu'un CPU, comment faire?

Oracle alloue par défaut 1 processus dbwriter pour 8 cpu. Donc, en monocpu, 1 seul process devrait suffire. Si vraiment il y a beaucoup trop de buffer busy waits (attentes vues dans un report statspack), tu peux en ajouter un (si les io ne sont pas 100% busy bien sûr) pour accélérer les écritures des blocs sur disque.
Si une table est très fréquemment accédée (en plus en full table) et qu'elle ne grossit pas, elle peut être candidate à une mise en cache. Ce n'est que mon avis. Si vraiment les FTS ne peuvent être évités et que la table est stable, why not. Sinon il faudra la partitionner pour limiter les IO. Pense à voir combien de blocs elle occupe. Il ne faut pas qu'elle gloutonne tout le cache.