Errors after a database defrag - Priv.edb 4

[Knackers]

Hi,

I ran into a bit of a problem yesterday with my exchange server (5.5 SP3). The Priv.edb had filled the drive that it is located on to capacity. This resulted on a loss of outbound email (the internet information service could not start due to lack of space)

To try and compact the database file I ran a eseutil, but the only place I could send the rebuilt file to was on another NT server. The defrag reclaimed nearly 3 Gb of space, but when I copied the defrag file back into the MDBData folder, the Information store will not start up the error meassage is:

The Microsoft Exchange Information Store service terminated with service-specific error 4294966766.

I also tried to do a Ininteg -patch , which returns the same error.

Is in not possible to copy thePriv.edb file accross in this manner? Any suggestions?

In the worst case scenario, will I be able to just restore the old Priv.edb from a backup?

Thanks

 

[ShackDaddy]

The problem is that the transaction logs aren't in the exact same state that they were when you originally started your compression. The Store service must have been started and stopped again since then, making the current transaction logs incompatible with the compressed database. You may want to start from scratch again, well, not scratch really. Did you delete the uncompressed .edb file, or did you move it somewhere else? If you could put it back and start things up, you might be able to get a fresh start. Or it could have been that running the utilites pushed the transaction log compatability away from both the fresh file and the old file.

You might just have to restore the priv.edb from backup to recover, like I had to do once in this exact situation.

If you do restore the old priv.edb from a backup, make sure that you also restore the transaction logs that were backed up with it, otherwise you might have some trouble, depending on whether you use circular logging or not.

If you have the transaction logs handy, and you didn't use circular logging, you should be able to:

1) restore the old database (but don't start the 'store' service)
2) delete the edb.chk file
3) start the store service

This will allow all the recent logs to play into the restored database and bring it up to date. If you start the store service without deleting the edb.chk service, you've blown your chance to bring your database up to date with the logs.

If you did use circular logging, the chances of success will depend on how old the most recent backup is.

Hope this helps,

ShackDaddy

 

[Knackers]

shackdaddy,

Thanks for the lightening response. Your analysis was spot on. The information store had been started since the defrag(to do a second back up of the Priv.edb) But before that occurred, I got a full backup of the MTBData folder - will this be enough to do a resore with? Where are the transactional logs located? And is there any reason why they would have changed in light of what I have done.

Any help would be great 'cos I'm not feeling too good right now.....

 

[ShackDaddy]

I'm not sure where your transaction logs are located. They are typically in the same directory as the main .edb file, but admins often move them somewhere else.

If you got a full backup of the folder that had the priv.edb and a bunch of edb*.log files in it before you tried to replace the .edb with the compressed one, you should be able to restore that folder completely and start again. The current .edb and logs are junk. Overwrite them with the backup of that directory you mentioned.

 

[Knackers]

Thanks - I have started the restore, it is 13.7 Gb, so it's going to take a while.The folder only contained the Pub.edb and Priv.edb - no other files.

I am hoping that the transactional logs were not changed when the information store was started between when the old Priv was defraged and when it was replaced with the new one. Theoretically, when it is done, I should be able to start the services up again and things should be as they were. If not, am guessing that I am going to have about 50 very pissed people. I am on UK time, so looks like a long night...

 

[ShackDaddy]

Sounds to me like your transaction logs have definitely changed, and that you didn't get a backup of them when you got a backup of your main .edb files. Since you did that backup, you've started and stopped the service several times, it seems, so the current transaction logs are all you have to work with. Since it doesn't sound like they got backed up, don't delete them now. There's still a chance that you can follow my instructions for using the logs to recover from an older backup of the database like I enummerated in my first post.

Good luck. I'll check in in a couple of hours to see if you have any new questions.

 

[Knackers]

Shackdaddy,
I think that I have found the transactional logs. I think that the optimiser must have been run on this server, because there are 2 exchsrvr folders - 1 on the C:drive and one on the E:

The MDBDATA folder on the E: has the priv & public edb's and the while the one on the C: appears to have some log files (edb.chk and text files edb, edb031A6, edb031A7, edb031A8, edb031A9, res1 and res2)all of which were last modified around 5pm yesterday.

Do you think that these are infact the transactional logs, and what would potentially be the next step if the restore yeilds the same bad signature log error?

 

[ShackDaddy]

Ok, your best bet is still to delete the edb.chk file, once the priv.edb has been restored, and then restart the information store service. If that doesn't work, delete the logs (those are the text files) and the .chk file altogether and start your information store service. It will be restored from the time it was backed up, and will create new log files on its own. Read through the topic that Caustic started today for some more helpful information.

ShackDaddy

 

[Knackers]

Shackdaddy - I report to you with success. By deleting the edb.chk file and restoring the priv & pub.edb's I was able to get the information service started once again.I now have all of the mail upto when I stopped the services yesterday.

So, I am now back to square one. My MTA won't start because I have less than 10Mb of space on the disk. So - now I have to free up some space. The eseutil seemed to work fine - it reclaimed nearly 3Gb after compaction.

Obviously I need to run this again and not mess it up! I don't have the space for the defragged file to be rebuilt on the server that has exchange running on it, so my best bet is to use the t switch to send it to another NT server. Can you give me any tips on the steps to take to successfully defrag and return the compacted file into use?

Forever in your debt.

 

[Zelandakh]

Knackers - don't you have a larger volume on that server that you can use the optimiser on?

If not, then you do need to run the eseutil with a -t switch but use a manually mapped network drive that points to a really fast hard disk on another server that has no lag.

ShackDaddy - nice one! You really know your Exchange Server. Kudos and a big purple star to you.

 

[Knackers]

Zelandakh & Shackdaddy.

If only I had a larger volume... The priv.edb file is 12.8Gb, which compacts to under 10 after using the eseutil. I did manage to successfully use the t switch to rebuild the edb last night, but was unable to get the services started (due to inconsistant log files).

Since I had to restore last night to the old edb, I am again running this utility as we speak.

My plan then is to back up the original edb again, delete the old uncompacted file and import the defragged file.

When I restored last night, the only way that it worked was to delete the edb.chk file. I assume that I will have to do this again before trying to start the services with the compacted file -Shack could you advise?

As I understand it, as long as none of the services are started at any stage of this operation - I should be in luck?

 

[Zelandakh]

Can't you cheat? Stick a disk on from a client workstation or some other piece of kit that has enough room to do the compact on that server then remove it and put it back where it belongs?

In theory your way detailed above will work fine - in practice the -t switch is flakey to say the least!

Are you running this on NT or 2000? If 2000, you have the option to mount as a sub directory. But I'll bet you are running NT or you'd have thought of that!!!

I'm going to replicate your problem tonight in my lab and see if there is any other way around the restore issue.

 

[ShackDaddy]

Knackers, you are right. If you stop the information store, then run the defrag on a different system, you should be able to bring the defragged file back and start the store again.

Try and use the -t switch, and you should be set. And of course, please don't start any of the services until all the files are back in place.

I'd like to take this time to point out the book that originally taught me all I know about Exchange disaster recovery, even at the risk of reducing my own future glory: Microsoft Press's <u>Managing and Maintaining Microsoft Exchange Server: Notes From the Field</u>. All the important Knowledge Base and Resource Kit information has been converted to a well-organized book format, and it's been a critical resource for me.

Something else to keep in mind: circular logging can be a way to shoot yourself in the foot, since it doesn't guarantee you that the logs will bring you up to currentness from your last backup (if your last backup is too old). You may want to disable circular logging in the future. I think I will write a FAQ on circular logging, since it can be so critical to ones recovery options.

Glad to be helpful,

ShackDaddy

 

[Knackers]

Shackdaddy - thanks for the tip on the book. Definietly worth investing in for a novice like me. I will check it out.

One last question while I am waiting for the edb files to backup. Can you you confirm that I will need to delete the edb.chk file again before starting up the services.

Thanks again for all of your help.

 

[ShackDaddy]

If you in a situation where you have transaction log files that are more recent that the database you are restoring from backup, and you are restoring from your most recent backup, you should delete the edb.chk file. When you start the information store, this will cause the transaction logs to dump their transactions back into the database and bring your database as up-to-date as possible. I don't think that this is your situation.

When you stop your information store in the standard way, without killing any processes, all the log files commit their transactions to the database. If the last time you stopped your store, it was healthy, you should be able to delete all edb*.log files now, as well as the edb.chk, which governs which logs should be dumped to the database. It may not even matter whether you actually do so or not. Caustic had to worry about this, since he had a system crash, but you don't.

 

[Knackers]

Shackdaddy - just a quick note to let you know that I managed to resolve the problem in the early hours of Friday morning. Thanks again for all of your help.