To kill the the Database 1

[eljefe79]

Hello All,

I have a bit of a problem. Theres an entire exchange 5.5 multi-site infrastructure built up a document imaging system. The developers are gone, know nothing about exchange and the central server handling routing in the corp ran out of disk space last night.

The server survives in a single site with a web of connectors to the other satellite locations. None of the exchange boxes are backed up and use circular logging.

The exchange 5.5 server for the site ran out of disk space for a Priv store of 24GB, I managed to get a smidge of disk space and added a new volume...the array could not be expanded. I ran a soft repair on the database to get exchange up, tried an offline defrag with no luck...it locked in process. From best estimates I've got 20 GB of white space.

Tried to migrate to a new volume, the exchange performance optimizer failed with an application error. I tried adjusting the paths and the exchange admin client failed.A soft resovery got me functional once again.

I'm now in a situation where I believe that the database has hard corruption but I'm looking at potentially 16 hours of Hard repair, defrag and isinteg to maybe get the db functionally down to a manageable size.

What I'm looking for is a relatively quick solution that will allow me to reset the core database structure--make it a manageable size..then get it to a new volume.
I dont care about the mail in the database...that can be pulled from an image store...I just need to essentially have a raw database with empty mailboxes again.

I've never been in this pridacament before, no backups, poor management and lousy design. Also where we didn't care about the contents of the mail DB. I would rather not end up having to kill the site and recreate the core for the sake of the database.

Any help would be much appreciated

 

[zbnet]

Wow, that's a mess.

If you want an empty priv.edb, you need to stop the Exchange IS service, and then delete (or rename if you want the option of ever undoing it!) the priv.edb file and all the \mdbdata\edb*.log files that are associated with it. When the IS service is restarted, it recreates an empty mail database; then a DS/IS Consistence Check will create stub (empty) mailboxes in the database based on the Directory.

I'd really recommend you also have a read of the DR whitepaper for 5.5 that is referenced in one of the FAQs for this group.

 

[eljefe79]

Zbnet..... thanks for the help. Darndest thing, just couldn't find that step mentioned anywhere.


I resolved the issue then they came to me and said that they really wanted to save some of the mail in the database. Well, I commented that that is what a backup solution is for but hey they decided you didn't need one so game over. Actually the on-track toolkit came in handy for that little eventuality...but I had to make them sweat a little

Thanks again ZB

 

[zbnet]

No problem, glad you managed to sort your problems out!