A couple of things could be the database files have grown large or there are a lot of queued messages on the thread.
You can use the db init command (hcidbinit) to re-initialize the database files – BE VERY CAREFUL WITH THIS COMMAND – it will wipe out all queued messages in the recovery and error databases for that site. When I need to issue this command, I do the following steps:
do a setsite command if you are doing this from a text session
shut down all incoming threads in the site
wait for all the messages to clear out. The alternative to this is to use the hcidbdump command to offload all the messages, but this is cumbersome if there are a lot of messages and/or threads since they need to be offloaded by each destination and state.
once all messages have cleared out, shut down all other threads and processes for that site.
Stop the Lock Manager and Monitor Daemon for that site
Issue the db init command (hcidbinit). I use the “-ACf” flags with it – look in help for explanations.
The process had 830k messages in the recovery DB. This is a test system so I exported and cleared them out. There are no messages in the recovery or error DB’s. However, I’m still seeing slowness in the process coming up.
By clearing them out, do you mean you just deleted them or did you do the database initialization? If you didn’t do the initialization, the database file is still at the same size it was with the 830K messages and will take a while to load up even if it is empty.
Deleted. I did the dbinit and the processes are starting up as expected now. Thank you for the help. Since the DB’s size won’t change when the messages are deleted, is it recommended to reinitialize the DB’s when they grow this large?
Limit the size of the DB? No. If we did that then data could potentially be lost.
If you are really worried about space and speed, you can turn off recovery DB in your test environment if you don’t need to worry about persisting the messages when you stop and start things. This is a setting on each thread’s properties.
Note that the database file size will reach a “high water mark”, that is if messages are deleted from the database, the space will be re-used as new messages are added.
Another thing you can do to shrink the size of the database non-destructively is run the following commands (lock manager, all processes need to be shut down first)
Future PROD environment. Our current LIVE / PROD (6.1) cloverleaf resides on the same server. I am working on moving over to this new server (19.1.1). I’ve moved a few things over and am using it for non-critical interfaces and some testing until 19.1.2 has came out at which time, LIVE and PROD will then be on 2 separate servers.
.
