IS Maintenance doesn't do Priv.edb - urgent

Exchange 5.5 SP4
Win NT 4.0

I've run IS Maintenance for the 1st time on my Exchange server.  It's done maintenance on Dir.edb and Pub.edb but not the Priv.edb

I don't have the option 'Don't permanently delete items until the store has been backed up' selected.

I ran it for 4 hrs earlier in afternoon and have ran it for 4 hrs again later. When I look in the Event Viewer I can see entries for Dir.edb and Pub.edb a few times saying it's completed the pass on those databases and I can see log 1221 saying it has so much free space in Pub.edb. However, there is no mention of Priv.edb in the Event Viewer anywhere.  

Why is IS Maintenance not working on Priv.edb?
What do I need to do?

File size for Pub.edb = 2.2Gb
File size for Priv.edb = 27.8 Gb

I need to do the maintenance this weekend, so pls reply quick.

Thank You Very Much.
Who is Participating?
kevalaConnect With a Mentor Commented:
Okay, the log files are there for recoverability purposes. When a transaction is made to the information store databases, it gets written to memory on the server, and to one of the log files on the server. If the server were to crash and we lose the data in memory, then we would have a copy of all transactions held in the log files. So YES, they are very important and you should not make a habbit of moving them out. If you need to move them to a drive with more space, then you can run the performance optimizer and specify a different drive.

The log files are purged/deleted with every Full and Incremental backup that you do. Yes it does make sense that there are more log files there, but don't delete them, if you do it once, then you might be tempted to do it again and get bitten the second time. So just make sure you are doing full backups and the log files will get deleted off the hard drive.

It is a good thing that you do not have circular logging check. This allows you full recoverability in the event disaster strikes against the drive with your databases. You can then restore from backup, then play in the log files all the way up to the point of failure and not lose a thing....
Well, i would suggest allowing maintenance to run alot longer against the priv.edb. Online maintenance must first COMPLETE it's pass on the priv.edb before it will report how much free space is in it.

Online maintenance has ran for a total of 8 hours against your database, but that apparently isn't long enough to finish against the priv.edb. I would let online maintenance run longer in order to finish -

Online maintenance will run as scheduled, but most of the time it cannot complete a database that large in one scheduled run, so each time it runs, it picks up where it left off.

If you are looking to lower the size of the priv.edb, i would suggest first running the following command:

eseutil /ms "X:\exchsrvr\mdbdata\priv.edb"

When this command completes, there will be a number in the bottom right hand corner under the final line. This is the number of available pages in the database. You can take this number and multiply it by 4. 1000 pages at 4KB each equals 4000 KB = 4mb. Of course your number will be alot bigger for a database that size.

You can then determine if an "offline defrag" is needed here. When you run an offline defrag (eseutil /d /ispriv) - this will actually remove the white space and lower the size of the priv.edb.

Now if you decide to run the offline defrag, you must remember that you need 110% free space available for the temp database that gets created. So in your case, you will need at least 31 gig free.

27.8 free, + another 10% - so 27.8 + 2.78

If you do not have enough free space local on this drive, or on this server, you can always temp the database to another server with:

eseutil /d /ispriv /tx:\tempdfrg.edb

/t = Temp
/x = drive letter mapped to the other server
\tempdfrg.edb = temp database that gets created to do the defrag....

Does this help any?  <-_->
One more thing, if you do decide to do the defrag, it can take anywhere from 45 minutes to 1 hour per gig, and sometimes more if you have to temp the database to another drive. So it could take you 15 to 30 hours to do an "offline" defrag. Just FYI
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

shahid_hussAuthor Commented:
Hi TX for the reply.

I've scheduled the maintenance again and this time I've scheduled it for 10 hrs, that should be long enough :-)

You were right, I didn't allow it long enough. As it happens this morning when I looked at the Event Viewer, there were couple of events for Priv.edb but ofcourse the scheduled time had come to an end.

Can you pls tell me a little more about this command you mentioned:
eseutil /ms "X:\exchsrvr\mdbdata\priv.edb"

Does it only check for space or does it actually do or make any changes?
Any danger in running this command?

(I'm new to Exchange and we don't have anyone else in company who knows Exchange so a little extra cautious.)

Also once the online IS maintenance has completed and freed up disk space inside the database, should the performance of our Exchange server increase?  Or will that only happend once I've done an offline defrag? I will at some stage be doing an offline defrag as well (I have done that before).

Once again Thanks, reading your detailed reply game me lot of confidence.

Well, there are alot of situations where an administrator calls in and says, my private database is huge and i'm about to run out of disk space. We look at event id 1221 and see that online maintenance has freed up alot of space within the database. So i say, "hey, lets do an offline defrag and reclaim some disk space. We will run into an issue alot of the times because on this server, we will be out of disk space! They will ask, how do we complete the offline defrag with no disk space, then i respond, "do you have another server with 110% free space?" They will say, "Yes i do". So my suggestion is to run Eseutil /d and temp the temporary database location to another server. You see, when running an offline defrag, Eseutil actually creates a whole new database called tempdfrg.edb, it is actually extracting the data from the production priv.edb, and inserting only the used pages into the tempdfrg.edb. When running this command:
Eseutil /d /ispriv /tx:\tempdfrg.edb    
You are actually specifying to create the tempdfrg on a drive which has been mapped to another server that has enough free space.

This command is TOTALLY safe, if a defrag fails, it doesn't hurt anything because it is working on the tempdfrg.edb database. If anything goes wrong, you will still have the priv.edb in it's original location in tact. Of COURSE you still make a backup of it because nobody can detect disaster ahead of time, and you know Murphy's law, if something can go wrong it will, so still make a backup of the priv before doing the offline defrag.

Will online maintenace improve the performance? Yes it will, it not only detects white space, but it helps align pointers and data in a more efficient manner. It will say, hey, the space is empty right here in the middle of the database, let me move all of the white space to the end of the database and move all of the used space to the back of the database. Therefore you don't have pointer number 1,009,345,345,345 pointing to page number 10.

Offline defrag will help improve performance, as it does not even have to scan the white pages, you will have less to backup, and when commiting new transactions to the database, it does not have to worry about writing to the white space first. (Which, when online maintenace completes, the white space is used up again before the priv will grow)

So lets go over the temp command again - Remember, you only need to do this if you do not have enough white space on the server which you are running it from.

eseutil /d /ispriv = the normal command you run when defragging the database and you have enough room on the server to do it locally

/t = Temp  = this is just telling eseutil that we will be using a temporary location
x: = drive letter mapped to the other server  = first map a drive to another server - you will replace X with the drive letter name that you have mapped to the other server.
\tempdfrg.edb = temp database that gets created to do the defrag....

combine the entire command, and you are telling eseutil to perform a defrag in a temp location specifying x and the file name. It will automatically copy the database back and rename it to priv.edb as if you had done it locally.

as for:
eseutil /ms x:\exchsrvr\mdbdata\priv.edb  (x being the real drive the database is on)

This is a totally safe command. If i have a customer that is not currently running online maintenance, or we do not have any current 1221 events, we run this command to check for white space. It is only a scan, and does not make any changes. Just look at the number in the bottom right hand side once the command completes, multiply this by 4, and you will have the number of Kilobytes free in the database. You do have to have the services stopped, it does take a while to run, and the database is open, so again, it is a good idea to make a backup of the database since we know that Murphy will take any chance he can get to screw us up.

So..., just make a backup of the priv, and do the defrag in whichever manner resources allow. You'll be fine.
shahid_hussAuthor Commented:

The IS Maintenance went v well over the weekend and it was just a case of me initially not allowing it long enough to do a pass on Priv.edb.

I can see the results, Deleted Items cache has been completed for most users and it's better performance for them.  Some still have few hundred k of Deleted Items but that's cause I still need to schedule more IS Maintenance, which I will be doing.

Just 1 more query I have before I close this question.

All my logs are written to drive E. I've noticed that it obviousley wrote lot of log files during the maintenance over the weekend. However, it still has all them and the few that it has written since them (which it does nightly) stored on drive E and haven't got rid of them.

Do these log files stay until a full backup has been completed?  Or should they have dissappeared by now. Normally they only there for a couple of days or so.

How important are these log files?  As the log drive also got full during the maintenance, I had to move some of the logs to another drive. This won't cause all logs to remain on drive will it until it can see the logs I have removed?

For your info, I don't have ticks in either of the options in 'Directory Circular Logging' on the Advanced tab page of my server

Again Tx
Just curious if you were going to reward the points?
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

Accept answer from kevala

Please leave any comments here within the next seven days.


EE Cleanup Volunteer
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.