4 Replies Latest reply on Dec 5, 2012 10:27 AM by Odgeuk

    Deleting Database Index - ToastCache

      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. Re: Deleting Database Index - ToastCache

          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.

          • 2. Re: Deleting Database Index - ToastCache

            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
            • 3. Re: Deleting Database Index - ToastCache

              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.

              • 4. Re: Deleting Database Index - ToastCache

                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.