验证订阅服务器与发布服务器数据是否一致

 

通过SQLServer数据库的复制功能，可以让订阅服务器与发布服务器中的数据保持一致。通常情况下，不会发生什么问题。但是为了以防万一，数据库管理员仍然需要对订阅服务器中的数据进行验证，以判断数据是否与发布服务器中的数据一致。

 N
　　通过SQLServer数据库的复制功能，可以让订阅服务器与发布服务器中的数据保持一致。通常情况下，不会发生什么问题。但是为了以防万一，数据库管理员仍然需要对订阅服务器中的数据进行验证，以判断数据是否与发布服务器中的数据一致。特别是刚部署完复制策略时往往需要进行测试。那么在SQLServer数据库中如何来验证订阅服务器与发布服务器数据是否一致呢?一般来说，数据库管理员可以选择下面三种方式的任何一种来进行测试。
　一、 数据一致性验证的方法。
    　不同的数据库都有自己对应的验证方法。在SQLServer数据库中，主要有三种验证方法。需要注意的是，这三种验证方法各有特点，在性能与准确率上各有千秋。数据库管理员不得不掌握这三种方法的差异，并根据实际应用的情景，选择合适的验证方式。' I# |! o& ^& d$ y
　　第一种方式是只统计行数，即验证订阅服务器上的表与发布服务器上的表的行数是否相同。但是不会验证行的内容是否匹配。这种行统计方法是一种比较经济的验证方法，可以在短时间内完成数据的验证工作。但是无法判断行中的内容是否存在不匹配的情况。如有时候如果订阅服务器的配置与发布服务器的配置不一样的话，在订阅服务器中的中文数据有可能会出现乱码的情况。如果简单的通过行计数来进行验证的话，则往往查不出这个问题。9 R2 V; ~% t# ]7 }2 y/ a
　　第二种方式是行计数和二进制校验和。这种验证方法主要分为两个步骤。首先会验证订阅服务器与发布服务器上的表的行数是否相同。如果相同的话则进行下一步验证。如果不同的话，则结束验证，返回错误信息。如果相同，则数据库据还会使用校验和这种算法来计算所有数据的校验和，然后判断两个服务器数据是否一致。

        第三种方式是行计数和校验和。这种方式跟第二种方式类似，只是校验和的算法不一样而已。其也是分两个步骤来完成。首先通过行计数的方式来判断订阅服务器与发布服务器表中的记录行数是否相同。不相同的话，则直接结束验证过程。如果相同的话则会对服务器中所有的数据执行校验和的算法，进行验证。只是这个校验和的算法采用的是7.0版本中的校验和算法。为此笔者并不建议大家使用这种验证方式。
        简单的说，这几种验证方式的差异主要集中在是否采用校验和的算法。如果不采用校验和(二进制校验和)，而只采用行计数一个方法的话，只可以保证订阅服务器有与发布服务器表相同的记录。而不能够保证记录的一致性。不过在大部分情况下，只要记录的数量相同，就可以保证内容一致。记录数量相同而内容不同主要是由于发布服务器与订阅服务器的配置不同而造成的。如果数据库管理员能够排除这个原因，那么只采用行计数验证方法即可。毕竟行验证方法的效率比较高。而校验和(二进制校验和)的方法在保证订阅服务器与发布服务器表有相同记录的情况下，进一步验证其行中数据的一致性。这个验证方法虽然可以确保记录内容的一致，但是其需要比较长的验证时间。特别是到数据越多，其验证所需要的时间越长。可见这几种验证方法各有千秋，数据库管理员需要在性能与准确性上寻求平衡点。
        二、 数据验证过程中的注意事项。
     　默认情况下，即使订阅服务器与发布服务器数据同步过程中出现错误，系统管理员也不会受到任何有价值的警告信息。这主要是因为复制作业不会报告具体失败的行。只会有一个总的消息，即复制成功还是失败。如果失败的话，不会指名在同步哪张表或者哪条记录的时候出现错误。为此在必要时需要设置订阅服务器未通过数据验证的复制警报。只有如此，数据库管理元才可以在验证失败时得到相关的通知，从而及早采取措施来解决这个问题。3 F7 J0 y( K- A, B% E8 O+ L& W
& N: T6 n  m8 ^
　　虽然验证可以保障订阅服务器与发布服务器数据的一致性。但是其也会消耗服务器的资源，导致服务器性能的下降。为此在做数据验证这项工作的时候，需要注意以下几个方面的内容。
; r2 w1 t3 c6 E# T+ e" {  w
　　1、为了提高验证结果的准确性，在验证数据作业开始之前，必须停止订阅服务器上的一切更新活动。不过在验证进行时不需要停止发布服务器上的更新作业。也就是说，在数据验证时(无论是行计数验证还是校验和验证)，订阅服务器中的数据是不允许更新的。而发布服务器的数据仍然允许更新。在验证作业的过程中，数据库系统会自动设置一个时间点。在数据库发布服务器上是以这个时间点来验证相关数据的。这主要是考虑到发布服务器往往是主生产服务器，一般不允许停机。而作为订阅服务器，一般都是作为备份或者查询使用，在一段时间内设置为不允许更新不会有什么大的问题。所以才做出这个规定。% }$ Y  C! R. ^' u" n( j

   　2、要注意不同的验证方法对系统资源消耗程度的不同。一般来说，如果数据库中的数据比较多，此时无论采用校验和或者二进制校验和的方法来验证数据，都将会大量消耗服务器系统的资源，会很明显的降低数据库的性能。而且到数据库中的记录越多，这个负面效应越加明显。所以，如果确实需要采用校验和或者二进制校验和的方法来验证数据的话，那么笔者建议这个数据验证作业要为其安排一个合适的时间。如可以安排在数据库访问人数比较少的时候，如晚上的时间来完成。这可以降低由于数据验证工作对用户产生的影响。不过在晚上可能会进行多个消耗服务器资源的作业。如对数据库进行备份等等。所以数据验证作业即时放在数据库访问相对空闲的时候执行，也需要跟其他的一些大型作业错开执行。

       3、尽量采用行计数方法。行计数方法是一种比较经济的数据验证方法。其不但在准确性上有所保障，而且不会消耗过多的数据库资源。为此不会对数据库性能造成多大的负面影响。为此笔者的建议是，数据库管理员在测试复制方案准确性的时候，可以采用行计数方法和二进制校验和的方式进行测试。因为在测试阶段，牺牲一些服务器的资源也不会有多大的影响。等到数据库服务器投入生产使用之后，在最好采用行统计的验证方案。因为经过测试阶段的数据和验证，基本上可以消除导致内容不一致的一些因素。所以在这种情况下，只要验证订阅服务器与发布服务器表中的行数即可。只要行数相同，则其记录不会有问题。这是笔者的经验之谈。各位数据库管理员若有时间，也可以进行类似的测试。* c: ?4 [5 H) q- a( E
( W, _# ^/ X2 m0 _9 t( K
　　4、若确实要采用校验和的方法来进行数据验证的，那么最好使用二进制校验和，而不要采用7.0版本的校验和算法。二进制校验和是2000版本数据库引入的一种校验和算法。一直到现在最新的数据库版本仍然在使用它。这两种校验和算法除了在算法的机制上有差异外，在功能上也有一定的区别。通常情况下，二进制校验和对所有的表都适用。也就是说，可以对任何的表都进行二进制校验和运算。但是传统校验和算法却对一些特殊的表不起作用。如对于那些带有刷选器的表或者列偏移量不一致的逻辑表结构无法进行校验和运算。为此笔者认为，如果真的要对行内容进行验证的话，那么就彻底一点，对所有的表进行验证。因为采用二进制校验和验证与采用校验和验证两者的性能差不多，但是验证的内容是二机制验证比较齐全。所以笔者建议采用二进制校验和认证而不是校验和认证。. G+ m: v9 [* E+ Q5 _7 m
  　5、在对行的内容进行校验和验证或者二进制验证的时候，有可能会出现一些“误报”的现象。如由于需要，手工修改了订阅服务器上某个表中字段的数据类型。然后进行二进制校验和验证或者校验和认证时候，系统就会认为两个数据库中的内容不一致。其实，由于数据类型或者数据精度不一致，那么订阅服务器与发布服务器中内容确实不一致，所以从这个角度讲这个校验和认证与二进制校验和认证并没有误报。只是这点内容上的差异(或者只是数据类型上的差异，如发布服务器上采用的是日期型数据，而订阅服务器上由于特定的需要改为了字符型数据)，系统管理员是认可的。但是数据库系统一板一眼的。所以会产生这个所谓的误报现象。