Performance: call packages from APEX is slow

Question

Hi
we have a complexe authorization, authentication and policy concept. We have encapsulate a lot of functions into a seperate package. Functions and procedures of this package gets called at different places in three different applications. I know if a package function ie. get's called in a report query it could be very slow because it get's called not one time for one row, it sometimes get's called 5 or 10 times for one row. It's always better to join tables and information into reports.
Problem is, we have two instances and in one instance, the application is "running". In the other instance, the application is f*****g slow...
So I read about pinning of packages and problems with session pooling and session cached cursors.
First question is, what excatly happens if I pin a package into memory and what are the prerequisites to do that? Could this realy improve the performance dramatically?
Second question is, could there be some problems of session pooling or can we increase the amount of session that could be pooled so that packages get be chached?
Do you have some more information, links or ideas to increase performance? or caching of packages? or some other tricks like overwriting V(xxx) syntax?
Thanks in advance!

Answer 1

Greetings,
As mentioned in the above post, pinning packages can help with the overhead of packages being loaded and reloaded after being swapped out. If you follow the link and read the blog post, you'll get a good idea of what happens when you Pin a package and how to actually do it.
But more to the point you need to know where your code is "failing to be performant". Luckily there are a number of things that you can do to pinpoint what portion of the code is slow and why.
DBMS_PROFILER allows you to get information about the execution of your PL/SQL packages, including how many times a particular line of code was executed and how long it took to run. This is very useful information when trying to diagnose PL/SQL. However DMBS_PROFILER doesn't give you a 100% picture of what is going on, as it lumps the execution of SQL in with the execution of PL/SQL.
DBMS_HPROF (available on 11g) is similar to DMBS_PROFILER in that it tells you what your code is doing, but it adds the ability to look at the data hierarchically (with parents and children) and to split the execution of PL/SQL from the execution of SQL queries.
There is an Open Source project called the Instrumentation Library for Oracle (ILO) that allows you to instrument your code and collect data about it's response time as well as capture accurately scoped 10046 trace data. Originally authored at the performance experts at HOTSOS (Where I should say, I used to work), the project is now stewarded by Method-R and continues to be expanded.
Speaking of 10046 trace, APEX is actually instrumented so that with a small addition to the URL, you can generate a 10046 Level 12 trace of the session that processes and renders a page. Run that through TK-PROF, SQL-DEV or The Method-R/Hotsos Profiler, and you'll see a full accounting of the time taken.
Another thing you can do is to make sure you're not executing the same code over and over to get the same result. If the result of a particular function or query will be the same for the life of a session, then execute it only once and store the result in a Package Variable. Accessing the package variable is far less overhead than continually executing a query or function even though the result might be cached.
Although there are myriad approaches to tuning code, it all basically starts with identifying where the problem is. The above methods will definitely help you get to the root cause and once you have something more specific to attack, please let us know and I'm sure many of us would be happy to jump in and help.
Hope That Helps,
- Doug Gault -
http://sumnertech.com/