We help IT Professionals succeed at work.

Tivoli Storage Manager v6.2.3 "Database Cache Hit Ratio is too low." error

ambisset
ambisset asked
on
I'm running Tivoli Storage Manager v6.2.3 and every evening I'm getting "Database Cache Hit Ratio is too low.       89.8 < 98       Increase bufferpool size value."

However all searches for solutions refer to TSM v5.x when it had a custom database. The solutions all revolved around managing the custom database. Now that TSM v6.x is using DB2 as far as I can see this issue has a totally different solution from 5.x that needs tackled from the DB2 side.

I'm not really that up to speed with DB2 although I am an Oracle DBA so do have lots of DBA experience. Can someone point me in the direction of the way to fix this issue please.
Comment
Watch Question

the simplest way to improve the hit ratio of an application you can't change, is just to increase the buffer pool size
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0052482.html
CERTIFIED EXPERT
Most Valuable Expert 2013
Top Expert 2013

Commented:
Hi,

check the DBMEMPERCENT server option.

This is used to specify the percentage of the virtual address space that is dedicated to the database manager processes, which also influences the size of the database cache.

If set to AUTO the value will be approximately 70 to 80 percent of system RAM.

So if you have set AUTO and still a too low Hit Ratio you simply don't have enough RAM.

But please keep in mind that there might well be DB utilization peaks lowering the ratio which might not last forever.
Did you restart the TSM server - maybe the cache data are heavily scattered so that rebuilding the cache could help?

wmp
ambissetIT Manager

Author

Commented:
@woolmilkporc - DBMEMPERCENT option is found where? DB2 control center? Some config file for DB2? I know precious little about DB2 and how to configure it so its configured precisely the way the TSM v6.2.3 install set it up.

The server has been restarted dozens of times and problem persists. Server has 8GB ram and TSM is the only application on it. Task manager suggests just 5.25Gb in use.

Is there a manual cache rebuild option?
CERTIFIED EXPERT
Most Valuable Expert 2013
Top Expert 2013
Commented:
It's in the server options file (not in DB2 config)

<install_dir>/config/dsmserv.opt

You must restart the TSM server to activate a change.

If the parameter is not mentioned there the default of "AUTO" is assumed.

If you didn't change anything during setup I'm pretty sure that you're using AUTO.

Reading your comment I assume that your OS is Windows. I'm not familiar enough with Windows to be able to tell you how much memory you could additionally take away from the OS, sorry.

You should take into account the size of the DB, the number of nodes and the number of transactions in a given period.
At first sight I'd say that 8GB is not much for an average TSM server.

Our database has roundabout 95 GB serving 250 nodes, which is not a huge thing for TSM, but nonetheless we need 12 GB RAM to keep the cache hits and overall performance at a reasonable level (hits 97.8 %).

And No, there is no manual cache rebuild option.

wmp
ambissetIT Manager

Author

Commented:
Thanks, that should fix things, easy when you know where to look.

Our database serves just 22 nodes and runs as you guessed on a Windows server so 8GB should be fine given that it tops out at around 6GB.. I am not that familiar with DB2 as our principal DB is Oracle and I am the IT department so TSM is a sideline to keep everything backed up and so not event close to being my primary role. Hence I'm not that familiar with all the configs and essentially hidden options like this ie: not mentioned in config file so I'd not know about it.

Thanks again for the assistance.