Exchange Database Maintenance is not running as scheduled... 1

[bjpjcpcjpjjp]

Hello everyone,

My exchange 2003 database maintenance is not running as scheduled. I noticed that my transaction logs were not being cleaned up and i started running out of disk space. When I checked the database tab on the information store properties it said the last full backup ran over a month ago. I modified the maintenance schedule to 2am-6am and then restarted the server. Maintenance is still not running. Can someone give me a tip on how to get the maintenance going again.

Thank you in advance!

 

[58sniper]

The daily maintenance has nothing to do with truncating the logs. Running a full backup with an Exchange aware backup application truncates the logs upon successful completion.

Pat Richard MVP

 

[bjpjcpcjpjjp]

Pat,

Thanks for your reply...maybe there is something else going on then...because the MDBDATA folder is growing rapidly and i am getting low on disk space.

Is there a way to verify that the daily DB maintenance is running for peace of mind. If I understand it right...the maintenance should include an online defrag of the DB. Which i don't think is being done.

As for the transaction logs...is there a reason that these are suddenly growing at a rapid pace? I looked at turning on circular logging for now so that I don't run out of space but I know that this is not best practice for protecting data...

any advice would be great!

 

[58sniper]

What do you think the daily maintenance is going to do?

If you're not running a backup, the logs will never get truncated. Hence, you run out of room. That's entirely by design.

Online defrag doesn't shrink the file size.

The only way to recover that space is a backup. You haven't had one in over a month, as evidenced by the store properties. It should be running daily.

Pat Richard MVP

 

[bjpjcpcjpjjp]

ok...let me ask you this then...when you say backup, are you referring to a backup task on the exchange server or a IS Backup? I have daily incremental backups and weekly full backups running via Backup Exec which have been completing successfully every day. But when I look at the database tab in the Information Store properties it says that the last full backup was over a month ago...which I assumed was being handled by the database maintenance which is why i have been asking about the maintenance. Is there somewhere else that I should look to make sure that the "Backup" is successful and thus recovering the space as you said a backup would do. Thanks for your help!

 

[Davetoo]

Did you purchase/install the Exchange Agent for Backup Exec? If not, then you have to do that in order to properly backup Exchange and flush the logs.

Stop referring to Database Maintenance, it has nothing to do with your current problem of running out of drive space due to the logs not being flushed.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

There are no more PDC's! There are DC's with FSMO roles!

 

[bjpjcpcjpjjp]

yes i have the agent installed and it has been working great...this problem just started a few weeks ago.

So aside from the backup that has not been running according to the exchange server...My exchange database is very large...we recently cleaned out old mailboxes and the size did not change...is it best to run a defrag to recover the white space in the database?

 

[bjpjcpcjpjjp]

Sorry for mentioning maintenance alot in this forum but it actually has alot to do with our current database size...there are a few differant peices to the puzzle so I am trying to look at the big picture and not get stuck on minor details...



--People who are insecure feed off of thinking they know more then they really do. It's not impressive.

 

[58sniper]

Daily maintenance has NOTHING to do with your database SIZE. It has NOTHING to do with transaction log truncation.

NOTHING NOTHING NOTHING.

If you say it does, you're going to get at least three senior Exchange guys here telling to you go read a book.

yes i have the agent installed and it has been working great.

No, it has not. If it were, you wouldn't have this problem. If it were working correctly, the store properties wouldn't say it's been a month. And you wouldn't have all of these transaction logs hanging around.

Pat Richard MVP

 

[Davetoo]

The minor detail that you've enlarged to a big detail is the daily maintenance. Do you get the point that it has nothing to do with this? Good.

Check your Backup Exec server and fix the problems that are apparently occuring there because if you have Exchange logs going back a month then you're not getting good backups on a daily basis.

If you were, those logs wouldn't be there.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

There are no more PDC's! There are DC's with FSMO roles!

 

[58sniper]

Yep - what Davetoo said!

When an Exchange aware backup application successfully completes a full backup, the streaming API is told to truncate the logs, and the store properties are updated to show the current date. Without that happening, the logs aren't truncated, and the store properties show the previous backup date. Eventually, the drive fills up.

So - you have store properties showing it's been a month. You correctly have a months worth of logs. It's a backup problem. Pure and simple.

Pat Richard MVP

 

[bjpjcpcjpjjp]

ok thanks...so I just ran a manual full backup of the database and it is now showing correctly in the store properties. Is there a way to shrink the actual size of the database since we recently removed several old mailboxes (about 10GB)?

 

[xmsre]

1. Do you have limits in place?

2. What is your expected growth rate?

3. Do you have any way to be absolutely certain the space will not be reused?


If so, then

1. How did you remove the mailboxes?

2. Did you wait 30 days?

3. Did you purge them?


Deleted mailboxes are not governed by the deleted items retention period. They are retained for 30 days by default. You can, however, run the cleanup agent and then purge them. One they are really gone, it makes no sense to try and shrink the size of the store if it will simply grow again. If you have limits in place, and you're absolutely certain your store will no grow (you won't be adding any user for the next three years or so), then create a new store, move all the mailboxes to it, then dismount and delete the old store.

 

[bjpjcpcjpjjp]

I deleted the mailboxes and ran the cleanup agent...but I am sure that it will continue to grow. i will just leave it as is and as we create new mailboxes I assume it will use the white space in the mailstore. Thanks for your reply.

 

[theravager]

Seems to be a lot of confusion in this thread.

Daily maintenance will cleanup deleted mails and mailboxes, if your maintenance plan goes to hell due to databases being to large or the agent dosen't have enough runtime them databases will grow rapidly. It does not reduce the physical size of files but allows the space recovered to be reused, otherwise known as whitespace. Probibly of note here you have the option to prevent cleanup of this space until a backup is down.

Exchange backups incrementals or fulls that are compelted successfully will remove the old log files.


In the logs if maintenance is complete succesfully you will get a event stating how much space is recovered per store so to get the real size of your databases subtract that.

If you want to physically shrink the database stores you can do a offline defrag, while its useful doing this occasionally to make fragmentation a little better the only real reason is if you recently migrated a lot of mailboxes to another store for space managment purposes.

 

[xmsre]

Online maintenance will clean up deleted items at the expiration of the deleted items retention period. Deleted mailboxes are retained 30 days and then cleaned up. This is independent of your DIR setting. If you want them cleaned up faster, run the clenup agent than after it completes purge the deleted mailbox. The space will berclaimed on the next online maintenance cycle after the purge. Whitespace within a database is reported in event id 1221. You can reclaim whitespace in two ways:

1. Create a new store, move all the maiboxes to it, and then dismount and delete the old store.

or

2. Do an offline defrag.

An offline defrag requires downtime (lots of it) and has no advantage over movemailbox. The only time you would even consider an offline defrag is if you can't create another store and you know you have lots of whitespace that will never be reused. Nedlessly performing offline defrags actually decreases performance (as well as invalidating all your backups)

Now, don't use that D word again!