cancel
Showing results for 
Search instead for 
Did you mean: 
Odgeuk
Level 7
Report Inappropriate Content
Message 1 of 5

Deleting Database Index - ToastCache

Jump to solution

Hi,

We delete all files names.* from the SBDATA Machines and Users folder in the database, every night. This is the index files in the 00000001 and 00000002 folders.

There are also names.* files in the other root directories...i.e 00000003....00000004, 0000ce00 etc

Is it 'safe' or good practice to delete those too?

In my distant memory, I recall SbDbServer.exe running high CPU and not responding, until we manually blew away the names cache for users and machines, and can't remember if we also had to do it for the other directories in order for the system to return to normal.

Running EEM 5.2.2

1 Solution

Accepted Solutions
Reliable Contributor SafeBoot
Reliable Contributor
Report Inappropriate Content
Message 4 of 5

Re: Deleting Database Index - ToastCache

Jump to solution

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.

View solution in original post

4 Replies
Reliable Contributor SafeBoot
Reliable Contributor
Report Inappropriate Content
Message 2 of 5

Re: Deleting Database Index - ToastCache

Jump to solution

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.

Odgeuk
Level 7
Report Inappropriate Content
Message 3 of 5

Re: Deleting Database Index - ToastCache

Jump to solution

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!).

Message was edited by: Odgeuk on 05/12/12 10:04:22 CST
Reliable Contributor SafeBoot
Reliable Contributor
Report Inappropriate Content
Message 4 of 5

Re: Deleting Database Index - ToastCache

Jump to solution

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.

View solution in original post

Odgeuk
Level 7
Report Inappropriate Content
Message 5 of 5

Re: Deleting Database Index - ToastCache

Jump to solution

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.

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community