日志传送简介
From : http://mssqlmct.blog.51cto.com/9951484/1641829
11.2 日志传送简介
11.2.1 原理概述
日志传送由一个主数据库和一个（或多个）辅助数据库组成。
主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定期备份。然后备份文件被辅助数据库所属的实例复制到它的本地文件夹，最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。
当主数据库发生故障时，可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库。
11.2.2 备用模式
恢复过程可以使用两个选项：使用“无恢复模式”（WITH NORECOVERY）选项将使数据库在恢复后处于“正在还原”状态，不可以访问；使用“备用模式”（WITH STANDBY）选项将使数据库在恢复后处于“正在还原，备用”状态，可以提供只读访问。
提示：
如果辅助数据库使用了“备用模式”，并且客户端提需要访问这个辅助数据库，那么需要为部署在这台辅助服务器上的 SQL Server 购买许可证。
11.2.3 逻辑流程
简单地说，日志传送是通过在 SQL Server 代理中创建3个作业实现的。
（1）在主服务器实例，为主数据库创建一个事务日志备份计划，定期备份事务日志到共享文件夹。
（2）在辅助服务器实例，为辅助数据库创建一个文件复制计划，定期将共享文件夹中的事务日志备份文件复制到本地。
（3）在辅助服务器实例，为辅助数据库创建一个事务日志还原计划，定期从本地的事务日志备份文件还原数据库。
（4）可选的另一个服务器实例（称为“监视服务器”）记录了备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。
11.2.4 日志传送的优势
可以广泛地部署。通过在多个辅助服务器上配置多个辅助数据库，可以建立多个“冷备用”数据库。
辅助数据库可以提供只读访问，作为报表等应用程序的数据源，从而将报表查询等只读访问的负载分摊到一个或多个辅助服务器。
11.2.5 日志传送的局限
主数据库和辅助数据库分别属于不同的实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主数据库的状态，因此日志传送技术不支持自动的故障转移。
主数据库与辅助数据库之间的异步数据更新被拆分成3个独立的步骤来实现，因此会有较大的延时。
实验一：SQL server 2005高可用性之----日志传送
如转载，请注明出处：http://blog.csdn.net/robinson_0612/archive/2009/10/31/4751070.aspx
SQL server 2005高可用性之日志传送是在SQL server 2000 日志传送基础之上的延续，两者其本质上并没有太大的差异。日志传送能够同步位于不同服务器或同一服务器不同实例之间的数据库，通过将主服务器上备份出来的一系列日志自动传送到辅助服务器上并进行恢复。当主服务器宕机的时候，日志传送功能并不能实现从主服务器到辅助服务器的自动故障转移功能，需要手动将辅助服务器切换到联机状态，使得辅助服务器上数据库来提供服务，从而实现数据库的高可用性。
一、实验目的：配置SQL server 2005日志传送、监控日志传送状态及故障转移。
二、日志传送使用的场景
1. 可用于支持Reporting server，通过指定standby模式来实现相应的查询功能，并保持与主体数据库同步。
2. 可用于初始化镜像数据库，使得镜像中主体数据库与镜像中的镜像数据库在时间上，时点延迟上更接近，加快镜像会话的实现。
3. 实现数据库的版本更新或迁移到新平台，有利于最小化应用程序的宕机时间。
4. 实现多个将多个主数据库的数据备份到一个辅助数据库，节省资源和开支。
三、实现日志传送的组成部分
1. Primary server(Primary database): 主服务器中用于实现日志传送的主体数据库
2. Secondary server(Secondary database): 辅助服务器中恢复日志文件的数据库，可以为多个主服务器提供日志备份。
3. Monitor Server: 可选的监视服务器，用于记录日志传送过程中出现的异常情况，失败时给出警告，存储在msdb数据库中。
四、实现日志传送所需的环境
1. 至少两台SQL server 2005服务器，或同一服务器的两个实例。
2. SQL server 2005的版本要求为Standard, Workgroup, Enterprise, or Developer Edition之一。
3. 主体服务器的主体数据库使用完全恢复模式(FULL)或大容量日志恢复模式(Bulk-Logged)。
4. 主体服务器中SQL server Agent服务启动帐户拥有对存放备份日志文件目录读写的权限，辅助服务器中SQL server Agent启动帐户一是要有对主服务器上存放备份日志文件目录读的权限，用于从主服务器复制日志文件，二是要拥有辅助服务器上存放用于恢复日志文件目录读写的权限。用于将复制过来的日志文件写入恢复日志文件目录。不建议将备份出来的日志文件存放到主服务器，可以考虑放到文件服务器上，减少主服务器的I/O。
5. 若主服务器备份出的日志文件要存放到其他服务器或文件服务器，请使用Windows域用户帐户启动主服务器的SQL server Agent服务。
6. 启动主体服务器和辅助服务器的SQL server Agent服务，若有监视服务器，也应当启动监视服务器的SQL server Agent服务。
五、实现日志传送所需要用到的几个作业
1. 备份作业(backup job): 运行在主服务器上，为每个实现日志传送数据库创建一个备份作业，备份主体数据库日志，删除旧的日志文件或历史记录信息，并将其记录到主服务器和监视服务器上。
2. 复制作业(copy job): 运行在辅助服务器上，将备份文件从主服务器复制到辅助服务器，并记录信息到辅助服务器和监视服务器上。
3. 还原作业(restore job): 运行在辅助服务器上，为每个日志传送配置创建一个还原作业，恢复从主体数据库传送过来的日志，删除旧的日志文件或历史记录信息，并将其记录到辅助服务器和监视服务器上。
4. 警报作业(alter job): 运行于监视服务器上，警报作业由使用监视器服务器实例的所有日志传送配置中的主数据库和辅助数据库所共享。
六、本次实验的环境
1. windows xp pro (英文版) + sp2
2. SQL server 2005 Developer + sp3
3. 同一主机的三个实例： ROBINSON ， ROBINSON/MIRROR，ROBINSON/WITNESS
4. 用于日志传送的数据库为Ecustom_qah
5. 因在同一服务器上实现日志传送，本实验没有增加SQL server Agent 服务帐户，用的是Local system帐户启动SQL server Agent 服务。
七、具体实验步骤如下
1. 设定共享目录，在主服务器上设定Backuplog并共享，使主服务器上的SQL server Agent 服务帐户拥有读写的权限，使辅助服务器上的SQL server Agent 服务帐户拥有读的权限。Backuplog用于存放主服务器备份出来的日志文件。
2. 辅助服务器上设定Resotrelog，使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Resotrelog用于存放从主服务器复制过来的日志文件，用于恢复。
3. 在辅助服务器上设定一个初始化数据库的文件夹Databckup并共享，使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Databckup用于存放Ecustom_qah的mdf文件和ldf文件。
4. 测试以上的设置可以正常使用，因本实验在同一台服务器上执行，故仅仅是在D：盘下设定了Backuplog、Resotrelog、Databackup并设定相应权限。
5. 启动相关服务。在SQL Server Configuration Manager中查看各个实例的MSSQLSERVE 和SQL server Agent是否启动，如下图：
6. 查看用于日志传送的主数据是否处于FULL或Bulk-Logged恢复模式，如不是，请修改其为FULL或Bulk-Logged恢复模式。
也可以使用如下语句来修改恢复模式： Alter database Ecustom_qah set recovery FULL。
7. 启动SSMS并连接到主服务器，展开databases文件夹，右单击Ecustom_qah，选择Properties,选择Transaction Log Shipping，选择Enable This As A Primary Database In A Log Shipping Configuration后单击Backup Settings设置。
8. 输入备份文件夹网络路径，当备份文件夹位于主服务器上时，输入主服务器上的文件夹。
9. 设定超6分钟后删除日志文件，并设定3分钟没有备份则提示报警。
10.单击Schedule，设定日志的备份频率，为每2分钟备份一次日志文件。
11. 单击 Add 按钮添加Secondary server.
12. 单击connect，连接Secondary server，输入帐户和密码，选择secondary database为Ecustom_qah，在Initialize Secondary Database中，因我们没有对初始数据库进行备份，故在此处选择generate a full backup，并设定其Restore options，设定数据文件和日志文件的位置在辅助服务器上的所在的文件夹 。
13. 如果在设定日志传送之前已经备份了数据库或已对辅助数据库初始化可以选择restore an existing backup或the secondary database is initialized.
14. 在copy files选项卡设定复制文件的目的文件夹，设定删除已复制的文件的时间间隔为6分钟，复制频率为每2分钟复制一次日志文件。
15. 在Restore Transaction Log选项卡中设定No recovery模式，并设定延迟为1分钟，恢复每2分钟发生一次，超过4分钟日志没有恢复则报警。
16. 设定完Restore Transaction Log后，回到log shipping 主界面，勾选use a monitor server instance，选择settings选择ROBINSON/WITNESS并设定15分钟后删除历史记录。
17. 按以上设定完毕后，点击ok，系统开始按所设定配置日志传送，如果有错误发生，系统会给出警告，按警告提示更正相关错误。
18. 如设定无误后，连接到MIRROR实例和WITNESS实例，则在各个实例之间的jobs会出现相关作业，在MIRROR实例中出现数据库Ecustom_qah(Restoring)如下图所示：
19. 打开设定的文件夹检查主服务器的备份情况和辅助服务器上复制过来的日志文件。
至此SQL server 2005日志传送配置完毕。
八、监控日志的传送
1. 通过存储过程查看日志传送的情况
如在主服务器上执行：sp_help_log_shipping_primary_database 'Ecustom_qah'
在辅助服务器上执行：sp_help_log_shipping_secondary_database 'Ecustom_qah'
也可以在监视服务器上执行脚本来跟踪日志的传送情况，如下图：
2. 通过摘要中报表模块下的事物日志传送状态来动态查看和跟踪事务日志的情况。
因本机所使用SQL server 2005的版本为Developer + sp3 ，所以无报表模块功能，什么原因待考证。笔者曾在SQL server标准版(中文)中看到有报表且有事物日志传送状态功能但安装了sp3中文补丁后则不再有此功能。如有知其原因者可以给我留言。
3. 通过警报作业将故障通知道相关人员。
在监视服务器上我们可以看到有两个警报作业，即Alters下，我们可以看到Log shipping Primary Server Alert和Log shipping Secondary Server Alert。.默认的情况，如果监视到错误，并不会做任何通知，我们可以通过新建操作员(Operators)来接受相关报警信息。同样，我们也可以在主服务器和辅助服务器上设定操作员来接受相关报警信息，可以通过消息，邮件等形式，前提是需要配置数据库邮件或启动操作系统中的Messenger信使服务等，如本试验中设定的启动了Messenge服务后，则得到如下图的提示：
4. 对于常见的SQL server故障，我们可以通过查看操作系统的事件查看器或SQL server日志来发现问题。
九、事务日志模式
在设置辅助数据库时，对于恢复事务日志Restore Transaction Log选项卡，我们设定了为No recovery mode，还有一个可供选择的则为Standby mode。在事物日志的传送过程中，恢复事务日志Restore Transaction Log与我们普通的恢复不同，一般情况下的恢复是回滚所有未提交的事务，前滚所有已提交但未写入磁盘的事务。事务日志中，如果一个事务回滚，所有改变的数据将会被丢失，因为在这个时候，你并不知道下一事物究竟是回滚还是提交。故在事务日志传送中提供了No recovery mode和Standby mode，两者的介绍如下：
1. 无恢复模式(No recovery mode):既不前滚也不回滚未提交的事务，数据不可读。
2. 备用模式(Standby mode):在恢复日志期间回滚所有未提交的事务，并且将所有未提交的事务保存为一个单独的Transaction Undo File(TUF)文件，恢复过程通过该文件来维护事务的完整性，当恢复下一个事物的时候则恢复所有已提交的事务。Standby mode中的复选框勾选则当日志恢复的时候，断开所有用户的连接，如果有一个用户没有断开，则还原无法进行。
十、演示Standby mode查看日志传送及故障转移
1. 将No recovery mode切换到Standby mode 。此操作在主服务器上打开Ecustom_qah 的 properties，选择Transaction Log shipping，点击辅助数据库后的… 号打开Restore Transaction Log，直接点击Standby mode即可，可以勾选当日志恢复的时候断开所有用户的连接。如果设定的复制和恢复间隔时间很短，则当主服务器上所有在Restoring模式下的备份出来的日志文件在辅助服务器上恢复完毕后，会自动在复制到的目录中产生一个tuf文件。且辅助服务中Ecustom_qah 数据库由restoring显示为standby/read-only模式。如果设定的复制和恢复间隔时间很长，可以手动执行辅助服务其中的copy 作业和restore作业，将主服务器上所有未复制的日志文件复制到设定的恢复目录(restorelog)中，然后恢复到辅助服务器中。同样也可以将Standby mode切换回No recovery mode。图略。
2. 可以通过在原始数据库中创建新的表或表中插入记录在到辅助数据库中检查该变化是否亦同步，前提是使用Standby mode，此演示省略。
3. 故障转移
在主服务器Ecustom_qah数据库中，删除complex表中字段code_ts中以04开头的记录,delete from complex where code_ts like '04%'。
停止主服务器的MSSQLSERVER服务，然后删除主服务器中的Ecustom_qah数据库的mdf文件来模拟主服务器故障。
重新启动主服务器的MSSQLSERVER服务服务，在主服务器master中执行备份尾部日志。
backup log Ecustom_qah to disk ='D:/Restorelog/last.bak' with no_truncate
将主、辅助、监视服务器上日志传送的几个作业禁用(Disable) 。
在辅助服务器上执行copy作业和resotre作业将未复制过来的日志复制到恢复目录并全部恢复完毕。
将尾部日志恢复到辅助服务器辅助数据库中并使辅助数据库Ecustom处理联机状态。在辅助服务器master数据库中执行如下脚本:
restore log Ecustom_qah from disk = 'D:/Restorelog/last.bak' with norecovery;
go
restore database Ecustom_qah with recovery;
go
改变应用程序的连接字符串，使应用程序连接到辅助服务器的辅助数据库，此时辅助服务器的辅助数据库已变成为主服务器主数据库。
当原始主服务器修复后，再重新配置日志传送即可。
From: http://www.cnblogs.com/dudu/archive/2013/03/20/sql-server-log-shipping.html
一、什么是日志传送？
原理很简单，三个动作六个字：备份->复制->恢复。
如果由人来完成这个三个动作，只能叫日志搬运工；而由SQL Server Job自动完成，就叫日志传送。同样的事情，不一样的档次，所以叫法也不一样。
二、日志传送能解决什么问题？
解决数据库的多服务器热备份问题。多台服务器定时备份，随时可以作为主数据库服务器的替补。
三、日志传送的优点是什么？
简单！比SQL Server的数据库复制、镜像简单多了。
四、日志传送的缺点是什么？
日志文件的传输只支持Windows文件共享的方式，不支持FTP，就如同快递公司只送本地，不送外地。所有备份服务器都要在同一个局域网内，所以准确的名字应该叫“日志本地传送”。
五、日志如何传送？
1. [主数据库服务器]要传送日志的数据库的恢复模式必须是完全（Full）
2. [主数据库服务器]对要传送日志的数据库进行1次且仅此1次完全备份
BACKUP DATABASE [CNBlogsJob] TO DISK = N'F:\FullBackup\CNBlogsJob.bak' WITH NOFORMAT, INIT, NAME = N'CNBlogsJob-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10GO
3. [备份数据库服务器]将完全备份文件复制到备份数据库服务器上，并以STANDBY的方式进行恢复
RESTORE DATABASE [CNBlogsJob] FROM DISK = N'F:\FullBackup\CNBlogsJob.bak' WITH FILE = 1, MOVE N'CNBlogsJob' TO N'D:\Data\CNBlogsJob.mdf', MOVE N'CNBlogsJob_log' TO N'E:\Logs\CNBlogsJob.LDF', STANDBY = N'F:\Standby\ROLLBACK_UNDO_CNBlogsJob.BAK', NOUNLOAD, STATS = 10GO
恢复成功后，SQL Server管理工具中会显示如下图所示的状态：
4. [备份数据库服务器]创建一个普通的Windows用户帐户（比如logshipper），将该用户加入到以SQLServerSQLAgentUser开头的组（未验证是否可以不加），并将该用户设置为SQL Server Agent的运行帐户。
5. [备份数据库服务器]创建一个文件夹（比如F:\LogBackup），用于存放从主数据库复制过来的日志文件。
6. [主数据库服务器]创建与备份数据库服务器同名同密码的Windows用户帐户（比如这里是logshipper）。
7. [主数据库服务器]创建存放日志备份文件的文件夹，并将该文件夹以只读权限共享给logshipper。假设文件名称是LogBackup，主数据库服务器名称是dbserver，通过设置共享让备份数据库服务器可以访问共享路径 \\dbserver\LogBackup 。
8. [主数据库服务器]选择要进行日志传送的数据库，打开属性窗口，进入Transaction Log Shipping窗口，勾选Enable this as a primary database in a log shipping configuration，然后点击Backup Settings打开日志传送备份设置窗口，如下图：
\\dbserver\LogBackup 就是给备份数据库服务器访问的共享路径。
F:\LogBackup 是主数据库服务器保存日志备份文件的路径。
9. [主数据库服务器]继续回到Transaction Log Shipping窗口，在Secondary databases部分点击Add按钮，连接至备份数据库服务器，选择对应的数据库；在Initialize Secondary Database窗口中，选择"No, the secondary database is initialized"；在Copy Files窗口中，输入备份数据库服务器中存放备份日志文件的路径（比如F:\LogBackup）；在Restore Transaction Log窗口中，选择Standby mode。
10. 成功设置之后，日志传送就开始工作了。主数据服务器上的Job根据设定的时间间隔定时地备份当前数据库的日志，将日志文件保存至本机的文件夹（比如F:\LogBackup）；备份数据服务器上的Job不断地通过共享文件夹（比如\\dbserver\LogBackup）从主数据库服务器复制日志文件到本机的文件夹（比如F:\LogBackup），然后将日志文件恢复至处于Standby状态的数据库中。
