On Database startup trigger and pinning objects in keep pool
cayenneSep 2 2009 — edited Sep 4 2009We're using a commercial package that for performance reasons requires that a couple of tables and indexes be kepts in the KEEP pool.
We did some experimentation, by running the application with the objects both and out of the keep pool, and of course it really made a difference.
One thing that was interesting, was that even after doing something like:
ALTER TABLE table1 (buffer_pool KEEP);
The table was 'pinned' to the keep pool, but, its contents didn't seem to be actually moved over and cached there, till there was a query (we did one with a full table scan) was performed.
Is this normal is this the case?
If so, that means you have to alter the table to keep pool, then run a full table scan to actually cache its contents?
That brings up my second question. I was wondering about what happens to table one when the database is bounced. Does the table stay in the keep pool on start up? If so, is all the data in the table in the keep pool automatically cached, or do you have to 'reload' it as described above?
That brings me to my latest research, what appears to be a stored procedure: dbms_shared_pool.keep('table1')
I've seen some documentation that seems to say you need to do this to put your tables into the keep pool by setting this off on a 'on database startup' trigger.
If this is true, does it automatically cache the table1 tables contets, or do you need as I described above, to do a full table scan query to cache it contents?
Thanks in advance or any suggestions or links,
cayenne