Oracles function result cache (FRC) works, in simplified terms, by caching the result of a PL/SQL function. This can greatly improve performance, but it can also lead to performance problems.
Read More »Category: Optimization
Forall is still row-by-row
I came over some code that used the forall construct to update rows in a large table. Quite a few rows were updated and the batch took some time to complete. Usually, using forall is a good idea, but sometimes other constructs can perform better.
Read More »Which tables could need updated statistics?
Does your tables need updated statistics for the optimizer? Here’s a couple of views that could be useful in the gathering of information.
Read More »Statistics gathering parameters for partitioned tables
When partitioned tables get a bit large, these parameters may be suitable to set.
Read More »Generating data: union all vs insert all
To test out different physical table lay-outs, I had to repeatedly generate some test-data. After a few runs, I wanted to speed it up a bit. This is how I did it.


Reviewing statements with hints, using PL/Scope
In my previous post, I showed how you can add a fake hint to tag the origin of a duplicated statement and as a side-effect make it unique. What if you regret and can’t remember where it was. Or you want to review old hinted statements after an upgrade to a newer version of the database/optimizer.

Differentiating between duplicated statements
Finding duplicate SQL statements using PL/Scope is easy. If you cannot merge them, how can you differentiate between which source is being run?

Find bad performing queries or code with PL/Scope
On our production system we’ve enabled the collection of PL/Scope metadata. Since this is a SmartDB/PinkDB-application (business logic and queries in the database), this makes it really easy to find, inspect and modify the source code of queries that doesn’t run efficiently. Now it’s even easier using reports in Oracle SQL Developer.

Finding bad queries in a package in a flash
I was going through some of the Top SQL-reports in SQL Developer, running them against our production system.
One of the “culprits” that showed up was a procedure call, not a query. A quick investigation showed that this procedure was fairly large and consisted of quite a few queries.

Function result cache and application context – don’t get burned
Oracles function result cache (FRC) can in certain cases give a considerable performance boost. Application context is another useful feature. How does FRC work when the function result relies on context-settings? And how can we make them play well together?