采用事务复制的收益分析

简单的说，如果采用了事务复制的话，那么当发布服务器中的数据一有变化，就会马上反应到订阅服务器中。所以发布服务器与订阅服务器之间的数据延迟是 非常小的。如果网络性能还可以的话，那么这个延迟几乎可以忽略不计。但是事务复制最大的缺陷就是会导致性能的下降。这就好像卡车装货一样，每次都是一点点 的装，都没有装满。由此可见卡车运货的效率并不是很高。那么企业如果采用事务复制的话，可以给他们带来哪些收益呢?这些收益能否弥补性能下降所带来的损失 呢?

　　收益一：可以访问数据修改的中间状态。

　　采用快照复制的话，在订阅服务器上只能够反映一个最终的修改状态。如现在用户修改某个数据，其在一分钟内可能修改了五次(如通过触发器或者脚本 语言进行更改)。更改完毕后进行快照复制。此时在订阅服务器上保存的是最终更改的数据，即第五次更改后的结果。而对于前面四次更改的记录，在订阅服务器上 不会有任何反应。而如果采用了事务复制的话，则不同。因为采用事务复制，其触发的事件不是时间或者手工触发。而是当事务日志文件发生了变化(即数据库中的 数据或者数据架构由了变化)，即会将这个变化传递给订阅服务器。为此发布服务器中的任何更改都可以记录到订阅服务器中。像上面案例，用户在短时间内五次所 做的更改(可能用户自己都不知道)，都会反映到订阅服务器上。数据库管理员可以查到五次数据更改的明细。所以说，事务复制允许应用程序响应每次更改，而不 只是响应最终的数据更改。

　　在某些情况下，这个特性非常的有用。因为此时数据库管理员可以访问数据修改过程中的中间状态。如上例可以在订阅服务器上查询到所有五次的修改记 录。有时候系统管理员需要分析这个值的关联性，就需要用到这些修改的纪录。另外在测试触发器的有效性、数据约束等功能时，也需要查看这些更改的历史信息。 所以说，数据库管理可以访问数据修改的中间状态，这就是采用事务复制所带来的第一个好处。

　　收益二：不会造成网络性能上的瓶颈。

　　如果采用快照复制的话，系统会对整个发布服务器的数据进行备份，并将这个备份文件传输到订阅服务器。为此如果这个备份文件比较大的时候，那么在 企业网络中传输就会占用比较大的带宽，甚至可能会导致企业网络的拥塞。特别是当数据库发布服务器与订阅服务器分布在两地，通过互联网来传送快照时，这个网 络的带宽就容易成为这个快照复制功能的性能瓶颈。

　　但是如果采用事务复制的话，就可以避免这个缺陷。因为事务复制采取的是细水长流的措施。即每当发布服务器有更新，那么就会将整个更新的信息传递 给订阅服务器。也就是说，有多少更新就传输多少。而不是将更新的内容积累起来，等到一定的时候一起发送。另外，就是其只传输更新的内容。而不是向快照复制 那样，不管内容是否有更新，都进行传输。所以说，采用事务复制的话，不仅仅在网络中传输的数据量比较少。而且还比较均衡。除非数据库在某个特定的时刻一次 性有大量的数据更改操作，否则的话就不会对企业网络的性能产生很大的影响。这也给我们一个启示。如采用了事务复制功能，而又需要对数据进行大量更新的时 候，那么这个数据更新的时间要好好的设置一下。如在数据库访问量比较低的时候，或者企业用户不怎么使用访问的时候。在这个时候进行大量的数据更新，即使由 于事务日志传送需要占用比较多的网络带宽，但是由于受影响的用户比较少，为此也可以将由此带来的负面影响降之到最低。同时由于用户所占用的带宽比较少，为 此与事务复制的带宽争用现象也就比较少。

　　收益三：在不同厂商的数据库之间实现数据同步。

　　如果发布服务器与订阅服务器采用的是不同公司的产品。如订阅服务器采用的是Oracle数据库，而发布服务器采用的是SQLServer数据 库。如果要在这不同厂商的数据库之间实现数据同步的话，有比较好的方法吗?据笔者所知，现在最理想的方法就是采用数据复制。通过复制功能，将发布服务器上 的数据同步到订阅服务器。不过如果发布服务器与订阅服务器采用的数据库不同，则推荐使用事务复制功能。这主要是因为在快照复制中，有些功能是微软的 SQLServer服务器特有的，Oracle等其他数据库并不支持。而现在基本上所有的品牌数据库，都支持事务复制的功能。所以说，如果数据库管理员采 用事务复制的话，能够提供比较好的兼容性。即使发布服务器或者订阅服务器不是SQLServer，仍然可以采用复制功能保证发布服务器与订阅服务器数据的 一致性，提高了SQLServer服务器与其他厂商数据库服务器的一致性。不过如果订阅服务器不是SQLServer数据库的话，需要注意一点。在采用事务复制功能时，微软数据库的解决方案是允许订阅服务器向发布服务器更 新数据的。也就是说，如果订阅服务器与发布服务器都是SQLServer数据库的话，那么他们之间的更新可以是双向的。发布服务器的数据可以更新到订阅服 务器。同理订阅服务器上的数据如果发生了更新，也可以同步到订阅服务器。但是，如果订阅服务器采用的是非微软的数据库产品，那么是否支持这个双向的功能就 不一定了。主要是要看对方的数据库产品，是否支持这种双向的同步。为此对于有双向同步要求的企业，在这个数据库的选择上就需要多一份关注了。如一些连锁店 都推出了冲值卡，可以在同一个城市甚至全国范围内使用。此时就需要各地办事处的消费记录即使回传到总部。然后总部的发布服务器将这些数据更新到各地的销售 办事处。不然的话，消费者可以在一个地方消费完后，马上到另外一个地方消费。如果订阅服务器的数据没有及时更新到发布服务器。那么这消费卡中的金额就有可 能导致透支。最后给企业和消费者带来不可挽回的损失。

　　所以虽然通过事务复制提高了SQLServer数据库与其他数据库的兼容性，可以让非SQLServer的数据库来充当订阅服务器或者发布服务 器。但是在一些细节上在部署之前还需要进行测试。因为像这种双向更新的功能，需要双方的支持。光SQLServer数据库支持还是不够的。

　　收益四：实时实现数据同步。

　　在收看足球比赛时，观众往往希望比赛与转播同步。如果不同步的话，用户往往不会买账。特别是在有些国家，涉及到赌球的业务。哪怕直播时间相差一分钟，都能够给他们带来很大的损失或者给他们创造无穷的财富。可见实现数据同步的重要性。

　　在数据库部署中，有时候数据同步也是如此。如在银行中，用户可以通过多种手段来查询自己卡内的余额。可以通过ATM机查询、可以通过银行柜台查 询、也可以通过电话银行或者网络银行查询。企业柜台所采用的数据库、网络银行所采用的数据库与电话银行所采用的数据库往往不是同一个数据库。为此有时候通 过电话银行可能可以查到最近的一笔交易明细，而通过网上银行则还暂时查不到。这就是不同数据库之间数据同步延迟所造成的。各位读者额可以自己去试试看。像 建设银行、农业银行等等这种现象发生的并不是很多。或者说，他们的延迟时间比较短。而有些银行可能在这方面投入的比较少，为此需要花费比较长的时间内才能 够在各个数据库之间实现数据的同步。

　　为此如果企业对于数据同步的要求比较高的话，则最好采用事务复制。理论上事务复制可以实现数据的实时同步。但是实际工作中，往往由于网络性能的影响、数据库服务器的配置等等因素，会导致数据同步的延迟。此时就需要数据库管理员跟企业网络管理员、操做系统管理员一起优化配置，减少由此给事务复制带来的负面影响。