顺接上一篇：SQL Server高可用——日志传送（4-2）——部署

本文为本系列最重要的一篇，讲述如何使用日志传送及一些注意事项。从上一篇可以看到，其实配置不难，难是难在一旦出现问题，如何处理。这些是4大高可用的同性。配置都不会很难，只是如何故障排除而已。

监控日志传送：

      在配置好日志传送之后，需要进行监控，监控备份、复制及还原的作业运作情况。这三类作业任何一个没有成功都意味着日志传送失败。

有两种方法可以监控辅助服务器是否与主服务器同步以及两者的时间差：

1、 使用“事务日志传送状态”

2、 执行master.dbo.sp_help_log_shipping_monitor

还可以使用sys.sp_check_log_shipping_monitor_alert来检查是否超过预先设置的阈值。如果超过了，存储过程会发出一个警报。

在监控服务器上执行存储过程：sp_help_log_shipping_monitor，可以看到主服务器和辅助服务器的信息，该结果和使用方法1中的结果基本一致。

故障排查：

日志传送由三部分组成：备份事务日志、复制文件和还原事务日志。所以当出现故障的时候，检查这三部分。

      可以查看SQL代理的日志传送作业历史和windows事件查看器来确认真正的错误信息。

      如复制文件失败，可能是网络不正常，如果还原失败，可能服务器不可用或者数据库处于standby模式时用户正在使用数据库。另外，如果数据库恢复模式改为“简单”，会中断日志传送，因为会截断日志。而不是备份日志。这时需要重新配置事务日志。

      要注意一点，在日志传送之外不应该存在任何其他的事务日志备份操作。因为这样会引起主服务器和辅助服务器的日志链不匹配，从而导致日志传送的中断。

数据库备份计划：

在日志传送中，，对于备份，要考虑以下几点：

l 数据库备份进程和事务日志备份进程不能并发运行。所以一个大型、活跃的数据库，备份可能要花费一段时间，引起日志快速的增长，从而导致辅助服务器和主服务器不同步。因为数据库备份完成之前无法及时地收到事务日志。

l 除日志传送之外不能有其他事务日志备份，因为会断开日志链。

l 截断事务日志将断开日志链，从而导致日志传送无法正常工作。

l 如果把数据库恢复模式转换成“简单”，那么SQLServer会截断事务日志。从而导致日志传送无法正常工作。

删除日志传送：

在删除日志传送数据库之前，先要删除数据库中的日志传送。当删除日志传送后，所有的时间表、作业、历史以及错误信息都会被删除。

使用ssms删除：

只需要把主服务器中下面红框处取消勾选即可。

也可以用下面那里点击【删除】

使用T-SQL删除：

在主服务器上：

Use master;

Sp_delete_log_shipping_primary_secondary @primary_database,@secondary_server,@secondary_database 

这个命令是删除主服务器上的msdb.dbo.log_shipping_primary_secondaries表中辅助服务器的信息。

在辅助服务器上：

Use master;

Sp_delete_log_shipping_secondary_database @secondary_database;

删除辅助服务器上有关服务服务器的信息和作业。

然后再回到主服务器：

Use master;

Sp_delete_log_shipping_primary_database @database

该存储过程删除对应的信息和作业。

日志传送性能：

1、 日志传送备份目录存放到与数据库不同的磁盘驱动器上。并使用备份压缩（2008出现）

2、  需要监控I/O性能计数器以找到所有的瓶颈（如每个物理驱动器的队列平均程度大于2）

3、 在空间时段进行数据库管理活动（如索引碎片整理），因为碎片越多，日志文件越大，备份和还原的时间就越长。

4、为了确保角色切换中数据库能快速恢复，辅助服务器应该与主服务器完全一样的容量。

5、需要把文件复制目录与数据库分离。

6、确保网络不会成为瓶颈。