-> [下一步] -> [指定订阅服务器的类型] -> [运行SQL Server 2000的服务器]             -> [下一步] -> [指定项目] -> [在事务发布中只可以发布带主键的表] -> [选中一个有主键的待发布的表]                ->[在合并发布中会给表增加唯一性索引和 ROWGUIDCOL 属性的唯一标识符字段[rowguid],默认值是newid()]                                 (添加新列将: 导致不带列列表的 INSERT 语句失败,增加表的大小,增加生成第一个快照所要求的时间)                        ->[选中一个待发布的表]          -> [下一步] -> [选择发布名称和描述] ->           -> [下一步] -> [自定义发布的属性] -> [否，根据指定方式创建发布]          -> [下一步] -> [完成] -> [关闭]          发布属性里有很多有用的选项：设定订阅到期(例如24小时)               设定发布表的项目属性:          常规窗口可以指定发布目的表的名称，可以跟原来的表名称不一样。          下图是命令和快照窗口的栏目        ( SQL Server 数据库复制技术实际上是用insert,update,delete操作在订阅服务器上重做发布服务器上的事务操作           看文档资料需要把发布数据库设成完全恢复模式，事务才不会丢失            但我自己在测试中发现发布数据库是简单恢复模式下，每10秒生成一些大事务，10分钟后再收缩数据库日志，          这期间发布和订阅服务器上的作业都暂停，暂停恢复后并没有丢失任何事务更改 )          发布表可以做数据筛选，例如只选择表里面的部分列:         例如只选择表里某些符合条件的记录, 我们可以手工编写筛选的SQL语句:         发布表的订阅选项，并可以建立强制订阅:                    成功建立了发布以后,发布服务器上新增加了一个作业: [ 失效订阅清除 ]        分发服务器上新增加了两个作业:                 [ JIN001-dack-dack-5 ] 类型[ REPL快照 ]                [ JIN001-dack-3 ]      类型[ REPL日志读取器 ]

         上面蓝色字的名称会根据发布服务器名,发布名及第几次发布而使用不同的编号            REPL快照作业是SQL Server复制的前提条件,它会先把发布的表结构,数据,索引,约束等生成到发布服务器的OS目录下文件    (当有订阅的时候才会生成, 当订阅请求初始化或者按照某个时间表调度生成)REPL日志读取器在事务复制的时候是一直处于运行状态。(在合并复制的时候可以根据调度的时间表来运行)

      建立一个数据库复制订阅的过程:             [复制] -> [订阅] -> 右键选择 -> [新建请求订阅]           -> [下一步] -> [查找发布] -> [查看已注册服务器所做的发布]                 -> [下一步] -> [选择发布] -> [选中已经建立发布服务器上的数据库发布名]     

     -> [下一步] -> [指定同步代理程序登录] -> [当代理程序连接到代理服务器时:使用SQL Server身份验证]                                               (输入发布服务器上distributor_admin用户名和密码)                                                          -> [下一步] -> [选择目的数据库] -> [选择在其中创建订阅的数据库名]/[也可以新建一个库名]             -> [下一步] -> [允许匿名订阅] -> [是，生成匿名订阅]               -> [下一步] -> [初始化订阅] -> [是，初始化架构和数据]     

     -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件]                    (订阅服务器要能访问发布服务器的REPLDATA文件夹，如果有问题，可以手工设置网络共享及共享权限)     

     -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件]     

     -> [下一步] -> [设置分发代理程序调度] -> [使用下列调度] -> [更改] -> [例如每五分钟调度一次]     

     -> [下一步] -> [启动要求的服务] -> [该订阅要求在发布服务器上运行SQLServerAgent服务]     

     -> [下一步] -> [完成] -> [确定]               成功建立了订阅后，订阅服务器上新增加了一个类别是[REPL-分发]作业(合并复制的时候类别是[REPL-合并])    它会按照我们给的时间调度表运行数据库同步复制的作业        三、SQL Server复制配置好后, 可能出现异常情况的实验日志:

    1.发布服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制没有多大影响

        中断期间,分发和订阅都接收到没有复制的事务信息

    2.分发服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制有一些影响

        中断期间,发布服务器的事务排队堆积起来           (如果设置了较长时间才删除过期订阅的选项, 繁忙发布数据库的事务日志可能会较快速膨胀),                订阅服务器会因为访问不到发布服务器,反复重试            我们可以设置重试次数和重试的时间间隔(最大的重试次数是9999, 如果每分钟重试一次,可以支持约6.9天不出错)

        分发服务器sql server服务启动,网络接通以后,发布服务器上的堆积作业将按时间顺序作用到订阅机器上:

        会需要一个比较长的时间(实际上是生成所有事务的insert,update,delete语句,在订阅服务器上去执行)        我们在普通的PC机上实验的58个事务100228个命令执行花了7分28秒.

    3.订阅服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制影响比较大,可能需要重新初试化

        我们实验环境(订阅服务器)从18:46分意外停机以, 第二天8:40分重启动后,             已经设好的复制在8:40分以后又开始正常运行了, 发布服务器上的堆积作业将按时间顺序作用到订阅机器上            但复制管理器里出现快照的错误提示, 快照可能需要重新初试化,复制可能需要重新启动.            (我们实验环境的机器并没有进行快照初试化,复制仍然是成功运行的)        四、删除已经建好的发布和定阅可以直接用delete删除按钮        我们最好总是按先删定阅，再删发布，最后禁用发布的顺序来操作。        如果要彻底删去SQL Server上面的复制设置, 可以这样操作:

    [复制] -> 右键选择 [禁用发布] -> [欢迎使用禁用发布和分发向导]       -> [下一步] -> [禁用发布] -> [要在"@servername"上禁用发布]                 -> [下一步] -> [完成禁用发布和分发向导] -> [完成]        我们也可以用T-SQL命令来完成复制中发布及订阅的创建和删除, 选中已经设好的发布和订阅, 按属标右键   可以[生成SQL脚本]。(这里就不详细讲了, 后面推荐的网站内有比较详细的内容)      当你试图删除或者变更一个table时，出现以下错误   Server: Msg 3724, Level 16, State 2, Line 1   Cannot drop the table 'object_name' because it is being used for replication.

   比较典型的情况是该table曾经用于复制，但是后来又删除了复制

   处理办法：

   sp_configure 'allow updates', 1   go   reconfigure with override   go   begin transaction   update sysobjects set replinfo = '0' where replinfo >'0'   commit transaction   go   rollback transaction   go   sp_configure 'allow updates', 0   go   reconfigure with override   go

示例下例启动名为 Nightly Backup 的作业。

USE msdbEXEC sp_start_job @job_name = 'Nightly Backup'

2、日志还原功能、、、

--首先,创建一个演示用的数据库(主数据库)CREATE DATABASE Db_testON( NAME = Db_test_DATA,      FILENAME = 'c:/Db_test.mdf' )LOG ON ( NAME = Db_test_LOG,   FILENAME = 'c:/Db_test.ldf')GO

--对数据库进行备份BACKUP DATABASE Db_test TO DISK='c:/test_data.bak' WITH FORMATGO

--把数据库还原成备用数据库(演示主数据库与这个备用数据库之间的同步)RESTORE DATABASE Db_test_bak FROM DISK='c:/test_data.bak' WITH REPLACE,STANDBY='c:/db_test_bak.ldf',MOVE 'Db_test_DATA' TO 'c:/Db_test_data.mdf',MOVE 'Db_test_LOG' TO 'c:/Db_test_log.ldf'GO

--启动 SQL Agent 服务EXEC master..xp_cmdshell 'net start sqlserveragent',no_outputGO

--创建主服务器数据训与备用服务器数据库之间同步的作业DECLARE  @jogid uniqueidentifierEXEC msdb..sp_add_job@job_id = @jogid OUTPUT,@job_name = N'数据同步处理'

--创建同步处理步骤EXEC msdb..sp_add_jobstep @job_id = @jogid,@step_name = N'数据同步',@subsystem = 'TSQL',@command = N'--主数据库中进行日志备份BACKUP LOG Db_test TO DISK=''c:/test_log.bak'' WITH FORMAT

--备用数据库中还原主数据库的日志备份(应用主数据库中的最新变化--实际应该时主数据库备份与备用数据库的还原作业应该分别在主服务器和备用服务器上建立，并且备份文件应该放在主服务器和备用都能访问的共享目录中RESTORE LOG Db_test_bak FROM DISK=''c:/test_log.bak'' WITH STANDBY=''c:/test_log.ldf''',@retry_attempts = 5,@retry_interval = 5

--创建调度(每分钟执行一次)EXEC msdb..sp_add_jobschedule@job_id = @jogid,@name = N'时间安排',@freq_type=4,@freq_interval=1,@freq_subday_type=0x4,@freq_subday_interval=1,@freq_recurrence_factor=1

-- 添加目标服务器EXEC msdb.dbo.sp_add_jobserver @job_id = @jogid,@server_name = N'(local)' GO

--通过上述处理,主数据库与备用数据库之间的同步关系已经设置完成--下面开始测试是否能实现同步

--在主数据库中创建一个测试用的表CREATE TABLE Db_test.dbo.TB_test(ID int)GO

--等待1分钟30秒（由于同步的时间间隔设置为1分钟,所以要延时才能看到效果）WAITFOR DELAY '00:01:30'GO

--查询一下备用数据库,看看同步是否成功SELECT * FROM Db_test_bak.dbo.TB_test

/*--结果:ID          -----------

（所影响的行数为 0 行）--*/

--测试成功GO

--最后删除所有的测试DROP DATABASE Db_test,Db_test_bakEXEC msdb..sp_delete_job @job_name=N'数据同步处理'GO

/*===========================================================*/

/*--服务器档机处理说明使用这种方式建立的数据库同步，当主数据库不可用时（例如，主数据库损坏或者停机检修）可以使用以下两种方法使备用数据库可用。--*/

--2. 如果主数据库可以备份出最新日志，则可以使用下面的语句。--先备份主数据库的最新的事务日志--BACKUP LOG Db_test TO DISK=''c:/test_log.bak'' WITH FORMAT--再在备用数据库中恢复最新的事务日志，并且使备用数据库可读写（升级为主数据库）--RESTORE LOG Db_test_bak FROM DISK='c:/test_log.bak'

简单地说:1. 你的sql服务要使用指定的windows用户登陆, 而不能使用"本地系统帐户"2. 用于登陆sql服务的用户要求对共享目录具有所有权限3. 如果你的电脑没有加入到域, 还必须保证源和目标服务器的sql服务设置的登陆用户是一样的(用户名和密码都一样)

网络备份主要是权限设置问题, 参考下面的备份文件共享目录权限设置方法去解决目录的共享权限就可以了

下面假设是假设A服务器上的数据库备份到B服务器上的共享目录权限设置(两台服务器应该在局域网内,允许目录共享访问)::

1.机器A,B创建一个同名的windows用户,用户组设置为administrators,并设置相同的密码,做为备份文件夹文件夹的有效访问用户,操作:我的电脑--控制面板--管理工具--计算机管理--用户和组--右键用户--新建用户--建立一个隶属于administrator组的登陆windows的用户

2.在B机器器上,新建一个共享目录,做为备份文件的存放目录,操作:我的电脑--D:/ 新建一个目录,名为: BAK--右键这个新建的目录--属性--共享--选择"共享该文件夹"--通过"权限"按纽来设置具体的用户权限,保证第一步中创建的用户具有对该文件夹的所有权限--确定

3.设置 MSSQLSERVER 及 SQLSERVERAGENT 服务的启动用户开始--程序--管理工具--服务--右键 MSSQLSERVER--属性--登陆--选择"此账户"--输入或者选择第一步中创建的windows登录用户名--"密码"中输入该用户的密码--确定--同样的方法设置 SQLSERVERAGENT

4.在A机器上完成对B机器BAK目录的映射

5.查询分析器中执行下面的语句,检验是否成功:  exec master..xp_cmdshell 'dir 映射的盘符'

6.A服务器上做备份计划

备注:创建一个新的用户只是为了让MSSQLSERVER服务的启动帐户与共享目录的有效访问同名且密码相同,这样才能通过验证(所以你也可以用其他有效的用户来代替,只需要满足用户名和密码相同,并且拥有足够的权限)