Quantcast
Channel: Exchange Server 2013 - General Discussion forum
Viewing all articles
Browse latest Browse all 4521

exchange database in dirty shutdown state questions

$
0
0

Two exchange 2013 servers in DAG group.

when I started the backup on my exchange 2013 server yesterday (using backup exec 2013) I was checking the event viewer and saw a message that database was in dirty shutdown state:

Instance 1: Database headers have been successfully validated. All databases are in a dirty shutdown state. To bring these databases to a clean shutdown state, log generations 8605532 (0x00834f5c) to 8605635 (0x00834fc3) will be required.

But everything looked fine, and I am aware that backup exec will cause that message to falsely popup at times.

when I checked my daily report generate by PS this morning, it showed errors on database availability, and my secondary exchange server (exchangeb) was mounted instead of primary exchange (exchangep).

Message was:

There were database availability check failures for database 'exchangedb' that may be lowering its availability. Availability Count: 1. Expected Availability Count: 2. Detailed error(s): exchangep: Database copy 'exchangedb' on server 'exchangep' has a total (copy plus replay) queue length of 1617 logs, which is higher than the maximum allowed queue length of 400. If you need to activate this database copy, you can use the Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to forcibly activate the database copy. If the database does not automatically mount after running Move-ActiveMailboxDatabase successfully, use the Mount-Database cmdlet to mount the database. 

Queue was in the thousands when I looked at it, however, about 30 minutes later, the queue length was down to 0, and I was able to make the primary exchange server mounted again.

two questions:

1)   would replaying of logs in this way resolve the dirty shutdown state issue?

2)I do have this issue where exchangeb gets mounted in the middle of the night, always thought it was latency issue, as the two exchange severs are at 2 different sites connected via IPSEC tunnel, so it is possible that the dirty shutdown error occurring before this happens was coincidence?



Viewing all articles
Browse latest Browse all 4521

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>