Tom Conlon wrote:

> The problem has been located in a key trigger and appears to be sorted.
>
> Getting back to the original question, surely someone has some advice
> regarding the values to use - please?

Unfortunately, the right number is application dependent and probably
dependent on the stage of an application. The goal of the page cache
is to keep all *frequently referenced* pages in memory.

In the case of a backup with gbak, for example, all that's needed is
two or three pages to hold the current data page being read, a pointer
page, and possibly the header page. Any application that's doing a
linear scan will work well with a very small cache. If you're doing
a mass insert, you need to keep several levels of each index on the
table in cache, and the current pointer page, and probably a page
information page (free space manager). A multi-way join works best
if small tables, as well as all involved indexes should be cached.
So there is no one right answer.

You could try increasing the cache size dramatically and see if that
helps - then lower it by stages


Regards,


Ann