It's not "good practice" to delete anything from the SBDATA directory - it should never need touching. But, what you are doing is corrupting the name index for users and machines and forcing it to rebuild on the next access.
The cache naturally expires according to the settings in the dbcfg.ini file - corrupting it (and forcing a refresh) just makes it rebuild when you choose, rather than on the first access after expiry.
So, after corrupting it, you really need to force a refresh, otherwise the first activity of the day will have to wait for the cache to be rebuilt. That's what the old ToastCache5 script does.
Just corrupting it and waiting got you nowhere really.
As for the index on the other object types, there's usually far fewer of them, so building the index for them takes minimal time. They will still expire on the timeout naturally.
Agreed. Yes, we stopped services, blew it away, then logged into the Database locally. The first login rebuilds the User Cache and then when we manipulate a machine object, this rebuilds the machine cache. It takes a while (15-30mins for each cache) but then we open up the Database Service to connections and things are better (what with the index being freshly built now).
It seems that once in a while, depite setting the cache to delete each night, the database gets in a tizzle, and the first indication of that is high CPU from SBDBSERVER.EXE. Refreshing the index has worked in most cases, although it takes us out of action for a while while we rebuild it. I was just wondering if it's always the Machines and Users index that gets 'corrupted' or if it's worth doing the others too?
We set the dbcfg.ini file so that there is no lifetime expiry, this is so we don't get any unexpected reindexing during working hours. Instead we manage with the nightly ToastCache. The ToastCache has the benefit of forcing the User and Machine caches to rebuild before the first person uses the database (although now we support Globally, there always SOMEONE trying to connect at any time!).
Hmm. Then in your case the other name indexes will never be rebuilt.
In theory you should actually never need to rebuild them - The expiry is more of a catch-all to solve the problem of flaky network connections and groups exceeding the reccomendation.
If you have set your cache to NEVER rebuild on its own, you need to handle the other object classes manually. My reccomendation is to manually rebuild user/machine more often than your cache timeout, but you still need a timeout for the others.
Thanks. So basically this would mean setting an expiry (say 7 days) but still manually rebuilding the Users and Machines every night. In this way, the Users and Machines are never rebuilt at unpredictable times (as they never get 7 days old) but the other caches will rebuild every seven days.