Hoi, het is misschien wat specifiek probleem, maar wie weet zitten hier wel Oracle freaks die me kunnen helpen.
Een bepaalde handeling in de client bestaat uit een lus (die door een gridje loopt) waarin een package functie opgeroepen wordt per doorloop.
Op onze testserver loopt dit vlot (280 doorlopen in 30 seconden), maar bij de klant gaat dit veel trager (280 doorlopen in 2 minuten). Dus ik start een oracletrace.
Alle SQLs hebben een vlotte doorlooptijd (<0.01s), behalve eentje, die ik niet kan plaatsen:
BEGIN SYS.DBMS_DESCRIBE.DESCRIBE_PROCEDURE(:object_name,:res1,:res2,:overload,
:position,:level,:argument,:datatype,:default,:in_out,:length,:precision,
:scale,:radix,:spare); END;
die heeft een doorlooptijd van 0.04s per keer bij de klant en 0.00s bij ons. Deze SQL is volgens mij niet data-gerelateerd. (bij een select op een tabel zou je nog kunnen zeggen dat die trager gaat bij de klant om dat daar meer data zit)
Heb alles gecheckt ivm vollopen tablespaces, grote logfiles, indexes,... geen fouten hier.
Ik had al een tip op het internet gevonden, en die was om de package te "pinnen" oftewel in de shared_pool geheugen te houden. met "execute sys.dbms_shared_pool.keep('MIJNPACKAGE')" maar dit maakt het niet sneller...
iemand nog tips?
Een bepaalde handeling in de client bestaat uit een lus (die door een gridje loopt) waarin een package functie opgeroepen wordt per doorloop.
Op onze testserver loopt dit vlot (280 doorlopen in 30 seconden), maar bij de klant gaat dit veel trager (280 doorlopen in 2 minuten). Dus ik start een oracletrace.
Alle SQLs hebben een vlotte doorlooptijd (<0.01s), behalve eentje, die ik niet kan plaatsen:
BEGIN SYS.DBMS_DESCRIBE.DESCRIBE_PROCEDURE(:object_name,:res1,:res2,:overload,
:position,:level,:argument,:datatype,:default,:in_out,:length,:precision,
:scale,:radix,:spare); END;
die heeft een doorlooptijd van 0.04s per keer bij de klant en 0.00s bij ons. Deze SQL is volgens mij niet data-gerelateerd. (bij een select op een tabel zou je nog kunnen zeggen dat die trager gaat bij de klant om dat daar meer data zit)
Heb alles gecheckt ivm vollopen tablespaces, grote logfiles, indexes,... geen fouten hier.
Ik had al een tip op het internet gevonden, en die was om de package te "pinnen" oftewel in de shared_pool geheugen te houden. met "execute sys.dbms_shared_pool.keep('MIJNPACKAGE')" maar dit maakt het niet sneller...
iemand nog tips?