Deleting unicode fixup table - Uh oh... (Full Version)

All Forums >> [Microsoft Exchange 2003] >> Information Stores


dcollar -> Deleting unicode fixup table - Uh oh... (13.Apr.2006 4:41:51 PM)

One of our clients has an Exchange 2003 Std SP1 installation that just bumped up against the 16Gb limit. We had them do some house cleaning and did the 17Gb hack to get them temporary extra space which got the system back on an even keel but when we tried to do the offline defrag to compress their database the result showed us it was corrupt and failed about 10% into it. The store mounts and runs fine and backs up OK but we are unable to defrag and now we have concerns that bad things are on the horizon.
I know everybody says the best thing to do is a restore from b/u if at all possible and we have several good B/U Exec 10 backups dating back months. The problem is that we have no idea how long this corruption has been in place so we don't know when to do the restore from.
Because of this we don't believe doing a restore is a viable option.
They are still running on the corrupt store but we think it appriopriate to fix this before going to SP2 (for the availability of extra space). We got a copy of the store and took it back to the shop where we could play with it. We tried more defrags with the same result (no big surprise there...). We then ran a eseutil /p repair to see what happened. The resulting message was "Deleting unicode fixup table" and it finished succesfully. Then we did a defrag and it finished successfully too. Because we were just experimenting with the store, we have not remounted it.
When we started this process the priv1.edb file started at over 13Gb and ended at 9.6Gb.
One last thing that makes me wonder - The repair took 46 minutes and the defrag only took 54 minutes. I've been told these things take HOURS.
Question #1 - What the heck is the "unicode fixup table" and is the priv1.edb file size reduction due to loss of data or just the defrag compression.
Question #2 - Our client has agreed to buy a new upgraded server.
Should we try to fix the database in place or fix this by migrating everything to the new server?
Question #3 - If the answer to #2 is migrate to the new server, how should this be done? Does anyone know of a proceedure I can follow that would take this corruption problem into consideration?
Note: I read somewhere that logical database structure corruption is not detected by backup programs.
Question #4 - Because I don't know when this occurred and the b/u programs don't detect this kind of corruption, how am I supposed to do the restore and how can I prevent this from happening again?
Anyone's insights into this problem would be greatly appreciated.

Page: [1]