SQLServer 数据库中如何保持数据一致性

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

以下方法均为
事务复制
--PUSH方式
1、删除单个的发布
：
复制-->
本地发布-->
右击-->
删除，如下图，然后再把对应的订阅服务器删除掉，或者等待执行：sp_MSdistribution_cleanup
的JOB（分发清除:
distribution）默认订阅72小时失效之后自动删除。
2、删除全部的发布：
复制-->
右击
-->
禁用发布和分发，如下图，这个会同时的把分发服务器的配置清掉，需要重新配置的哦。。
其实只是执行了一个脚本
use
[master]
exec
sp_dropdistributor
@no_checks
=
1
GO
/
[
@no_checks=]
no_checks
指示在删除分发服务器之前是否检查有无依赖对象。no_checks
的数据类型为
bit，默认值为
0。
如果为
0，则
sp_dropdistributor
将执行检查，以确保除分发服务器以外的所有发布和分发对象都已删除。
如果为
1，则
sp_dropdistributor
将在卸载分发服务器之前删除所有发布和分发对象。
[
@ignore_distributor=]
ignore_distributor
指示是否在未连接到分发服务器的情况下执行此存储过程。ignore_distributor
的数据类型为
bit，默认值为
0。
如果为
0，则
sp_dropdistributor
将连接到分发服务器，并删除所有复制对象。
如果
sp_dropdistributor
无法连接到分发服务器，则存储过程将失败。
如果为
1，则不与分发服务器建立连接，并且不删除复制对象。
如果分发服务器正在卸载或持久脱机，才使用它。
直到分发服务器在未来某个时间重新安装之后，才会删除分发服务器中的该发布服务器的对象。
/
--注意:
sp_dropdistributor
用于所有类型的复制。
不过不是建议直接的界面 *** 作。
3、对于某些时候可能删除不掉，这个时候可以直接trace一下，然后把进程杀掉
4、或者对于附加的数据库不注意可能会出现发布的错误，你也删除不掉。会报下面的错误。
无法作为数据库主体执行，因为主体
"dbo"
不存在、无法模拟这种类型的主体，或您没有所需的权限。
已将数据库上下文更改为
'AdventureWorks2008'。
(Microsoft
SQL
Server，错误:
15517)
这个时候可以查一下数据库属性->文件->所有者如果没有话，填个sa再试一次就可以。

50 文档说明
除可用的新功能之外，本节还包含运行 SP3 时可能发生的问题。这些问题可能发生在从 SQL Server 2000、SQL Server 2000 SP1 或 SQL Server 2000 SP2 运行 Service Pack 进行升级的情况下。本节未描述 SP3 中提供的所有修补程序。要查看这些修补程序的完整列表，请参见 Microsoft 知识库文章 306908。
本节中的 Analysis Services 和 Meta Data Services 部分不适用于仅 Desktop Engine 安装。
本自述文件中未能及时提供的 SQL Server 2000 Service Pack 3 相关信息，将在 Microsoft 知识库文章 330022 中提供。该文章可以在 Microsoft 产品技术支持服务知识库中找到。
51 数据库引擎和 Desktop Engine 增强功能
下列增强功能适用于安装 Database Components SP3 的 SQL Server 2000 实例。也适用于安装 Desktop Engine SP3 的 Desktop Engine 实例。
511 在 Database Components SP3 中使用中文、日语或朝鲜语字符
在 SP1 中引入
如果在运行 Windows NT 40 的服务器或 Windows 98 上安装了 Database Components SP3 之后再升级到 Windows 2000，Windows 2000 升级过程将替换某些系统文件。在对中文、日语或朝鲜语字符排序时，需要使用这些系统文件。如果在 SQL Server 数据库中使用中文、日语或朝鲜语字符，在升级到 Windows 2000 后，需重新运行 SP3 附带的 Sqlredisexe。有关运行 Sqlredisexe 的更多信息，请参见 42 再发布 SP3 数据访问组件。
说明 如果客户机或服务器上没有含中文、日语或朝鲜语字符的数据库，则无需重新应用 Sqlredisexe。
512 散列组已删除
在 SP1 中引入
散列组 (hash teams) 已删除。由于 SQL Server 2000 中的改进，使用散列组已不能获得它们在 SQL Server 70 中所提供的性能好处。而且，删除散列组使得 SQL Server 2000 更加稳定。
因此，查询优化器不再用散列组生成查询计划。
在极个别的情况下，删除散列组可能会使查询的处理速度减慢。请分析这类查询并确定创建更适合的索引是否能使查询性能恢复到以前的水平。
513 添加的 Affinity Mask 开关
在 SP1 中引入
此 Service Pack 添加了两个 Affinity Mask 开关。
Affinity Mask I/O 开关
使用此 Service Pack，可以指定使用哪些 CPU 来运行用于磁盘 I/O *** 作的线程。这一开关必须与 Affinity Mask 选项结合起来使用。有关更多信息，请参见 Microsoft 产品技术支持服务知识库中的文章 298402。有关搜索知识库的指导，请参见 13 关于 SP3 的其他信息。
Affinity Mask 连接开关
使用此 Service Pack，可以将支持虚拟接口体系结构 (VIA) 的系统配置为将 SQL Server 连接从某些网卡绑定到一个处理器或一组处理器。这一开关必须与 Affinity Mask 选项结合起来使用。有关更多信息，请参见 Microsoft 产品技术支持服务知识库中的文章 299641。
详细内容参见
>