The Database Availability Group (DAG) is probably the best Exchange 2010 feature from both an impact and technology perspective. Microsoft took a really good decision by not limiting the DAG to enterprise editions of Exchange, even if you can only mount five databases on a server (counting both active and passive) with this edition and still require Windows 2008 Enterprise (because of the dependency on Windows Failover Clustering). The reason why it’s such a good decision is that it allows DAGs to be deployed to protect Exchange 2010 deployments from the very smallest to the very largest, which can’t be a bad thing.
Of course, another good thing about the DAG is that it hides much of the complexity involved behind the Exchange Management Console (EMC). Sure, you can plunge into mano-a-mano combat with the finer points of the DAG through the command line but there’s no good reason to do this unless you really must tune something that cannot be reached through EMC, such as sorting out networks automatically generated when a DAG is formed – the rule is that you can only have one MAPI network while several replication networks are supported.
MAPI networks are used to connect DAG member servers to network services such as Active Directory and for connections between a mailbox server and the CAS. These networks are registered in DNS, use the default gateway, and are enabled for Microsoft networks file and print sharing. Replication networks are used to transfer transaction logs between servers and are not registered in DNS, do not use the default gateway, and disable Microsoft networks. A server can survive with just the MAPI network (single NIC) as Exchange will route all traffic across this network, but if the MAPI network fails it forces a server failover within the DAG.
The Add-DatabaseAvailabilityGroupServer cmdlet (run manually or by the EMC Create New DAG wizard) attempts to make things easy for administrators by scanning for network cards known to the cluster service when a server joins a DAG (note that if you add a NIC to a server after it’s in a DAG or change the subnets used by the DAG, you can force Exchange to discover the NIC by running the Set-DatabaseAvailabilityGroup cmdlet with the -DiscoverNetworks parameter. For example:
Set-DatabaseAvailabilityGroup -Identity DAG1 -DiscoverNetworks
During enumeration, each NIC is assigned its own DAG network entry. If a server has multiple NICs, it’s possible that the enumeration and creation of DAG networks will end up with some entries that have a single endpoint and that just won’t work. The DAG will continue to function because Exchange contains fall-back logic that will instruct the DAG to use the only network that’s registered in DNS, meaning that all traffic will be routed across the MAPI network. However, it’s not good to persist with this situation and an administrator will have to sort it out by collapsing the networks so that you end up with the various subnets allocated correctly to the right DAG networks and the superfluous networks removed. This kind of complex one-off work is best done with EMS as you couldn’t expect the EMC UI to cater for every possible situation that might arise. See MSDN for more information about the creation of DAG networks.
In any case, this post is not about the finer points of DAG networks. In fact, I just wanted to share an unusual hiccup that EMC displayed the other day.
EMC displays a huge copy queue length for a database
Even a hugely active database is hardly likely to create so many transaction logs that it would accumulate such a massive copy queue length (9,223,372,038,654,775 is the figure shown in the screen shot). Of course, this is the result of a transient glitch that EMC took seriously – a quick refresh exposed the true state of affairs and the copy queue length came up with the expected zero value. But isn’t it nice to know that Exchange 2010 is designed to deal with such a long queue – or at least that EMC is ready to display the good news about such a queue to an administrator!
Where would we be without a glitch to make the day go by faster?
– Tony
Thoughtsofanidlemind's Blog 
What made it to show exactly this many queue…would you please like to share your view further as above…?
Just a bug, I think. Sometimes EMC displays the weirdest information.
It’s not EMC. If you ran Get-MailboxDatabaseCopyStatus at that exact same time, you’d have seen the exact same copy queue. The value is placed there when network communication between the active and passive copies has gone awry long enough during an incremental reseed (or page patching) that the passive copy doesn’t trust itself to be an active copy until things get fixed.
Correct. The point is that EMC always shows a static picture of what’s happening with copy queue lengths (as does Get-MailboxDatabaseCopyStatus). The only way of knowing exactly what’s happening with copy queue lengths at a precise level is to check the performance monitor counters, which are refreshed (every second, I think). EMC or EAC don’t refresh.
just sync the correct time of local clock same as other DAG members shall show the correct information for queue length
Get-MailboxDatabaseCopyStatus –id “database name”
no its a feature called Database Protection Mode, which prevents to mount the passive copy automatically where active copy is already working fine.