SQLServer 数据库中如何保持数据一致性
根据实现策略的不同，主要有快照复制、事务复制、合并复制等三种类型。这三种复制类型，各有各的特点，分别适用于不同的场合。一般来说，在考虑采用哪种复制类型比较合适的时候，主要考虑的是性能与数据同步的时间间隔。那么在什么情形下比较适用快照复制呢?笔者就跟大家来讨论一下这个话题。
为了在恰当的时候采用快照复制，数据库管理员首先需要知道快照复制的特点。快照复制是指将数据以特定时刻的瞬时状态转发，而不坚实对数据的更新。在发生同步时，将生成完整的快照并将其发送到订阅服务器。简单的说，快照复制就是每隔一段时间发生数据同步操作。而不是发布服务器的数据一有更新就出发这个快照复制。显然这种快照复制的数据同步性稍微差一点。在订阅服务器与发布服务器之间有一段时间会存在数据不一致的情况。但是这可以在很大程度上提高订阅服务器与发布服务器的性能。这就好像汽车运输。采用快照复制的话可以将一个集装箱装满后在送货，而不是有多少送多少。掌握这个数据库复快照复制的具体特点之后，数据库管理员就可以来考虑在什么情况下，采用快照复制更加的合理。
一、数据更改比较少的系统中。
快照复制与其他复制相比最主要的缺陷就是数据库中的数据无法及时同发布服务器一致。为此如果发布服务器中的内容很少更改的话，显然此时采用快照复制是比较合理的。此时采用快照复制的话，不仅数据一致性延迟的负面效应会越来越不明显，同时可以提高发布服务器与订阅服务器的性能。如在实际工作中，经常会遇到这样的客户。如一家企业在各地都有办事处或者销售机构，就像肯德基一样，各地的产品价格基本上都是相同的，不怎么会更改。即使更改的话，各地也是统一调整。由于此时产品价格表更改的比较少，那么在企业总部的数据库服务与各地的订阅服务器之间，采用快照复制的形式就会比较合适。其实类似的情况有很多。如不少的服装企业，像李宁、耐克等等，他们不仅自己生产，而且在各地又有自己的销售办事处。在价格方面也是统一的。在这种情况下，采用快照复制往往能够提高数据库复制的性能，同时又不影响其使用。
二、在某个时段内会出现数据大量的更改。
需要补充说明的一点是，上面说到的数据不怎么发生更改，指的是数据的延续性更改。如在一年中，每天或者每个小时更改的数据都比较平均。此时采用快照复制不怎么合适。但是如果数据的更改集中在一个时段内。而其他时间中数据库的内容不会有多大的更改。此时采用快照复制是可行的。如一些决策性系统，往往在起初导入数据的时候，需要进行大量的更改。而等到数据导入完毕，在大家对数据进行分析时，则数据库中的内容基本上保持不变。在这种情况下，笔者认为只要数据的更新集中在一个固定的时段，此时采用快照复制仍然是可行的。
再如上面这个KFC或者服装企业的案例中，如果市场部门维护一个产品的价格，而且这些价格往往在一个固定的时间进行几次更新。如在换季的时候会进行一些促销。此时数据库管理员可以在数据更新完毕后立即执行复制完成的数据快照。所以，以数据更新来判断是否适合采用快照复制，标准并不是数据的更新量。像上面提到的分析决策系统，其起初的数据更新量可能比有些数据库系统几年的数据更新量都要大。笔者认为，主要是根据数据更新的频率来进行判断。如果数据更新的比较频繁，那么即使数据更新的数据不多，像那种细水长流似的更新，则不适合采用快照复制。而那些井喷似的数据更新，所有的更新都集中在一个固定的时刻，那么此时采用快照复制是比较合理的。
三、在一段时间内是否允许具有相对发布服务器已过时的数据副本?
现在不少超市也已经连锁了，如世纪联华等等。为了提高利润，增加市场的份额，这些超市纷纷推出了冲值卡，即消费者先将一定金额的人民币打入到冲值卡中。然后每次消费完成后从卡中扣费。但前些天经常有新闻报道，说一个客户的消费卡在一家联华超市挂失了。但是捡到这张卡的人仍然可以在其他的联华超市中消费。为此消费者就想不明白了，为什么挂失了的消费卡仍然可以在其他超市中消费?挂失后的损失该由谁来承担呢?其实这就使超市在不适当的时候采用了快照复制所造成的。由于采用快照复制，在各个联华超市的数据库之间数据无法在短时间内取得一致。如有些商户说挂失当日之内的损失他们不承担，这就说明他们可能是每天下班后进行一次快照复制。一般情况下这不会有问题。但是像遇到消费卡被偷了等情况，就会遇到类似的问题了。
所以，在考虑是否适合采用快照复制的时候，还需要考虑在一段时间内是否允许具有相对发布服务器来说已过时的数据副本。如果不允许的话，那么就不允许采用这个快照复制。如果允许的话，那么数据库管理员就需要评估这段时间最长是多少。如果是24个小时，那么就需要每隔24小时进行一次快照复制。但是需要注意的是，如果时间的间隔比较短，如才允许十分钟的数据延迟，那么采用快照复制就没有必要了。此时采用事务复制或则和合并复制可能更加的合适。
四、复制少量的数据。
快照复制跟其他复制类型相比，还有一个比较显著的特点，即当发生数据同步时，将生成完整的快照并将其从发布服务器传送到订阅服务器。这是一个什么概念呢?如订阅服务器中有10G的数据，而在一个快照复制的周期内，只有1M的数据发生了更改。此时发生快照复制的话，数据库系统会将10G的数据都传送到订阅服务器上。此时更改的数据只有1M，却需要在网络上传送10G的数据流量，显然会对企业的网络产生比较大的压力。由于在发布服务器上快照复制的连续开销低于事务复制的开销，一次数据库系统不会启用跟踪增量更改。但是像这种情况，如果要复制的数据量非常的大，而平时的更新又不多。此时数据库系统要生成和应用快照，就将耗用大量的资源，包括网络资源和服务器资源。所以说，当发布服务器中的数据比较多时，采用快照复制不怎么合适。因为此时网络传输反而会成为其最重大的瓶颈资源。相反若能够采取细水长流的事务复制策略，那么对于企业网络性能的影响就会小的多，甚至可以忽略不计。
所以在采用快照复制的时候，数据库管理员一定要明白，快照复制会传送整个数据库对象。从而在快照复制传输过程中会侵蚀大量的网络带宽，从而明显的降低企业网络的性能，甚至导致网络拥塞。有时候为了保障快照能够准确、迅速的传递到其他的订阅服务器，还不得不采用VPN等技术来保障传输的准确性。为此，笔者认为只有发布服务器的数据库并不是很大的情况下，才适合采用快照复制。否则的话，采用快照复制是得不偿失。
从以上的分析中，可以得到一个结论。在考虑采用快照复制是否合适时，往往不能够采用一个指标来判断。而需要考虑多个因素，如数据库的大小、数据更新的频率、允许数据延迟的时间等等因素来进行判断。最后在数据的一致性与数据库的性能之间取得一个均衡。说实话，对于大部分数据库管理员来说，要做出一个抉择，确实有困难。因为这没有固定的指标可以拿来参考。如数据库容量小于多少时该采用快照复制。任何一个数据库管理专家都不能够下这个结论。所以在掌握影响其选择的相关因素外，就要依靠数据库管理员的经验了。在遇到类似的选择题时，往往经验可以帮助管理员迅速解决问题。最后需要提醒的是，无论最终采取了什么方案，最好能够持续跟踪一段时间，看看自己的选择是否合理。