I’m strongly inclined to agree with you about “other parts of Oracle circumventing the need”. (The cynic might, at this point, check the TPC-C disclosures to see which bit of the TPC-C data set Oracle put into the KEEP cache – and ask why.)

There was an interesting defect with “smallish” tablescans in 8i and 9i that made it worth KEEPing tables as a short-term damage limitation option – but apart from that I don’t think there will be many people who really see a benefit from KEEP.

The strategy I use is basically: check v$segstat (Segments by … in the AWR/Statspack) and IF I find a segment which is responsible for a large fraction of the physical I/O, and IF I can work out that this isn’t just some inefficient code or poor indexing, and IF a very large fraction of the object is already cached, and IF I can’t see an obvious threat to the rest of the data set by taking away some of the DEFAULT cache, then I will suggest a temporary switch of cache from DEFAULT to KEEP – and check what this does to the physical I/O of that segment and the general level of physical I/O on the whole system.

Nevertheless, I notice in all OLTP I ever did looked into, that small and medium tables are still doing gets and no physical reads, and if there are physical on these objects, increasing the buffer_cache solves the issue. In respect of the big tables, they are too big to fit anyway. So I am reading you articles with interest but do not find any clue as of why I should set a feature that up to now, I could do without.

My feeling is that the KEEP is like the FIRST_ROW : something Oracle did, but in fact other parts of the engine, circumvent the needs. I recon, I might be wrong, but up to know, the need for a KEEP cache never come up or I was not smart enough to detect its needs.