事务日志传送这个功能有点像Oracle的DataGuard，具体介绍就不在这里废话了，本文主要记录我在实施过程中所遇到的问题以及解决方法。
事务日志传送的“传送”这个功能是通过Windows共享实现的，而不是好像Oracle那样由数据库本身的机制来进行传送(log_archive_dest_X = 'service=XXXXX')，一说到Windows共享就牵涉到用户权限的问题，所以配置事务日志传送这个功能所遇到的故障绝大部分都是由于用户的权限问题所造成的。
先上一张架构图，可以看到事务日志传送的就是由主库不断产生事务日志文件的备份（或者叫归档日志，可能更好理解）而备库不断还原这些事务日志备份文件的过程。
细心的朋友可能已经发现中间的backup文件是一个共享文件夹，如果这个共享文件夹位于主库的服务器上，主库的备份路径可以不写成UNC路径的形式，而备库则必须写成UNC路径的形式。如果这个共享文件夹位于备库的服务器上，主库的备份路径就要写成UNC路径，而备库可以写成本地路径的形式。如果共享文件夹即不在主库也不在备库的服务器上面，那么备份、还原目录的名称都要写成UNC路径了。
现在开始配置事务日志传送
第一部先确认备库中运行SQL Server的用户是什么：
在这里可以到SQL Server (MSSQLSERVER)这个服务是用“本地系统”这个用户启动的，这个用户在安装SQL Server的时候可以指定的。如果你的SQL Server是使用“本地系统”这个用户启动的话，就不能正常访问网络，也就不可以还原远程的备份文件，如果不修改启动的用户的话，等一下做事务日志传送的时候就会报这个错：
10.168.4.18是我主机的IP地址，此时，在备机的应用程序日志里面可以看到如下信息：
BackupDiskFile::OpenMedia: 备份设备 '\\10.168.4.18\backup\Lucky.bak' 无法open。操作系统错误 5(拒绝访问。)。
为了解决这个问题，我们需要让备机的不运行在“本地系统”这个帐号上面，我们创建一个普通的用户，例如叫做SqlUser，然后将这个用户加入到那堆SQLServer2005**************的组里面，如果不加入这些组的话，SQL Server会启动不了。
然后修改SQL Server的启动帐户，并重新启动SQL Server 服务。
在备库的服务器上面，也建一个SqlUser的用户，但是这个用户自需要属于Users组就可以了，当然主库、备库的SqlUser的密码得一样。
在主库上面建一个共享文件夹backup。
好了，自此准备工作已经完成，下面开始正式开始配置事务日志传送。
这两个窗口主要是调节备份归档事务日志的策略，注意，这里的本地路径要对应UNC路径，不明白的就看一下以下这张图：
然后，添加备库，为了尽快看到效果，我将“事务日志备份”，“复制文件”，“还原事务日志”的调度时间都调整为1分钟
一切OK之后，就可以开始创建事务日志传送，但是通常来说都会出现如下的问题：
10.168.4.100是我备库的服务器地址，大家仔细看一下错误，说是无法访问C:\Windows\System32\目录下的一个文件，实际上是无法写入创建该文件，此时，到备库的服务器上面，将已经还原出来的数据库（我这里是Lucky）删除掉，然后给C:\Windows\System32\这个目录加上一个用户权限，如下图所示：
我见过某些文章为省事特意将SqlUser这个用户加入到Administrators组里面，估计就是为了逃避这个问题，但是我不建议这样做，而且我觉得奇怪的是怎么会在这个目录建立文件呢，我很怀疑这是一个Bug。
然后再试一下，就可以了。
取消事务日志备份之后，备库依然是处于“备用/只读”的状态，可以查询，但是，还是不能写入，执行以下语句就可以使备库正式使用了
restore database Lucky with recovery