sqlserver数据库快照
数据库快照是MSSQL2005的新功能，仅在 Microsoft SQL Server 2005 Enterprise Edition 中可用。而且SQL Server Management Studio 不支持创建数据库快照，创建快照的唯一方式是使用 Transact-SQL。
数据库快照是数据库（称为“源数据库”）的只读静态视图。在创建时，每个数据库快照在事务上都与源数据库一致。在创建数据库快照时，源数据库通常会有打开的事务。在快照可以使用之前，打开的事务会回滚以使数据库快照在事务上取得一致。
客户端可以查询数据库快照，这对于基于创建快照时的数据编写报表是很有用的。而且，如果以后源数据库损坏了，便可以将源数据库恢复到它在创建快照时的状态。
创建数据库快照可以：
·<!--[if !supportLists]--><!--[endif]-->维护历史数据以生成报表。可以通过快照访问特定时间点的数据。例如，您可以在给定时间段（例如，财务季度）要结束的时候创建数据库快照以便日后制作报表。然后便可以在快照上运行期间要结束时创建的报表。
·<!--[if !supportLists]-->将查询实施在数据库的快照上，可以释放主体数据库上的资源。
·<!--[if !supportLists]-->加快恢复操作效率，使用快照将数据库恢复到生成快照时的状态比从备份还原快得多；但是，此后您无法对数据进行前滚操作。根据磁盘资源，可以每 24 小时创建 6 到 12 个滚动快照。每创建一个新的快照，就删除最早的快照。如果要恢复，可以将数据库恢复到在错误发生的前一时刻的快照。或者，也可以利用快照中的信息，手动重新创建删除的表或其他丢失的数据。例如，可以将快照中的数据大容量复制到数据库中，然后手动将数据合并回数据库中。
但是只要存在数据库快照，快照的源数据库就存在以下限制：
·<!--[if !supportLists]-->必须在与源数据库相同的服务器实例上创建数据库快照。
·<!--[if !supportLists]--> <!--[endif]-->数据库快照捕获开始创建快照的时间点，去掉所有未提交的事务。未提交的事务将在创建数据库快照期间回滚，因为数据库引擎 将对快照执行恢复操作（数据库中的事务不受影响）。
·<!--[if !supportLists]-->当将源数据库中更新的页强制压入快照时，如果快照用尽磁盘空间或者遇到某些错误，则该快照将成为可疑快照并且必须将其删除。有关详细信息，请参阅删除数据库快照。
·<!--[if !supportLists]-->快照为只读。
·<!--[if !supportLists]--> <!--[endif]-->禁止对 model 数据库、master 数据库和 tempdb 数据库创建快照。
·<!--[if !supportLists]--> <!--[endif]-->不能更改数据库快照文件的任何规范。
·<!--[if !supportLists]--><!--[endif]-->不能从快照中删除文件。
·<!--[if !supportLists]-->不能备份或还原快照。
·<!--[if !supportLists]-->不能附加或分离快照。
·<!--[if !supportLists]-->不能在 FAT32 文件系统或 RAW 分区中创建快照。
·<!--[if !supportLists]--> <!--[endif]-->数据库快照不支持全文索引，不能从源数据库传播全文目录。
·<!--[if !supportLists]-->数据库快照将继承快照创建时其源数据库的安全约束。由于快照是只读的，因此无法更改继承的权限，对源数据库的更改权限将不反映在现有快照中。
·<!--[if !supportLists]-->快照始终反映创建该快照时的文件组状态：在线文件组将保持在线状态，离线文件组将保持离线状态。有关详细信息，请参阅本主题后面的“含有离线文件组的数据库快照”。
·<!--[if !supportLists]-->如果源数据库的状态为 RECOVERY_PENDING，可能无法访问其数据库快照。但是，当解决了源数据库的问题之后，快照将再次变成可用快照。
·<!--[if !supportLists]-->只读文件组和压缩文件组不支持恢复。尝试恢复到这两类文件组将失败。有关恢复的详细信息，请参阅恢复到数据库快照。
㈡ sqlserver数据库实时同步是选快照发布还是事务发布
1. SQLSERVER服务器上面安装oracle客户端，配置服务命名(假设为 test)
2. 在SQLSERVER服务器上面建立链接服务器，脚本如下
SQL code?
SQL code-- Adding linked server:
exec sp_addlinkedserver @server = 'test' ,
@srvproct = 'ORACLE',
@provider = 'MSDAORA',
@datasrc = 'test'
-- Adding linked server login:
exec sp_addlinkedsrvlogin @useself='false ', @rmtsrvname = 'test',
@rmtuser = 'user', --数据库用户
@rmtpassword = 'password' --密码
3. 建立一个作业，通过作业调度存储过程，存储过程使用类似的语句将oracle的数据插入到sqlserver表中
SQL code?
insert into sqlserver表 select * from test..oracle表名
4. 如果要球ORACLE数据是实时增加的，并且ORACLE记录上有递增的字段，可以在SQLSERVER上面建立一个表记录上次插入的id，然后下次可以从上次的ID+1开始继续插入
SQL code?
insert into sqlserver表 select * from test..oracle表名 where id>@id
5. 防止sqlserver同步的时候oracle仍在不断的插入，每次要取一个结束ID
SQL code?
select @endid=max(id) from test..oracle表名.
㈢ SQLServer数据库中如何保持数据一致性
根据实现策略的不同，主要有快照复制、事务复制、合并复制等三种类型。这三种复制类型，各有各的特点，分别适用于不同的场合。一般来说，在考虑采用哪种复制类型比较合适的时候，主要考虑的是性能与数据同步的时间间复制是SQLServer数据库中保持数据一致性的一种手段。根据实现策略的不同，主要有快照复制、事务复制、合并复制等三种类型。这三种复制类型，各有各的特点，分别适用于不同的场合。一般来说，在考虑采用哪种复制类型比较合适的时候，主要考虑的是性能与数据同步的时间间隔。那么在什么情形下比较适用快照复制呢?笔者就跟大家来讨论一下这个话题。 为了在恰当的时候采用快照复制，数据库管理员首先需要知道快照复制的特点。快照复制是指将数据以特定时刻的瞬时状态转发，而不坚实对数据的更新。在发生同步时，将生成完整的快照并将其发送到订阅服务器。简单的说，快照复制就是每隔一段时间发生数据同步操作。而不是发布服务器的数据一有更新就出发这个快照复制。显然这种快照复制的数据同步性稍微差一点。在订阅服务器与发布服务器之间有一段时间会存在数据不一致的情况。但是这可以在很大程度上提高订阅服务器与发布服务器的性能。这就好像汽车运输。采用快照复制的话可以将一个集装箱装满后在送货，而不是有多少送多少。掌握这个数据库复快照复制的具体特点之后，数据库管理员就可以来考虑在什么情况下，采用快照复制更加的合理。 一、数据更改比较少的系统中。 快照复制与其他复制相比最主要的缺陷就是数据库中的数据无法及时同发布服务器一致。为此如果发布服务器中的内容很少更改的话，显然此时采用快照复制是比较合理的。此时采用快照复制的话，不仅数据一致性延迟的负面效应会越来越不明显，同时可以提高发布服务器与订阅服务器的性能。如在实际工作中，经常会遇到这样的客户。如一家企业在各地都有办事处或者销售机构，就像肯德基一样，各地的产品价格基本上都是相同的，不怎么会更改。即使更改的话，各地也是统一调整。由于此时产品价格表更改的比较少，那么在企业总部的数据库服务与各地的订阅服务器之间，采用快照复制的形式就会比较合适。其实类似的情况有很多。如不少的服装企业，像李宁、耐克等等，他们不仅自己生产，而且在各地又有自己的销售办事处。在价格方面也是统一的。在这种情况下，采用快照复制往往能够提高数据库复制的性能，同时又不影响其使用。 二、在某个时段内会出现数据大量的更改。 需要补充说明的一点是，上面说到的数据不怎么发生更改，指的是数据的延续性更改。如在一年中，每天或者每个小时更改的数据都比较平均。此时采用快照复制不怎么合适。但是如果数据的更改集中在一个时段内。而其他时间中数据库的内容不会有多大的更改。此时采用快照复制是可行的。如一些决策性系统，往往在起初导入数据的时候，需要进行大量的更改。而等到数据导入完毕，在大家对数据进行分析时，则数据库中的内容基本上保持不变。在这种情况下，笔者认为只要数据的更新集中在一个固定的时段，此时采用快照复制仍然是可行的。 再如上面这个KFC或者服装企业的案例中，如果市场部门维护一个产品的价格，而且这些价格往往在一个固定的时间进行几次更新。如在换季的时候会进行一些促销。此时数据库管理员可以在数据更新完毕后立即执行复制完成的数据快照。所以，以数据更新来判断是否适合采用快照复制，标准并不是数据的更新量。像上面提到的分析决策系统，其起初的数据更新量可能比有些数据库系统几年的数据更新量都要大。笔者认为，主要是根据数据更新的频率来进行判断。如果数据更新的比较频繁，那么即使数据更新的数据不多，像那种细水长流似的更新，则不适合采用快照复制。而那些井喷似的数据更新，所有的更新都集中在一个固定的时刻，那么此时采用快照复制是比较合理的。 三、在一段时间内是否允许具有相对发布服务器已过时的数据副本? 现在不少超市也已经连锁了，如世纪联华等等。为了提高利润，增加市场的份额，这些超市纷纷推出了冲值卡，即消费者先将一定金额的人民币打入到冲值卡中。然后每次消费完成后从卡中扣费。但前些天经常有新闻报道，说一个客户的消费卡在一家联华超市挂失了。但是捡到这张卡的人仍然可以在其他的联华超市中消费。为此消费者就想不明白了，为什么挂失了的消费卡仍然可以在其他超市中消费?挂失后的损失该由谁来承担呢?其实这就使超市在不适当的时候采用了快照复制所造成的。由于采用快照复制，在各个联华超市的数据库之间数据无法在短时间内取得一致。如有些商户说挂失当日之内的损失他们不承担，这就说明他们可能是每天下班后进行一次快照复制。一般情况下这不会有问题。但是像遇到消费卡被偷了等情况，就会遇到类似的问题了。 所以，在考虑是否适合采用快照复制的时候，还需要考虑在一段时间内是否允许具有相对发布服务器来说已过时的数据副本。如果不允许的话，那么就不允许采用这个快照复制。如果允许的话，那么数据库管理员就需要评估这段时间最长是多少。如果是24个小时，那么就需要每隔24小时进行一次快照复制。但是需要注意的是，如果时间的间隔比较短，如才允许十分钟的数据延迟，那么采用快照复制就没有必要了。此时采用事务复制或则和合并复制可能更加的合适。 四、复制少量的数据。 快照复制跟其他复制类型相比，还有一个比较显着的特点，即当发生数据同步时，将生成完整的快照并将其从发布服务器传送到订阅服务器。这是一个什么概念呢?如订阅服务器中有10G的数据，而在一个快照复制的周期内，只有1M的数据发生了更改。此时发生快照复制的话，数据库系统会将10G的数据都传送到订阅服务器上。此时更改的数据只有1M，却需要在网络上传送10G的数据流量，显然会对企业的网络产生比较大的压力。由于在发布服务器上快照复制的连续开销低于事务复制的开销，一次数据库系统不会启用跟踪增量更改。但是像这种情况，如果要复制的数据量非常的大，而平时的更新又不多。此时数据库系统要生成和应用快照，就将耗用大量的资源，包括网络资源和服务器资源。所以说，当发布服务器中的数据比较多时，采用快照复制不怎么合适。因为此时网络传输反而会成为其最重大的瓶颈资源。相反若能够采取细水长流的事务复制策略，那么对于企业网络性能的影响就会小的多，甚至可以忽略不计。 所以在采用快照复制的时候，数据库管理员一定要明白，快照复制会传送整个数据库对象。从而在快照复制传输过程中会侵蚀大量的网络带宽，从而明显的降低企业网络的性能，甚至导致网络拥塞。有时候为了保障快照能够准确、迅速的传递到其他的订阅服务器，还不得不采用VPN等技术来保障传输的准确性。为此，笔者认为只有发布服务器的数据库并不是很大的情况下，才适合采用快照复制。否则的话，采用快照复制是得不偿失。 从以上的分析中，可以得到一个结论。在考虑采用快照复制是否合适时，往往不能够采用一个指标来判断。而需要考虑多个因素，如数据库的大小、数据更新的频率、允许数据延迟的时间等等因素来进行判断。最后在数据的一致性与数据库的性能之间取得一个均衡。说实话，对于大部分数据库管理员来说，要做出一个抉择，确实有困难。因为这没有固定的指标可以拿来参考。如数据库容量小于多少时该采用快照复制。任何一个数据库管理专家都不能够下这个结论。所以在掌握影响其选择的相关因素外，就要依靠数据库管理员的经验了。在遇到类似的选择题时，往往经验可以帮助管理员迅速解决问题。最后需要提醒的是，无论最终采取了什么方案，最好能够持续跟踪一段时间，看看自己的选择是否合理。
㈣ SQLServerManagementStudio里面的数据库快照的定义是什么
简单地说
㈤ SQLSERVER 2008 在数据库复制时无法启动快照代理，是什么问题
试试用管理员权限打开sqlserver
㈥ sqlserver with snapshot 有什么作用
数据库快照为你现有的数据库创建了一个数据库的壳，然后无论何时当数据页被修改的时候，改变也同时被写入稀疏文件(sparse file)当中。当人们获取数据的时候，数据中没有变化的部分是从原始数据库中得到的，而改变的部分则是从稀疏文件中获得。
稀疏文件和数据库快照
当数据库快照被创建的时候，第一次的创建是十分迅速的。因为实际上只是创建了一个用来记录被修改文件的壳。随着时间的推移，文件不断的被修改，这些修改页都将被写进稀疏文件。你的主数据库中修改的文件越多，就有越多的文件被写入稀疏文件。因此，有越来越多的磁盘空间被用来保存你的主数据库和快照的数据库，也增加了你服务器的磁盘输入输出的次数。
稀疏文件被写入大小为64KB的分组块当中。每一个分组块增量能包含8个大小为8KB的数据页。所以，每次在你的主数据库中有任何的数据改变，都会先把数据页拷贝到稀疏文件当中，然后再将主数据库中文件的变化写入稀疏文件。一旦数据页被写入稀疏文件，他们就不再需要被写出来。因为页面的全部内容被保护起来，让其处于当快照建立时的状态。
为了实现优化磁盘并消除磁盘冲突，在主数据库以外的独立的驱动器和阵列中创建稀疏文件是一个明知之举。原因有二：
其一，当快照被建立的时候，没有数据被写入稀疏文件。从快照进行的所有的数据访问实际上都是在主数据库文件当中的。随着时间的推移，你会通过在不同的阵列和磁盘上从主文件数据库读取未被修改过的文件和从稀疏文件读取修改过的数据的方法来减少输入输出的负担。
其二，根据你数据库数据的易变动性和数据变化的数量，你可以通过将在主数据库的读取工作和稀疏文件的写入工作分离来减少输入输出的瓶颈大小。
使用数据库快照
在这里你一定要记住的事情就是，你的查询请求访问的依然是你的主数据库。当初始的快照被建立的时候，其实仅建立了一个空的壳子。所有的数据请求都是在主数据库文件中被完成的。随着时间的流逝和文件不断地被修改，就有一些数据请求从初始的数据库文件中分离出来指向了稀疏文件。所以，尽管看上去它是一个独立的数据库，那些根本的数据仍然是源于主数据库。
鉴于此，你需要确定不要试图去进行你日常活动范围以外的查询。这样说吧，你创建了一个快照，接着你进行了读写的操作，并对每个人做了记录。当那些记录被执行查询操作时，他们仍然继续影响着主数据库。所以你要保证任何新的活动都不会影响主数据的活动。
另外，你需要记住到底有哪些数据是被写入稀疏文件里的，而不是认为所有可能的数据都被写进了稀疏文件。基本上，当快照被创立时，主数据库的大小就是快照稀疏文件的潜在大小。如果稀疏文件中的数据量已经达到甚至超过数据库的一半时，也许再创造一个数据库的完整拷贝来取代现有的快照是一个更好的主意。
综上所述，我认为，数据库快照是一个非常新的功能。我也希望在SQL Server2005的所有版本，而不仅仅在企业版和开发版中可以应用这个功能。有一个没有讨论的地方就是我们没有讨论有关对数据库镜像使用快照。其实，无论是镜像还是原数据库，快照都给了你最好的方法。因为镜像是离线的，你并不能访问那些数据，所以说无论是镜像还是原数据库，它都给了你最好的方法。花一些时间去理解快照是如何应用于你的环境中的，并且确认你监视着维护快照的影响以及通过快照进行的数据存储。
㈦ 如何创建数据库快照
任何能创建数据库的用户都可以创建数据库快照。创建快照的唯一方式是使用 Transact-SQL。 注意：有关命名数据库快照、设置创建数据库快照的时间和限制数据库快照成员的注意事项，请参阅创建数据库快照。 创建数据库快照 根据源数据库的当前大小，确保有足够的磁盘空间存放数据库快照。数据库快照的最大大小为创建快照时源数据库的大小。 使用 AS SNAPSHOT OF 子句对文件执行 CREATE DATABASE 语句。创建快照需要指定源数据库的每个数据库文件的逻辑名称。有关创建数据库快照的语法的正式说明，请参阅 CREATE DATABASE (Transact-SQL)。 注意：创建数据库快照时，CREATE DATABASE 语句中不允许有日志文件、脱机文件、还原文件和不起作用的文件。 示例本节包含创建数据库快照的示例。 A. 对 AdventureWorks 数据库创建快照此示例对AdventureWorks 数据库创建数据库快照。快照名称 AdventureWorks_dbss_1800 及其稀疏文件的名称 AdventureWorks_data_1800.ss 指明了创建时间 6 P.M.（1800 小时）。 复制代码CREATE DATABASE AdventureWorks_dbss1800 ON( NAME = AdventureWorks_Data, FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\AdventureWorks_data_1800.ss' )AS SNAPSHOT OF AdventureWorks;GO注意：示例中随意使用了扩展名 .ss。 B. 对 Sales 数据库创建快照此示例对Sales数据库创建数据库快照 sales_snapshot1200 。
㈧ 如何利用SQL Server数据库快照形成报表
在SQL Server 2005中，它的另外一个强大的新特点是数据库快照。数据库快照是一个数据库的只读副本，它是数据库所有数据的映射，由快照被执行的时间点来决定它的内容。
这些数据库快照在报表方面是非常有价值，因为在快照数据库中或者在原数据库中，对于任何查询而言没有锁就将被执行。快照也可以使用在灾难恢复中，因为你可以将现有的数据恢复到现有的快照中，或者还可以在有害数据操作声明的事件中存储个别必要的表和数据。
数据库快照是如何工作的?
可以使用典型的数据库命令CREATE DATABASE语句来生成一个数据库快照，在声明中有一个源数据库快照的附加说明。当快照被建立时，同时生成一个稀疏文件。这个文件（只能使用在NTFS卷中）在初始化的时候并没有磁盘空间分配给它——尽管你可能在WINDOWS资源管理器中看到了文件的大小，它会看上去与原始的源数据库文件的大小相同。对磁盘来说其实这个文件的大小接近于零。
数据库快照在初始化时读的数据文件是来自于源数据库的。当源数据库的数据发生变化时，数据引擎就会将原始数据从源数据库拷贝到快照数据库中。这个技术确保快照数据库只反映快照被执行时数据的状态。当SELECT命令被用来发布反对数据库快照时，不管数据页的读取是否被定位在源数据库数据文件中还是在快照数据库数据文件中都是没有锁被发布的。因为在只读数据库快照中是没有锁被发布，数据库快照对于报表解决方案是一个重要的解决方案。
一个快照的实例
现在，让我们来看看数据库快照在SQL Server 2005中是如何工作的。为此，首先我需要一个源数据库作为快照的来源。下面的脚本将创建一个源数据库：
以下为引用的内容：
USE master
GO
IF EXISTS(SELECT name from sysdatabases where [name] = 'SourceDatabase')
DROP DATABASE SourceDatabase
GO
CREATE DATABASE SourceDatabaseON PRIMARY
(
NAME = SourceDatabase_Data,
FILENAME = 'C:SQLServerSourceDatabase_Data.mdf'
) LOG ON
(
NAME = SourceDatabase_Log,
FILENAME = 'C:SQLServerSourceDatabase_Log.ldf'
)
GO
注意这里产品区域的大小。我定义它的大小为CHAR（150）来强调数据文件的增长级数，这样在我接下来的实例中将更容易解释清楚快照是如何工作的。
现在既然我已经有了一个源数据库，现在我装载一些数据来扩展数据文件的大小位。如此，使用列表1中的脚本来创建销售历史表。
以下为引用的内容：
USE SourceDatabase
GO
IF OBJECT_ID('SalesHistory')>0 DROP TABLE SalesHistory
GO
CREATE TABLE SalesHistory
( SaleID INT IDENTITY(1,1),
Proct CHAR(150), SaleDate DATETIME,
SalePrice MONEY
)
DECLARE @i INT
SET @i = 1
WHILE (@i <=10000)
BEGIN INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('Computer', DATEADD(mm, @i, '3/11/1919'),
DATEPART(ms, GETDATE()) + (@i + 57) )
INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('BigScreen', DATEADD(mm, @i, '3/11/1927'),
DATEPART(ms, GETDATE()) + (@i + 13) )
INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('PoolTable', DATEADD(mm, @i, '3/11/1908'),
DATEPART(ms, GETDATE()) + (@i + 29) )
SET @i = @i + 1
END
GO
㈨ sqlserver snapshot快照怎么用jdbc获取
数据库快照为你现有的数据库创建了一个数据库的壳，然后无论何时当数据页被修改的时候，改变也同时被写入稀疏文件(sparse file)当中
㈩ SQLServer 数据库中如何保持数据一致性
为了在恰当的时候采用快照复制，数据库管理员首先需要知道快照复制的特点。快照复制是指将数据以特定时刻的瞬时状态转发，而不坚实对数据的更新。在发生同步时，将生成完整的快照并将其发送到订阅服务器。简单的说，快照复制就是每隔一段时间发生数据同步操作。而不是发布服务器的数据一有更新就出发这个快照复制。显然这种快照复制的数据同步性稍微差一点。在订阅服务器与发布服务器之间有一段时间会存在数据不一致的情况。但是这可以在很大程度上提高订阅服务器与发布服务器的性能。这就好像汽车运输。采用快照复制的话可以将一个集装箱装满后在送货，而不是有多少送多少。掌握这个数据库复快照复制的具体特点之后，数据库管理员就可以来考虑在什么情况下，采用快照复制更加的合理。 一、数据更改比较少的系统中。 快照复制与其他复制相比最主要的缺陷就是数据库中的数据无法及时同发布服务器一致。为此如果发布服务器中的内容很少更改的话，显然此时采用快照复制是比较合理的。此时采用快照复制的话，不仅数据一致性延迟的负面效应会越来越不明显，同时可以提高发布服务器与订阅服务器的性能。如在实际工作中，经常会遇到这样的客户。如一家企业在各地都有办事处或者销售机构，就像肯德基一样，各地的产品价格基本上都是相同的，不怎么会更改。即使更改的话，各地也是统一调整。由于此时产品价格表更改的比较少，那么在企业总部的数据库服务与各地的订阅服务器之间，采用快照复制的形式就会比较合适。其实类似的情况有很多。如不少的服装企业，像李宁、耐克等等，他们不仅自己生产，而且在各地又有自己的销售办事处。在价格方面也是统一的。在这种情况下，采用快照复制往往能够提高数据库复制的性能，同时又不影响其使用。 二、在某个时段内会出现数据大量的更改。 需要补充说明的一点是，上面说到的数据不怎么发生更改，指的是数据的延续性更改。如在一年中，每天或者每个小时更改的数据都比较平均。此时采用快照复制不怎么合适。但是如果数据的更改集中在一个时段内。而其他时间中数据库的内容不会有多大的更改。此时采用快照复制是可行的。如一些决策性系统，往往在起初导入数据的时候，需要进行大量的更改。而等到数据导入完毕，在大家对数据进行分析时，则数据库中的内容基本上保持不变。在这种情况下，笔者认为只要数据的更新集中在一个固定的时段，此时采用快照复制仍然是可行的。 再如上面这个KFC或者服装企业的案例中，如果市场部门维护一个产品的价格，而且这些价格往往在一个固定的时间进行几次更新。如在换季的时候会进行一些促销。此时数据库管理员可以在数据更新完毕后立即执行复制完成的数据快照。所以，以数据更新来判断是否适合采用快照复制，标准并不是数据的更新量。像上面提到的分析决策系统，其起初的数据更新量可能比有些数据库系统几年的数据更新量都要大。笔者认为，主要是根据数据更新的频率来进行判断。如果数据更新的比较频繁，那么即使数据更新的数据不多，像那种细水长流似的更新，则不适合采用快照复制。而那些井喷似的数据更新，所有的更新都集中在一个固定的时刻，那么此时采用快照复制是比较合理的。 三、在一段时间内是否允许具有相对发布服务器已过时的数据副本? 现在不少超市也已经连锁了，如世纪联华等等。为了提高利润，增加市场的份额，这些超市纷纷推出了冲值卡，即消费者先将一定金额的人民币打入到冲值卡中。然后每次消费完成后从卡中扣费。但前些天经常有新闻报道，说一个客户的消费卡在一家联华超市挂失了。但是捡到这张卡的人仍然可以在其他的联华超市中消费。为此消费者就想不明白了，为什么挂失了的消费卡仍然可以在其他超市中消费?挂失后的损失该由谁来承担呢?其实这就使超市在不适当的时候采用了快照复制所造成的。由于采用快照复制，在各个联华超市的数据库之间数据无法在短时间内取得一致。如有些商户说挂失当日之内的损失他们不承担，这就说明他们可能是每天下班后进行一次快照复制。一般情况下这不会有问题。但是像遇到消费卡被偷了等情况，就会遇到类似的问题了。 所以，在考虑是否适合采用快照复制的时候，还需要考虑在一段时间内是否允许具有相对发布服务器来说已过时的数据副本。如果不允许的话，那么就不允许采用这个快照复制。如果允许的话，那么数据库管理员就需要评估这段时间最长是多少。如果是24个小时，那么就需要每隔24小时进行一次快照复制。但是需要注意的是，如果时间的间隔比较短，如才允许十分钟的数据延迟，那么采用快照复制就没有必要了。此时采用事务复制或则和合并复制可能更加的合适。 四、复制少量的数据。 快照复制跟其他复制类型相比，还有一个比较显着的特点，即当发生数据同步时，将生成完整的快照并将其从发布服务器传送到订阅服务器。这是一个什么概念呢?如订阅服务器中有10G的数据，而在一个快照复制的周期内，只有1M的数据发生了更改。此时发生快照复制的话，数据库系统会将10G的数据都传送到订阅服务器上。此时更改的数据只有1M，却需要在网络上传送10G的数据流量，显然会对企业的网络产生比较大的压力。由于在发布服务器上快照复制的连续开销低于事务复制的开销，一次数据库系统不会启用跟踪增量更改。但是像这种情况，如果要复制的数据量非常的大，而平时的更新又不多。此时数据库系统要生成和应用快照，就将耗用大量的资源，包括网络资源和服务器资源。所以说，当发布服务器中的数据比较多时，采用快照复制不怎么合适。因为此时网络传输反而会成为其最重大的瓶颈资源。相反若能够采取细水长流的事务复制策略，那么对于企业网络性能的影响就会小的多，甚至可以忽略不计。 所以在采用快照复制的时候，数据库管理员一定要明白，快照复制会传送整个数据库对象。从而在快照复制传输过程中会侵蚀大量的网络带宽，从而明显的降低企业网络的性能，甚至导致网络拥塞。有时候为了保障快照能够准确、迅速的传递到其他的订阅服务器，还不得不采用VPN等技术来保障传输的准确性。为此，笔者认为只有发布服务器的数据库并不是很大的情况下，才适合采用快照复制。否则的话，采用快照复制是得不偿失。 从以上的分析中，可以得到一个结论。在考虑采用快照复制是否合适时，往往不能够采用一个指标来判断。而需要考虑多个因素，如数据库的大小、数据更新的频率、允许数据延迟的时间等等因素来进行判断。最后在数据的一致性与数据库的性能之间取得一个均衡。说实话，对于大部分数据库管理员来说，要做出一个抉择，确实有困难。因为这没有固定的指标可以拿来参考。如数据库容量小于多少时该采用快照复制。任何一个数据库管理专家都不能够下这个结论。所以在掌握影响其选择的相关因素外，就要依靠数据库管理员的经验了。在遇到类似的选择题时，往往经验可以帮助管理员迅速解决问题。最后需要提醒的是，无论最终采取了什么方案，最好能够持续跟踪一段时间，看看自己的选择是否合理。