Exchange DAG Health Details Test

When creating a mailbox data copy,  you can specify the activation preference number, which is used as part of Active Manager's best copy selection process. It's also used to redistribute active mailbox databases throughout the DAG when using the RedistributeActiveDatabases.ps1 script. The value for the activation preference is a number equal to or greater than one, where one is at the top of the preference order. The position number cannot be larger than the number of mailbox database copies.

The values that this measure can report, their description, and their corresponding numeric values are detailed in the table below:

Note:

By default, the test reports the Measure Values listed in the table above to indicate the current state of a mailbox database copy.

In the graph of this measure however, the same is represented using the numeric equivalents only.

The copy queue length signifies the number of logs still to be copied to the passive mailbox database copy.

Ideally, a passive mailbox database copy should not have a copy queue length thatis more than 10 logs. A consistent rise in the value of this measure therefore could indicate slowness in copying logs to the passive copy.  

A steady increase in the value of this measure could indicate a replication bottleneck, as it implies that log files are not getting replayed into the database copy rapidly. This could be owing to a high Replay lag time setting.

Replay lag time is a property of a mailbox database copy that specifies the amount of time, in minutes, to delay log replay for the database copy. The replay lag timer starts when a log file has been replicated to the passive copy and has successfully passed inspection. By delaying the replay of logs to the database copy, you have the capability to recover the database to a specific point in time in the past. A mailbox database copy configured with a replay lag time greater than 0 is referred to as a lagged mailbox database copy, or simply, a lagged copy.

To reduce the length of the replay queue, you may want to consider reducing the Replay lag time specification of the database copy.

A steady increase in the value of this measure could indicate that log files that have been replayed into the database copy and are not truncated quickly enough. This could be because of a high Truncation lag time setting for the database copy.

Truncation lag time is a property of a mailbox database copy that specifies the amount of time, in minutes, to delay log deletion for the database copy after the log file has been replayed into the database copy. The truncation lag timer starts when a log file has been replicated to the passive copy, successfully passed inspection, and has been successfully replayed into the copy of the database. By delaying the truncation of log files from the database copy, you have the capability to recover from failures that affect the log files for the active copy of the database.

You may want to reduce this setting to minimize the copy queue length.

The values that this measure can take and their corresponding numeric values have been discussed in the table below:

Note:

By default, the test reports the Measure Values listed in the table above to indicate whether/not replay was lagged for the database copy. In the graph of this measure however, the same is represented using the numeric equivalents only.

The values that this measure can take and their corresponding numeric values have been discussed in the table below:

Note:

By default, the test reports the Measure Values listed in the table above to indicate whether/not truncation was lagged for the database copy. In the graph of this measure however, the same is represented using the numeric equivalents only.