MSSQL数据库备份

SQL   SERVER   2005   同步复制技术(转)

以下实现复制步骤（以快照复制为例）  

运行平台SQL   SERVER   2005  

一、准备工作：  

1．建立一个   WINDOWS   用户，设置为管理员权限，并设置密码，作为发布快照文件的有效访问用户。  

2．在SQL   SERVER下实现发布服务器和订阅服务器的通信正常（即可以互访）。打开1433端口，在防火墙中设特例  

3．在发布服务器上建立一个共享目录，作为发布快照文件的存放目录。例如：在D盘根目录下建文件夹名为SqlCopy  

4．设置SQL   代理（发布服务器和订阅服务器均设置）本篇文章发表于www.xker.com(小新技术网)  

打开服务(控制面板---管理工具---服务)  

---右击SQLSERVER   AGENT---属性---登录---选择“此帐户“  

---输入或选择第一步中创建的WINDOWS   用户  

---“密码“中输入该用户密码  

5．设置SQL   SERVER   身份验证，解决连接时的权限问题（发布、订阅服务器均设置）  

步骤为：对象资源管理器----右击SQL实例-----属性----安全性----服务器身份验证------选“SQL   Server和WINDOWS“，然后点确定  

6.开启SQL   Server   2005的网络协议TCP/IP和管道命名协议并重启网络服务。  

7.在SQL   Server中创建步骤1中对应的系统用户登陆名，作为发布数据库的拥有者（设置为dbo_owner和public）。  

8．以系统超级用户sa登陆SQL   Server建立数据库和表。  

9．发布服务器和订阅服务器互相注册  

步骤如下：视图----单击以注册服务器----右键数据库引擎----新建服务器注册-----填写要注册的远程服务器名称------身份验证选“SQL   Server验证“-----用户名(sa)   密码------创建组（也可不建）-----完成。  

10．对于只能用IP，不能用计算机名的，为其注册服务器别名  

二、开始：  

发布服务器配置（在发布服务器上配置发布和订阅）  

1．   选择   复制   节点  

2．   右键本地发布   ----下一步---------系统弹出对话框看提示----直到“指定快照文件夹“  

----在“快照文件夹“中输入准备工作中创建的目录(指向步骤3所建的共享文件夹)------选择发布数据库-------选择发布类型-------选择订阅服务器类型-------选择要发布的对象------设置快照代理-------填写发布名称。本篇文章发表于www.xker.com(小新技术网)  

3．   右键本地订阅--------选择发布服务器-------选择订阅方式（如果是在服务器方订阅的话选择推送订阅反之  

选择请求订阅）-------填加订阅服务器--------选择代理计划（一般选择连续运行）---------其余选择默认项。  

至此,   SQL   SERVER   2005   同步复制就完成了。使用复制技术，用户可以将一份客户端的数据发布到多台服务器上，从而使不同的服务器用户都可以在权限的许可的范围内共享这份数据。复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性,就无需编程实现客户端和服务器端数据同步了！大大提高了工作效率！
=======================================

一、 事务复制的特点
    前面我们指出复制的本质就是从源数据库向目标数据库复制数据，但对不同的复制类型而言总是有差别的。从复制的具体内容来看快照复制是真正意义上的数据复制，不管采用何种数据接收方式（如将表删除后再重建或删除表中数

据但保留表结构），在网络中传送的是数据。而事务复制在网络中传送的是事务（由一条或多条INSERT、 DELETE、 UPDATE）；从传输的数据量来看，事务复制仅将发生的变化传送给订购者，是一种增量复制，但快照复制却将整个出版

物复制给订购者。
    由于事务复制要不断地监视源数据库的数据变化，所以与快照复制相比，其服务器负载相应要重。
    在事务复制中当出版数据库发生变化时，这种变化就会被立即传递给订购者，并在较短时间内完成（几秒或更短），而不是像快照复制那样要经过很长一段时间间隔。因此，事务复制是一种几近实时地从源数据库向目标数据库分发

数据的方法。由于事务复制的频率较高，所以必须保证在订购者与出版者之间要在可靠的网络连接。
    事务复制只允许出版者对复制数据进行修改（若设置了立即更新订购者选项，则允许订购者修改复制数据），而不像合并复制那样，所有的节点（出版者和订购者）都被允许修改复制数据，因此事务复制保证了事务的一致性。它所

实现的事务一致性介于立即事务一致性和潜在事务一致性之间。
    由于事务复制在极小的时延内把数据分发到订购者，因此要求出版者与订购者总是保持连接。但在快照复制中，由于相邻两次复制数据的传递间隔时间较长，则允许订购者与出版者不必保持永久连接。
    事务复制另外一个独有特点是支持并行的快照处理，这也是SQL Server 2000 事务复制的新特征。正如在快照复制一节中所叙述的那样，通常而言，在创建初始快照文件的整个处理过程中，都要在出版表上放置一个共享锁来阻止对

出版的更。新但事务复制所支持的并行快照处理却允许在创建快照文件的整个过程中不必将共享锁保持到快照文件创建结束之时。其具体过程是：在复制开始时，快照代理在出版表上放置共享锁。当表示快照开始的事件被写入事务日志

时，该共享锁即被释放。这样在随后的时间，即使快照文件仍处于生成过程中，仍可以对出版表进行修改。由此可见，共享锁在出版表时持续的时间很短。释放共享锁的时刻正是快照代理开始创建快照文件的时刻。在结束快照文件创建

时。表明创建结束的事件被记录到事务日志中。在从开始到结束的整个快照生成过程中所发生的影响出版表的事务将被日志阅读代理发送到分发数据库。
    并行快照处理虽然允许在创建快照文件的过程中对出版表进行修改，但也因此而增加了快照处理的负载，降低了复制处理的性能，所以应在系统活动较少时，进行快照初始化处理。

二、 事务复制的执行步骤
事务复制的执行主要需要三个代理：快照代理、日志阅读代理、分发代理。

1 快照代理
    快照代理从出版者获取新的变化之前，必须使订购数据库的表与出版数据库表具有相同的表结构和数据。因此快照代理首先要实现同步集合的初始化。SQL Server 只有在确认订购者包含表描述与数据的快照文件后，才能进行事务复

制。

2 日志阅读代理
从出版者事务日志中搜索出带有复制标志的事务，并将这些事务插入分发数据库。

3 分发代理
分发代理将日志阅读代理插入到分发数据库中的事务分发到订购者。
在事务复制中快照代理和分发代理的具体步骤与快照复制基本相同。事务复制中各代理按照以下的执行顺序来协调工作完成事务复制（见图16-53）。
 
（1） 当创建订购时或到了创建出版物时，所规划的时间快照代理就会被执行，快照代理在论文上放置共享锁之后，便创建包含数据文件与描述文件的同步集合。描述文件主要是为了在订购数据库内创建与论文表相同的表结构。然后将

：这两个文件存储在分发者的复制目录下，并在分发数据库中记录同步作业。

（2） 日志阅读代理可以连续不断地运行或在出版物创建时规划的时刻运行来监视数据变化。日志阅读代理执行时，它首先阅读出版物的事务日志，搜索出带有复制标志的INSERT、 UPDATE、 DELETE 语句和其它修改事务。接着，日志阅

读代理将这些带有复制标志的事务批拷贝至分发者的分发数据库中。日志阅读代理使用系统过程sp_replcmds 从日志中来获取下一批带有复制标志的命令。只有那些被提交的事务才送至分发数据库。

    在分发数据库中的复制事务和出版者事务日志中有复制标志的事务是一一相对的。在 Msrepl_transactions 表中存储的一个事务可由多个命令组成，每一条命令存储在Msrepl_ commands 表中。在整个批事务成功写入分发数据库后

，每一命令将被提交接着阅读代理调用sp_repldone 系统过程来标明复制事务最终在哪里完成。最后代理标明在事务日志中的哪一行将被截掉。那些仍旧等待复制的行不会被截掉。从出版者删除事务日志并不影响复制，因为只有那未标

有复制的事务才会被清除。
（3） 事务命令一直存储在分发数据库中，除非分发代理从分发者将其推至订购者数据库或从订购者将其拉到订购者数据库。

注意：分发代理第一次执行时的主要任务是订购初始化，即将初始快照文件分发到订购者。
      分发代理仅用于复制而不包含任何用户表，同时也不允许在分发数据库中创建任何其它数据库对象。
      在出版者招待的将被复制的操作将按顺序在订购者上被执行、确保数据的最终一致性。
      如果订购事务出版物但却没有对订购进行初始化，那么在出版者上自动定制的存储过程都不能在订购者上使用。相反必须在订购者手工创建存储过程。

三、 存储过程的复制
    SQL Server 中除了可以复制表以外还可以复制存储过程。在快照复制中，如果论文中包含存储过程，则在复制过程中整个存储过程将从出版者传递到订购者。在事务复制中，如果论文中包含存储过程，则在复制过程中传递给订购者

仅是一条存储过程的执行语句，而不是由存储过程的执行而引起变化了的数据。
    如果某一存储过程在执行后产生的结果集很大，我们会发现仅复制存储过程的执行语句而不是大量的SQL 语句将带来极大好处。不必再担心大量的复制语句会占满分发数据库而引起事务丢失，也不再会因复制大量的SQL 语句而引起

网络传输性能的下降而感到沮丧。
    下面的例子也许会帮助用户更为深刻地理解复制存储过程的优点。
    假如数据库的使用者打算修改出版物中某一表的10000 条记录的某一列。如果不使用存储过程复制，它的处理过程应是这样的：当这些修改在出版者完成时，日志阅读代理便会从事务日志中读出这些带有复制标志的上10000 条

DELETE 语句以及相同数目的UPDATE 语句，并将它们送到分发数据库，分发数据库有限的空间立刻显得有些局促起来如果您很不走运的话，分发数据库会被添满而导致复制中断），然后分发代理再把这20000 条语句分发到订购者，在分

发时20000 语句争先恐后地挤满了网络线路，我想您会体会到那种等待的滋味。
    但是，如果利用存储过程来实现这一修改，并在您的事务复制论文中添上该存储过程，那么在网上传递上仅是一条EXEC 语句。
    将一存储过程定义成出版内容并不是一件困难事，只要在图16-31 Specify Articles 对话框中选中Include Store 复选框即可。