You may encounter an error message in Exchange Server, saying the queue length is too high. In particular, this error occurs in a Database Availability Group (DAG) setup. There could be many things which can cause this error. In this article, we will cover the common reasons for this error and the possible solutions to resolve it.
Understanding the Queue Length is too High Error
The error “Mailbox Database Copy or Replay Queue is High” indicates that the server hosting the active database copy is struggling to copy the replication logs or to keep up with the transfer to the copy database in the other nodes, which normally receive the logs to be replayed.
How does this Error Affect the Database Availability Group?
In a Database Availability Group (DAG) setup, there are two or more nodes that act as one Exchange Server. In this, one server host the active database and the other nodes record the changes in the database and replay these changes on the copy databases. These changes, coming from the active database, are sent via transaction logs.
If these transaction logs are not sent or there is a high replay queue on the copy databases, then there is a risk of data loss, in case of a failover. In addition, the load on active database and server would impact the user experience and performance, which can damage the server’s integrity and lead to data corruption if the issue is not resolved.
What are the Causes of Queue Length is too High Error?
There are many factors that might cause this issue. Below, we will discuss the most common factors:
- Network Latency: If the network is clogged, the cost of traffic is too high, or the connection is not fast enough for the email usage demand, then there would be connectivity issues between the nodes.
- Disk I/O Issues: If the disks hosting the active database or the passive copy of the database are under high volume and the write or read performance is affected by this, then this can cause delay in the processing of log files.
- High CPU Utilization: CPU usage can spike during such processes. If there is disk performance issue, hardware issue, misconfiguration, or network latency issue, then this will cause the CPU to work harder to keep up with the demand. In addition, third-party applications can also impact the CPU performance of the server.
Solutions to Resolve the Queue Length is too High Error in Exchange Server
There are multiple factors (internal and external) that could impact the transfer and replay of transaction logs. So, first do the following:
- Check with the network team if the bandwidth and traffic between the active database copy on the active server and the passive copy on the other node is working properly. If the error is not appearing frequently, ask the team to monitor the server’s connections to determine where and what is causing this.
- Check with the hardware and infrastructure team if there are any hardware changes. Get a report of the storage performance and hardware state.
- Check with the Exchange Server team to review the change management system. This will help to find out if anything has changed or installed on the server.
If nothing is found from the above investigations, then you need to run the following command to get more information from the queue to determine the source of the problem.
Get-MailboxDatabaseCopyStatus -Identity <dag name\server name>
The above command will give an indication where the issue is. If the issue is in the copy, then you need to look into the source. However, if the problem is in the replay area, you need check the passive copy server.
Now, to troubleshoot the issue, it is suggested to do the following:
- Check the performance of server, i.e., CPU, storage, and memory. You can also create scripts to monitor the performance.
- If the server lacks storage space, then this will impact both the copy and the replay of the transaction logs. Lack of disk space can interrupt the data transfer and replay, and can also cause corruption of data. So, check the hard drive space.
- Check the Event Viewer for any indications to why the issue has occurred.
Once the above are done, it is suggested to resume the replication by using the below command in the Exchange Management Shell (EMS).
Resume-MailboxDatabaseCopy -Identity "<dag name\server name>"
If there are no issues, you can continue to monitor it.
Another solution is to try to reseed the database. You can recreate the copy process and create a new copy of active database on the affected server.
First, you need to suspend the copy by running the below command:
Suspend-MailboxDatabaseCopy -Identity "<dag name\server name" -Confirm:$false
When the command is successfully executed, update the database copy by using the below command:
Update-MailboxDatabaseCopy -Identity "DAGName\ServerName" -Confirm:$false
Now, run the below command to resume the database copy:
Resume-MailboxDatabaseCopy -Identity "DAGName\ServerName" -Confirm:$false
After this, you should monitor the database copy and reply length to ensure that the issue has been resolved.
To Conclude
You can follow the above solutions to resolve the “Queue Length is too high” error in Exchange Server. However, in case of failover due to a disaster, data might be lost or get corrupted. In such a case, the major challenge is recovering the data with no loss. Restoring from backup would take a considerate amount of time and there will be data loss. When such events happen, it’s good to have the right tool in hand to recover data from healthy and corrupted databases in the least possible time and with minimal impact on the business.
With tools, such as Stellar Repair for Exchange, you can easily open corrupted (EDB) databases from any version of Exchange Server, independently from the server. You can then granularly export user mailboxes, user archives, disabled mailboxes, shared mailboxes, public folders, and even deleted and purged items to PST and other file formats. You can also export the EDB data directly to a live Exchange Server database or Exchange Online with automatic mailbox matching. This will drastically reduce the chance of data loss and minimize the recovery time of data.
Was this article helpful?
