Exchange Logs inconsistent, causing backups to fail

I would like to suggest to create a new database then move the user over to new DB instead of dismount the original DB

I second that motion - As suriyaehnop suggested, create a new database and move mailboxes to it. In fact, I would create multiple databases and split up the mailboxes between them. I do not see a reason for keeping all the mailboxes in a single database when you can divide them into smaller manageable databases.

With circular logging, once that is enabled and the database is mounted and dismounted, will the logs flush out even if there have been problems with consistency due to some files being deleted?  Can anyone speak to the amount of time to perform this operation?

Splitting the database up is definitely something we'd like to do.  The store is just way too large.

Here's the problem how I see it  and from assumptions based on what you have mentioned - Log files have been deleted to allocate more disk space but it is not known (or is it??) if the log files that were deleted are required to make the database consistent. That means there is a possibility when you come to dismount the database that it may crash when it doesn't find the log files in the "logs required" range - This would mean the database must be repaired and this could take plenty of time (5-10GB an hour for repair then 7-10GB an hour for offline defragmentation).

In my opinion, I would just create new databases and start moving mailboxes as soon as possible. its Exchange 2010 so moves are online and users will not be affected until the move is completed - when they will be prompted to restart Outlook to reconfigure their profile settings.

How far back do the log files currently go? Were they randomly\individually deleted or were some deleted in a group chunk?

Yes, log files were deleted to make more space as the drive was filling up.  I do not know if the log files deleted were required to make the database consistent.  (I do know that the logs were deleted without even dismounting the store.)  However, when attempting to backup the database with Backup Exec it fails, reporting that the logs are not consistent.  Is this indicative that the files deleted were in the "logs required" range?  If I'm going to be faced with a situation where I'll need to do a repair after unmounting, before I can mount again, I'll definitely need to know ahead of time!  
It does seem that the safest thing to do would be to create a new database and start moving mailboxes, but given that there is an issue with space, I don't know that this would even be possible.  
The log files go back to the beginning of Feb. from what I can see so far, and when I asked how they were deleted I was told that the oldest files were selected and "shift deleted".
The Exchange folder moves so slow, when I can report back with more concrete numbers for the number and age of the logs I will!

Ok, here is some additional information:

450GB Mailbox Store
355,016 files in the Exchange Folder
Roughly 400GB in log files dating back to the beginning of Feb.

As long as you don't restart the services, the database should mount with circular logging enabled. Has the server never been rebooted?

Do you have the space to split the database up? I doubt if you do.

The number of logs that you have is too high, unless this is a fresh installation. It could be that you have another problem that is causing high log generation - usually a mobile device.

The Exchange product team have an article on troubleshooting this issue.

http://blogs.technet.com/b/exchange/archive/2013/04/18/troubleshooting-rapid-growth-in-databases-and-transaction-log-files-in-exchange-server-2007-and-2010.aspx

Basically it looks like you have two issues.

1. The logs have been manually deleted.
2. The logs are growing at a rate that is faster than normal.

Simon.

The server was rebooted multiple times a few weeks ago when Windows Updates were done.  This is not a fresh installation.  Definitely don't have space to split the database up.
When enabling circular logging, do you need to dismount the database first, enable it, then remount?  Is that when the logs start to clear?

Yes, the log files are too many and add up to too much space.  They haven't had a good backup in a long time which contributes to the log files not clearing.

Enable, dismount, remount. It doesn't take effect until the database has been through the dismount/remount cycle.

If there are 400gb of logs but they only date back to February, that is too much. If they dated back to the point the server was installed then I could understand it, but 400gb for a 450gb database since February is simply excessive and indication of a problem elsewhere.

Simon.

Ok, good to know.  Given the size of the store and the logs, is this a process that will take a long time?
Also, should I backup after remouting and the logs are cleared out (with circular logging still enabled), or should I disable circular logging, dismount, and remount again before trying to backup?

Yes, definitely will be looking into excessive logging once I have a good backup!

I would normally do the backup AFTER disabling circular logging.
It will take a while to flush the logs - maybe an hour or so with that many.

Simon.

Ok, final thing I'm trying to determine, as it will make a huge difference in the expected downtime...

When I turn on circular logging and unmount the database, will I be able to remount it, or will the database need to be repaired? (If so it could take 50+ hours)

I wish there was a way to know for certain if I'll be able to remount it or not.  Otherwise I'm bringing this uncertainty to the client. (It could take 50+ hours, or it could take up to 3 hours)

You shouldn't need to do anything with the database, dismount and remount.
The log clearing doesn't require any further downtime - so your downtime is actually about 30 seconds.

However I have made that recommendation based on what you have said about the server being rebooted since the log deletions have been taking place - so the database has mounted successfully.

Simon.

Thank you!