eG Monitoring
 

Measures reported by MsSqlLgShipStTest

SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually.

The following are the benefits of the SQL Server Log shipping:

  • Provides a disaster-recovery solution for a single primary database and one or more secondary databases, each on a separate instance of SQL Server.

  • Supports limited read-only access to secondary databases (during the interval between restore jobs).

  • Allows a user-specified delay between when the primary server backs up the log of the primary database and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly, a delay can let you retrieve still unchanged data from a secondary database before the change is reflected there.

Log shipping involves applying the transaction log from every insertion, update, or deletion made on the primary database onto the secondary database. Log shipping can be used in conjunction with replication, with the following behavior:

  • Replication does not continue after a log shipping failover. If a failover occurs, replication agents do not connect to the secondary, so transactions are not replicated to Subscribers. If a failback to the primary occurs, replication resumes. All transactions that log shipping copies from the secondary back to the primary are replicated to Subscribers.

  • If the primary is permanently lost, the secondary can be renamed so that replication can continue.

When log shipping feature is enabled on the target database, the transaction logs are applied to the secondary database quickly without loss of data from committed transactions. If the secondary database is not reachable or is not able to accept the transaction logs from the primary database, data may not be up to-date in the secondary database when a primary database goes down even for a short duration. This may result in data loss and eventually unhappy users! To avoid such unpleastaries, it is necessary to monitor the time duration that elapsed while applying the transaction logs from the primary to the secondary database. The SQL Log Shipping Status test helps administrators in this regard!

This test auto-discovers the secondary databases and for each secondary database, reports the lag time noticed while the data is transferred from the target database. By comparing the value of this test across the secondary databases, administrators can figure out the secondary database on which the transaction logs took too long to be applied. This way, administrators can figure out the secondary database that is currently not up to-date.

Note:

This test is applicable only to Microsoft SQL Server 2005 (and above).

Outputs of the test: One set of results for each Microsoft SQL server monitored

Descriptor: Microsoft SQL Server

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Tlog_lag_duration Indicates the time lag that was noticed between the target database and this secondary database. Minutes

A sudden / gradual increase in the value indicates a longer than usual transaction gap between the primary and secondary database. This may lead to the data loss in the secondary database if the primary primary database is down.

The detailed diagnosis lists the Last restored time, Last restored file and the current server time

By comparing the value of this measure across the secondary databases, administrators can figure out the secondary database on which the transaction logs took too long to be applied. This way, administrators can figure out the secondary database that is currently not up to-date.