Augusto Estefan · Jun 9, 2021

Cache database "cachetemp" is getting huge


I have a DR member and in this cache server the database "cachetemp" start to getting bigger without any reason (50GB that was all the free disk space we have)

In the members of the mirrors the cachetemp its ok and the size is 31MB.

I restarted the server because I read that the cachetemp database purge when restarting, but didnt happend.

Any recommendation to clean this database? can I just deleate the CACHE.DAT from this database?


Product version: Ensemble 2016.1
$ZV: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.2.1 (Build 806_0_17136U) Tue Mar 7 2017 12:32:06 EST [HealthShare Modules:Core:15.02.9912 + Linkage Engine:15.02.9912 + Patient Index:15.02.9912]
0 490
Discussion (4)0
Log in or sign up to continue

I would recommend seeing what's stored in the database, for this, you can use %GSIZE and count all the globals,
and you may find which global(s) so big.

And you can stop the server, delete CACHE.DAT, and start it again, and in this case, it should be recreated anyway

To elaborate a bit more on this and add to the other comments - when you restarted Caché the contents of cachetemp are cleared out, so you won't be able to find out what was in there anymore. It would have been good to investigate prior to restarting, but now there's no direct record of what was in the database, unless you can determine indirectly what was happening on the DR to cause this.

Though the database is empty on startup, the database size on the OS level won't have changed. Cachetemp doesn't automatically truncate because once it expands to a certain size, it doesn't know if it will need to expand to that size again. To enforce what you think the appropriate size for cachetemp would be based on your environment, as Dmitry says, you can delete it to have it be recreated and reexpanded as necessary.

There is also a cpf parameter that limits cachetemp size at startup, MaxCacheTempSizeAtStart:

If you are certainly sure, you have restarted the instance and the OS space and new size  after startup (as seen in system management) portal don't match, a 'truncate' will release the OS space immediately. I've encountered same issue  and this is what i've done.