Reg: result_cache in parallel -

Question

Hi Experts,
I have few concern(s) regarding the Result Cache (introduced in 11gR2) and the /*+ RESULT_CACHE */ hint.
Refering to -
Doc 12.1 - Tuning the Result Cache
Murali Vallath - Using Oracle Database 11g Release 2 Result Cache in an Oracle RAC Environment
Adrian Billington -- query result cache in oracle 11g
Concerns -
(1) Suppose I have a master ETL job which has 5 sub-jobs. These sub-jobs are executed in parallel i.e. started all at once from ETL.
Each of these sub-job executes an extraction query and pulls data from database.
In each of these sub-job queries, there's a subquery which is common. I am thinking to provide /*+ RESULT_CACHE */ to this common subquery.
But my actual concern - since all the extraction queries (i.e. sub-jobs) are started in parallel, will the Result Cache thing come into picture?
(2) For how long the data is retained in the cache?
A wild guess - till the point we execute the DBMS_RESULT_CACHE.FLUSH procedure ?
(3) Any caveats?
(Trying to fix few costly time-consuming queries, and suddenly this option came to my mind. Took the opportunity to look at this cool feature, at the same time understanding the caveats, if any)
Please advise me on this.
-- Ranit
(on Oracle 11.2.0.3.0)

Answer 1

Hi.
2.1) 50Mb can store approximately 50Mb of data. The amount of stuff you can sore depends a number of factors, including:
- How many queries or function calls are being cached.
- With respect to the query cache, how wide are the rows. We are talking size of data in the columns.
- How many rows are being returned.
So you might have a few larger result sets, or many small ones.
2.2) Well, it can't. The RESULT_CACHE_MAX_RESULT parameter determines the maximum size of a result set that will be considered for caching. By default it is set to 5, which means 5% of the size. So let's say you have a result cache of 100Mb. By default, a result set in excess of 5Mb will not be considered for caching. This stops you wiping out useful information in the cache by trying to cache one big result set.
The reality is, if you start to use this feature you will have to monitor the cache performance and be selective about what you cache and what you don't. The default sizing parameters are not going to be suitable for everyone. You need to alter them based on your monitoring. Nobody in a forum will be able to tell you figures to set. If it were that easy, Oracle would do it for you.
Regarding your "alternative solution", I don't really want to comment on that specifically because I don't know enough about the system. Typically, it would not be something I would do, but maybe it is the right thing for you to do in your case. Impossible for me to know. Things to consider in preference to your alternative solution.
- Scalar subquery caching: If the subqueries are scalar subqueries (pulling back a single column/object in a single row), it will already be taking advantage of scalar subquery caching, so your alternative solutions may actually give worse performance. There is no sharing between SQL statements or sessions.
ORACLE-BASE - Efficient Function Calls From SQL
- Use a WITH clause to replace the subqueries and use the materialize hint. This way, the subquery is automatically materialized into temp segments, so multiple references to it within a single statement query the result from the temp segments, rather than the full subquery. There is no sharing between SQL statements or sessions.
ORACLE-BASE - WITH Clause : Subquery Factoring
The reality is, there is not going to be a "best" solution that works for all cases. What you need to do is try several approaches and pick the one that works best for your circumstances. The next time you run into a similar issue, you can't assume what you did last time is the right solution this time...
Regardless of which option you pick, you need to read the docs and feel comfortable with the tech before you launch down the path. No matter how good a feature is, if you use it badly you will make that feature look bad. 
Cheers
Tim...