HI Clovis,
there is actually nothing to do much about this.
Unless the problem is caused by a too small buffer cache - in that case you can try to increase the CACHE_CAT_SUPPLY parameter value as you did.
The MAX_USER_TASKS parameter don't have any influence in the catalog cache hit ratio. Anyhow - if you can cut this parameter to a third without loosing application functionality, then do it - and put the now unused memory to the database cache!
Since you described that after increasing the catalog cache size the cache hit ratio stayed at the same level I see only two options why this could be:
- catalog entries are deleted/created often
- only a few acesses are repeated to specific catalog entries.
Since the cache will only be usefull for any access after the first one, the bad cache hit ratio may be the result of too few repetitive acesses.
In this case this is not a performance issue and can be ignored.
Remember: as with all cache hit ratio performance counters you cannot say anything about the real performance. Such ratios hide more information than they disclose. So at best they give you a hint where you can further go looking for causes of performance issues.
In itself the number does not have any meaning.
KR Lars
p.s.
I forget to mention: in MaxDB the Catalog Cache is a user task local cache.
That means that the same catalog objects will be cached locally for each user task acessing these objects.
So if session 1 reads catalog information about table A for the first time you get a cache miss for that. If session 1 reads the same information again you get a cache hit (2 accesses, 1 hit -> hit ratio 50%).
If session 2 now accesses the same data, it does not access the local cache of session 1 but will load the same data into it's local cache as well and produces 1 cache miss. So we have now 3 accesses, 1 hit -> hit ratio 33%),
Edited by: Lars Breddemann on May 5, 2008 3:45 PM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.