ssms 和sql

Database Administrators are vigilant on the backup and restore processes and use the Monitor Transaction log for the same. SQL Server Transaction Log shipping’s prime steps are Transaction Log backup, copy and restore. The answer to solving Disaster Recovery (DR) at the database level can be achieved by SQL Server Transaction Log shipping.

数据库管理员对备份和还原过程保持警惕，并将监视事务日志用于备份和还原过程。 SQL Server事务日志传送的主要步骤是事务日志备份，复制和还原。 在数据库级别解决灾难恢复（DR）的答案可以通过SQL Server事务日志传送来实现。

Log shipping is just an automated method of doing a FULL backup, copying it to the secondary server and restoring it in NO-RECOVERY state, and then making sequential log-backups from the primary server, copying them to the secondary server and restoring them. The log shipping jobs always save the history and status of log shipping operations. The primary server always keeps the history and state of the backup process, whereas the history and state of the copy and restore operations are stored at the secondary server.

日志传送只是执行完整备份，将其复制到辅助服务器并以NO-RECOVERY状态还原然后从主服务器进行顺序日志备份，将其复制到辅助服务器并进行还原的一种自动方法。 日志传送作业始终保存日志传送操作的历史记录和状态。 主服务器始终保留备份过程的历史记录和状态，而复制和还原操作的历史记录和状态存储在辅助服务器上。

In the msdb, SQL Server itself sets up the alert in case of failure of any step or if any step is navigating towards the pre-defined boundary. In the primary and secondary database of the SQL Server instance, the alert configuration will reside in the tables of the msdb database. In the log shipping for primary database, log_shipping_monitor_primary table is there, and for the secondary database table, named log_shipping_monitor_secondary is there.

在msdb中，如果任何步骤失败或任何步骤都朝着预定义的边界导航，则SQL Server本身会设置警报。 在SQL Server实例的主数据库和辅助数据库中，警报配置将驻留在msdb数据库的表中。 在主数据库的日志传送中，存在log_shipping_monitor_primary表，而在辅助数据库表中，存在名为log_shipping_monitor_secondary的表。

Table log_shipping_monitor_primary is used for each individual primary database in the msdb to store log shipping monitor details. With the use of this table, failure alert for the activity at the primary database will be set up. Different columns are used to denote whether the alert is configured or not using a Boolean (true/false) field to monitor transaction log status. For example, a threshold_alert_enabled column is used for monitoring perspective, whereas a backup_threshold column represents the polling time to alert if no backup occurs within the value defined with the column.

表log_shipping_monitor_primary用于msdb中的每个单独的主数据库，以存储日志传送监视器详细信息。 使用此表，将为主要数据库上的活动设置故障警报。 使用不同的列来表示是否使用布尔值（true / false）字段监视事务日志状态来配置警报。 例如， threshold_alert_enabled列用于监视透视图，而backup_threshold列表示在该列定义的值内没有备份发生时发出警报的轮询时间。

For each secondary database in the msdb, log shipping monitor details are being stored by log_shipping_monitor_secondary. This table also provides the facility to store failure alert for the copy and restore activity at the secondary database end. Different meaning is associated with every individual column of this table to monitor transaction log status.

对于msdb中的每个辅助数据库，日志传送监视器详细信息都由log_shipping_monitor_secondary存储。 该表还提供了在辅助数据库端存储复制和还原活动失败警报的功能。 该表的每个单独列都具有不同的含义，以监视事务日志状态。

• restore_threshold column is for an alert if no restore occurs within (n) minutes restore_threshold列用于在（n）分钟内未发生任何还原的警报
• threshold_alert_enabled column is with the Boolean value (true/false) to represent that alert is configured or not threshold_alert_enabled列带有布尔值（true / false），表示是否配置了警报
• last_copied_file column related to the destination location for the copy operation with last copied file name for the subscriber database last_copied_file列，以及订户数据库的最后复制的文件名
• last_copied_date column related to the last copy operation timing for the subscriber database last_copied_date列
• last_copied_date_utc column related to the last copy operation UTC timing for the subscriber database last_copied_date_utc列
• last_restored_file column related to the last restored file name with the folder directory path for the subscriber database last_restored_file列，以及订户数据库的文件夹目录路径
• last_restored_date column related to the last transaction log backup restoration time last_restored_date列
• last_restored_date column related to the last transaction log backup restoration time last_restored_date列
• last_restored_date_utc column related to the last transaction log backup restoration time in the UTC time zone last_restored_date_utc列

为什么我们需要监视事务日志传送？ (Why do we need to monitor Transaction Log Shipping?)

Let’s consider a scenario where log backups and copies are running smoothly without any problems, but one of your secondary fails. We are not aware of this because we are deliberately not monitoring the secondary. Your log shipping restore alerts are based on the secondary server. If you notice that a couple of days later, but by then, it’s too late because the LSN chain is already broken with deleting the (n) days later backup at primary and you have to restart log shipping from scratch.

让我们考虑一种情况，其中日志备份和副本运行平稳，没有任何问题，但是其中一个辅助服务器出现故障。 我们没有意识到这一点，因为我们故意不监视辅助服务器。 您的日志传送还原警报基于辅助服务器。 如果您注意到几天后，但是到那时，为时已晚，因为LSN链已经损坏，删除了（n）天后的主数据库备份，您必须从头开始重新启动日志传送。

The best way to monitor the multiple Log shipping connections in SQL Server is through separate monitoring instance. If the monitoring instance is in Express Edition, then you don’t have to worry about licensing. After setting up log shipping and thereafter in the future, when we want to change the monitoring instance or add one, all you need to know is you need to reconfigure your log shipping. The advantage is that you can use the monitoring instance for multiple log shipping and have the view of all the primary/secondary database status in one location.

监视SQL Server中多个日志传送连接的最佳方法是通过单独的监视实例。 如果监视实例在Express Edition中，则不必担心许可问题。 在设置日志传送之后，以及以后的将来，当我们要更改监视实例或添加一个监视实例时，您所需要知道的就是您需要重新配置日志传送。 好处是您可以将监视实例用于多次日志传送，并且可以在一个位置查看所有主数据库/辅助数据库状态。

The health updates of Transaction log shipping on SQL Server report and third party monitor tools as well can be checked by the user. We also get help to monitor the Transaction Log Shipping process through SQL Server DMV. To check the backup and restore stats of Transaction Log backup, we will have a much better direction over the T-SQL script. In SSMS Basic report with Backup, Copy and Restore status are always available. The users get great help in the form of Transaction Log Shipping Status reports, when users are not much aware of the Backup and Restore related DMVs.

用户还可以检查SQL Server报表和第三方监视工具上的事务日志传送的运行状况更新。 我们还将获得帮助，以通过SQL Server DMV监视事务日志传送过程。 要检查事务日志备份的备份和还原状态，我们将比T-SQL脚本有一个更好的指导。 在带有备份的SSMS Basic报表中，“复制”和“还原”状态始终可用。 当用户不太了解与备份和还原相关的DMV时，用户会以“ 事务日志传送状态”报告的形式获得很大的帮助。

使用SSMS监视事务日志传送 (Monitor Transaction Log shipping with SSMS)

SQL Server instance -> Reports -> Standard Reports -> Transaction Log Shipping Status

SQL Server实例->报告->标准报告->事务日志发送状态

In this example, the Primary database is pub_db, whereas the subscriber database is sub_db in the log shipping. Along with the health details report (Transaction Log Shipping Status) is generated in the SSMS as under. Database Administrator gets every comprehensive detail in this report.

在此示例中，主数据库是pub_db，而订户数据库在日志传送中是sub_db。 如下所示，还在SSMS中生成了运行状况详细信息报告（“事务日志传送状态”）。 数据库管理员可以获取此报告中的所有详细信息。

With the help of a report generated by SSMS, Database administrators can’t keep track of the number of health check-ups for different activities. Therefore, we use third-party tools for database monitoring. Even, T-SQL statement gives the user insight into every information listed below.

在SSMS生成的报告的帮助下，数据库管理员无法跟踪不同活动的健康检查次数。 因此，我们使用第三方工具进行数据库监视。 即使使用T-SQL语句，用户也可以洞悉下面列出的所有信息。

使用T-SQL监视事务日志传送 (Monitor Transaction Log shipping using T-SQL)

Monitor transaction log and Log shipping failures can be regulated for the smooth operation by statistics; backup history helps in analyzing the delays at the publisher’s end, restore history at the subscriber end. We have T-SQL statements as under for the backup and restore with row filter by database name. LSN of the transaction log backup can be handy for analyzing the statistics. The unique LSN, which is generated by the publisher end is associated with each backup set and based on the LSN reference, the user can find the last backup is restored or not at the subscriber end?

监视事务日志和日志传送失败可以通过统计信息进行调整，以实现平稳运行； 备份历史记录有助于在发布者端分析延迟，在订阅者端恢复历史记录。 对于数据库的备份和还原，我们具有T-SQL语句，如下所示： 事务日志备份的LSN可以方便地用于分析统计信息。 由发布者端生成的唯一LSN与每个备份集相关联，并且基于LSN引用，用户可以找到是否在订户端还原了最后一个备份？

Get last Backup of database with LSN (Publisher Side):

使用LSN（发布方）获取数据库的最新备份：

SELECT   d.name, b.*
FROM     master.sys.sysdatabases d
LEFT OUTER JOIN msdb..backupset b ON b.database_name = d.name AND b.type = 'L'
where d.name = ?
ORDER BY backup_finish_date DESC

Get details of last restored transaction log Backup (Subscriber Side):

获取上次还原的事务日志备份（订阅方）的详细信息：

SELECT b.type, b.first_lsn, b.last_lsn, b.checkpoint_lsn, b.database_backup_lsn, a.*
FROM msdb..restorehistory a
INNER JOIN msdb..backupset b ON a.backup_set_id = b.backup_set_id
WHERE a.destination_database_name = ?
ORDER BY restore_date DESC

Here, First LSN is an LSN reference of last-second generated database backup and LAST LSN is an lsn reference of last generated database backup.

在这里， First LSN是最后生成的数据库备份的LSN参考，而LAST LSN是最后生成的数据库备份的lsn参考。

SQL Server系统过程以获取日志传送运行状况的详细信息 (SQL Server system procedures to get details of Log Shipping health)

sp_help_log_shipping_monitor procedure helps to get log shipping health details of the primary and secondary database in the SQL Server instance to monitor Transaction Log.

sp_help_log_shipping_monitor过程有助于获取SQL Server实例中主数据库和辅助数据库的日志传送运行状况详细信息，以监视事务日志。

EXEC sp_help_log_shipping_monitor

sp_help_log_shipping_monitor_primary procedure helps to get log shipping health details of the particular primary database to monitor Transaction Log. Here, the primary database server and primary database name will be the input parameter.

sp_help_log_shipping_monitor_primary过程有助于获取特定主数据库的日志传送运行状况详细信息，以监视事务日志。 在此，主数据库服务器和主数据库名称将作为输入参数。

EXEC sp_help_log_shipping_monitor_primary @primary_server, @primary_database

sp_help_log_shipping_monitor_secondary procedure helps to get log shipping health details of a particular secondary database to monitor Transaction Log. Here, the secondary database server and secondary database name will be the input parameter.

sp_help_log_shipping_monitor_secondary过程有助于获取特定辅助数据库的日志传送运行状况详细信息，以监视事务日志。 在此，辅助数据库服务器和辅助数据库名称将作为输入参数。

EXEC sp_help_log_shipping_monitor_secondary @secondary_server, @secondary_database

sp_help_log_shipping_primary_database procedure helps to get log shipping configuration and health details of the primary database by the primary database name and primary database reference from the msdb.dbo.log_shipping_primary_databases table.

sp_help_log_shipping_primary_database过程有助于通过msdb.dbo.log_shipping_primary_databases表中的主数据库名称和主数据库引用来获取主数据库的日志传送配置和运行状况详细信息。

EXEC sp_help_log_shipping_primary_database @database, @primary_id

sp_help_log_shipping_secondary_database to get log shipping configuration and health details of the secondary database by the secondary database name and secondary database reference from the msdb.dbo.log_shipping_secondary table.

sp_help_log_shipping_secondary_database通过msdb.dbo.log_shipping_secondary表中的辅助数据库名称和辅助数据库引用获取辅助数据库的日志传送配置和运行状况详细信息。

EXEC sp_help_log_shipping_secondary_database @secondary_database, @secondary_id

sp_help_log_shipping_primary_secondary to get log shipping configuration details of the primary database and secondary database with the log shipping health details of the primary database by the primary database name as an input parameter. Data will be fetched from the msdb.dbo.log_shipping_primary_databases & msdb.dbo.log_shipping_primary_secondaries table.

sp_help_log_shipping_primary_secondary使用主数据库名称作为输入参数来获取主数据库和辅助数据库的日志传送配置详细信息，以及主数据库的日志传送运行状况详细信息。 数据将从msdb.dbo.log_shipping_primary_databases和msdb.dbo.log_shipping_primary_secondaries表中获取。

EXEC sp_help_log_shipping_primary_secondary @primary_database

sp_help_log_shipping_secondary_database to get log shipping configuration details of the secondary database and secondary database with the log shipping health details of the secondary database by the secondary database name and secondary database reference as an input parameter. Data will be fetched from the msdb.dbo.log_shipping_secondary & msdb.dbo.log_shipping_secondary_databases table.

使用sp_help_log_shipping_secondary_database获取辅助数据库和辅助数据库的日志传送配置详细信息，并以辅助数据库名称和辅助数据库引用作为输入参数，获取辅助数据库的日志传送健康详细信息。 数据将从msdb.dbo.log_shipping_secondary和msdb.dbo.log_shipping_secondary_databases表中获取。

EXEC sp_help_log_shipping_secondary_database @secondary_database, @secondary_id

SQL Server日志传送错误列表 (SQL Server Log shipping Error list)

The T-SQL query stated below is useful for tracking Log shipping errors. For both publisher end and subscriber end, log_shipping_monitor_error_detail table will be available with error details. This table can help immensely with error troubleshooting. If log shipping is broken with any one of the job steps, fail.

下面所述的T-SQL查询对于跟踪日志传送错误很有用。 对于发布者端和订阅者端， log_shipping_monitor_error_detail表将可用，并包含错误详细信息。 该表可以极大地帮助您进行错误排除。 如果日志传送因任何一个作业步骤而中断，则失败。

SELECT CASE agent_type WHEN 1 THEN 'Backup' WHEN 2 THEN 'Copy' WHEN 3 THEN 'Restore' END as agent_type, *
from msdb..log_shipping_monitor_error_detail

Log shipping error recovery is a bit difficult for what we see here. A user needs to apprehend and monitor many things at the publisher and subscriber end. Even for the user, transaction log database size is also important because, for the Disaster Recovery solution, Log shipping is used. If the transaction is too long and taking more time to get copied at the destination side (subscriber end), then there may be a delay in the restoration, and if any restore activity does not happen in (n) minutes, then it should raise an alert to the user.

对于我们在此处看到的内容，日志传送错误恢复有些困难。 用户需要在发布者和订阅者端理解和监视许多事情。 即使对于用户来说，事务日志数据库的大小也很重要，因为对于灾难恢复解决方案，使用了日志传送。 如果事务太长并且需要更多时间才能在目标端（订户端）进行复制，则还原可能会有所延迟，并且如果在（n）分钟内未发生任何还原活动，则应该提高给用户的警报。

There can be many more challenges for the log shipping configuration, such as Network issues, Folder access permission issues if any changes occur in the directory permission, Shared folder directory changes, SQL Server agent service issue (because all things are done by SQL jobs), etc… You don’t have to take any additional log backups, once you configure a database for log shipping. Backup, copy, and restore job automatically performs the event; log shipping will start failing if the LOG CHAIN is disturbed.

日志传送配置可能面临更多挑战，例如网络问题，如果目录权限发生任何更改都将导致文件夹访问权限问题，共享文件夹目录更改，SQL Server代理服务问题（因为所有事情都由SQL作业完成）等等。配置数据库进行日志传送后，您无需进行任何其他日志备份。 备份，复制和还原作业将自动执行该事件； 如果日志链受到干扰，日志传送将开始失败。

结论 (Conclusion)

As mentioned earlier, monitoring the database servers is one of the important tasks for DBAs, and we explored the transaction log shipping feature in this article and how we can monitor the Transaction Log process using T-SQL.

如前所述，监视数据库服务器是DBA的重要任务之一，我们在本文中探讨了事务日志传送功能以及如何使用T-SQL监视事务日志过程。

翻译自: https://www.sqlshack.com/monitor-transaction-log-shipping-using-t-sql-and-ssms/

ssms 和sql