服务器存储快照
服务器存储快照技术是关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。
快照的作用主要是能够进行在线数据备份与恢复。当存储设备发生应用故障或者文件损坏时可以进行快速的数据恢复，将数据恢复某个可用的时间点的状态。快照的另一个作用是为存储用户提供了另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。
所有存储系统，不论高中低端，只要应用于在线系统，那么快照就成为一个不可或缺的功能。
快照的实现方式：当前实现快照有主要有两种技术，一种是第一次写时复制(Copy OnFirst Write,COFW)，有时简称为写时复制（CopyOn Write,COW）。即在数据第一次写入到某个存储位置时，首先将原有的内容读取出来，写到另一位置处（为快照保留的存储空间，此文中我们称为快照空间），然后再将数据写入到存储设备中。而下次针对这一位置的写操作将不再执行写时复制操作。这种技术常在计算机相关的技术中经常初使用，其基本原理大同小异，只是面向的对象不同，适用的场合不一样。从COW 的执行过程我们可以知道，这种实现方式在第一次写入某个存储位置时需要完成一个读操作（读原位置的数据），两个写操作（写原位置与写快照空间），如果写入频繁，那么这种方式将非常消耗IO时间。因此可推断，如果预计某个卷上的I/O多数以读操作为主，写操作较少，这种方式的快照实现技术是一个较理想的选择，因为快照的完成需要较少的时间。除此之外，如果一个应用易出现写入热点，即只针对某个有限范围内的数据进行写操作，那么COW的快照实现方式也是较较理想的选择。因为其数据更改都局限在一个范围内，对同一份数据的多次写操作只会出现一次写时复制操作。但是这种方式的缺点也是非常明显的。如果写操作过于分散且频繁，那么 COW造成的开销则是不可忽略的，有时甚至是无法接受的。因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。
快照实现技术中的另一种技术是 I/O 重定向（I/O Redirect）。即将读写操作重新定向到另一个存储空间中。在一个快照生成期间，所有的写操作将被重定向到另一个介质，而读操作是否需要读重定向，则需要根据读取的位置是否有过自上次快照以来的写重定向，必须对有过写重定向的位置进行读重定向，否则不需要进行读定向。当要创建一个快照时，则将自上次快照以来所有的重定向写数据所对应在源介质中的数据复制出来生成这个时间点的快照，然后再将这些重定向写数据写回到源介质中的相应位置上，从而完成一个快照生成过程。从上面的过程来看，关键的性能影响在于快照生成时的四次I/O操作（一次读源介质，一次写快照数据，一次读快照介质，一次写源介质），另一个则是重定向的计算工作。这种方式虽然看起来最后生成快照时的I/O操作较多，但是考虑到这个操作是在生成快照时才会发生，特别是快照生成时可以对I/O操作进行排序，可以使得对介质的读写得到较好的优化，因此使影响很小。而对于重定向的计算操作对于当下的计算能力来说，不会成为一个性能的瓶颈问题。因此这种快照实现方式在非快照执行期间的影响甚小。因此这种方式比较适合Write-Intensive（写密集）类型的存储系统。
SNIA 将快照的实现方式表述为：镜像分离(split mirror)、改变块(changed block)、并发(concurrent)三大类。后两种在实现时其实质就是写时复制及I/O重定向。对于 split mirror的方式，由于其灵活性以及开销问题，在实际的存储系统中，并不实用。
快照的实现层次计算机的存储结构是一个类似于 TCP/IP 一样的栈结构。栈中包括硬件与软件部分。栈中不同层为上层提供服务，同时利用下层的接口。因此在实现上，快照可以在不同的栈层上实现。但是不同的层其效果及特点是不一样的。一般来说，在应用层不太合适实现快照功能。因为不同的应用是千差万别的，因此需要针对不同的应用实现快照功能，这个代价也太高了。但在应用层实现快照也并不是说一无用处，如在应用层实现快照的一个典型的例子就是 vmWare 虚拟化软件中的快照功能。只是这种快照功能应用在存储系统中不现实。
其次在文件系统层实现快照与应用也是具有同样的缺点，就是需要针对不同的文件系统实现快照功能，这样的代价也很大。实现的快照的功能的文件系统基本上都是一些专用系统为者专为某个特定功能实现的文件系统。在这个层级上实现快照，缺乏灵活性和可扩展性。这个比较典型的例子就是ZFS。而较为适宜实现快照功能的层应该为卷管理层以及物理层。在这两个层中都不与特定的应用及文件系统相关。这里比较典型的例子有Linux 的LVM。而在硬件层次上实现快照又通常有许多种，在这个层次上实现的快照一般为专用系统，好处是性能是各个方式中最好的。但是在这个层次上实现的快照也有一个不可避免的缺点，那就是由于不与特定的应用及文件系统关联，因此其就无法理解上层的应用逻辑，也就无法保证每个快照都处于数据一致性状态的。但是这个缺点是可以通过其他的方式减少或者解决的，比如在生成快照之前先对数据进行刷新操作，或者在恢复快照时对文件系统进行一致性检查等。结束语计算技术不断在进步，存储技术同样也在进行着日新月异的变化。不同的应用在不断地更新着对存储的需求。同时对于数据重要性的体现，各种容灾技术也给用户的数据加上了防护安全帽。
数据库快照
数据库快照是数据库（称为“源数据库”）的只读静态视图。在创建时，每个数据库快照在事务上都与源数据库一致。在创建数据库快照时，源数据库通常会有打开的事务。在快照可以使用之前，打开的事务会回滚以使数据库快照在事务上取得一致。客户端可以查询数据库快照，这对于基于创建快照时的数据编写报表是很有用的。而且，如果以后源数据库损坏了，便可以将源数据库恢复到它在创建快照时的状态。
复制是SQLServer数据库中保持数据一致性的一种手段。根据实现策略的不同，主要有快照复制、事务复制、合并复制等三种类型。这三种复制类型，各有各的特点，分别适用于不同的场合。一般来说，在考虑采用哪种复制类型比较合适的时候，主要考虑的是性能与数据同步的时间间隔。那么在什么情形下比较适用快照复制呢?笔者就跟大家来讨论一下这个话题。
为了在恰当的时候采用快照复制，数据库管理员首先需要知道快照复制的特点。快照复制是指将数据以特定时刻的瞬时状态转发，而不坚实对数据的更新。在发生同步时，将生成完整的快照并将其发送到订阅服务器。简单的说，快照复制就是每隔一段时间发生数据同步操作。而不是发布服务器的数据一有更新就出发这个快照复制。显然这种快照复制的数据同步性稍微差一点。在订阅服务器与发布服务器之间有一段时间会存在数据不一致的情况。但是这可以在很大程度上提高订阅服务器与发布服务器的性能。这就好像汽车运输。采用快照复制的话可以将一个集装箱装满后在送货，而不是有多少送多少。掌握这个数据库复快照复制的具体特点之后，数据库管理员就可以来考虑在什么情况下，采用快照复制更加的合理。
一、数据更改比较少的系统中。
快照复制与其他复制相比最主要的缺陷就是数据库中的数据无法及时同发布服务器一致。为此如果发布服务器中的内容很少更改的话，显然此时采用快照复制是比较合理的。此时采用快照复制的话，不仅数据一致性延迟的负面效应会越来越不明显，同时可以提高发布服务器与订阅服务器的性能。如在实际工作中，经常会遇到这样的客户。如一家企业在各地都有办事处或者销售机构，就像肯德基一样，各地的产品价格基本上都是相同的，不怎么会更改。即使更改的话，各地也是统一调整。由于此时产品价格表更改的比较少，那么在企业总部的数据库服务与各地的订阅服务器之间，采用快照复制的形式就会比较合适。其实类似的情况有很多。如不少的服装企业，像李宁、耐克等等，他们不仅自己生产，而且在各地又有自己的销售办事处。在价格方面也是统一的。在这种情况下，采用快照复制往往能够提高数据库复制的性能，同时又不影响其使用。
二、在某个时段内会出现数据大量的更改。
需要补充说明的一点是，上面说到的数据不怎么发生更改，指的是数据的延续性更改。如在一年中，每天或者每个小时更改的数据都比较平均。此时采用快照复制不怎么合适。但是如果数据的更改集中在一个时段内。而其他时间中数据库的内容不会有多大的更改。此时采用快照复制是可行的。如一些决策性系统，往往在起初导入数据的时候，需要进行大量的更改。而等到数据导入完毕，在大家对数据进行分析时，则数据库中的内容基本上保持不变。在这种情况下，笔者认为只要数据的更新集中在一个固定的时段，此时采用快照复制仍然是可行的。
再如上面这个KFC或者服装企业的案例中，如果市场部门维护一个产品的价格，而且这些价格往往在一个固定的时间进行几次更新。如在换季的时候会进行一些促销。此时数据库管理员可以在数据更新完毕后立即执行复制完成的数据快照。所以，以数据更新来判断是否适合采用快照复制，标准并不是数据的更新量。像上面提到的分析决策系统，其起初的数据更新量可能比有些数据库系统几年的数据更新量都要大。笔者认为，主要是根据数据更新的频率来进行判断。如果数据更新的比较频繁，那么即使数据更新的数据不多，像那种细水长流似的更新，则不适合采用快照复制。而那些井喷似的数据更新，所有的更新都集中在一个固定的时刻，那么此时采用快照复制是比较合理的。
三、在一段时间内是否允许具有相对发布服务器已过时的数据副本?
现在不少超市也已经连锁了，如世纪联华等等。为了提高利润，增加市场的份额，这些超市纷纷推出了冲值卡，即消费者先将一定金额的人民币打入到冲值卡中。然后每次消费完成后从卡中扣费。但前些天经常有新闻报道，说一个客户的消费卡在一家联华超市挂失了。但是捡到这张卡的人仍然可以在其他的联华超市中消费。为此消费者就想不明白了，为什么挂失了的消费卡仍然可以在其他超市中消费?挂失后的损失该由谁来承担呢?其实这就使超市在不适当的时候采用了快照复制所造成的。由于采用快照复制，在各个联华超市的数据库之间数据无法在短时间内取得一致。如有些商户说挂失当日之内的损失他们不承担，这就说明他们可能是每天下班后进行一次快照复制。一般情况下这不会有问题。但是像遇到消费卡被偷了等情况，就会遇到类似的问题了。
所以，在考虑是否适合采用快照复制的时候，还需要考虑在一段时间内是否允许具有相对发布服务器来说已过时的数据副本。如果不允许的话，那么就不允许采用这个快照复制。如果允许的话，那么数据库管理员就需要评估这段时间最长是多少。如果是24个小时，那么就需要每隔24小时进行一次快照复制。但是需要注意的是，如果时间的间隔比较短，如才允许十分钟的数据延迟，那么采用快照复制就没有必要了。此时采用事务复制或则和合并复制可能更加的合适。
四、复制少量的数据。
快照复制跟其他复制类型相比，还有一个比较显著的特点，即当发生数据同步时，将生成完整的快照并将其从发布服务器传送到订阅服务器。这是一个什么概念呢?如订阅服务器中有10G的数据，而在一个快照复制的周期内，只有1M的数据发生了更改。此时发生快照复制的话，数据库系统会将10G的数据都传送到订阅服务器上。此时更改的数据只有1M，却需要在网络上传送10G的数据流量，显然会对企业的网络产生比较大的压力。由于在发布服务器上快照复制的连续开销低于事务复制的开销，一次数据库系统不会启用跟踪增量更改。但是像这种情况，如果要复制的数据量非常的大，而平时的更新又不多。此时数据库系统要生成和应用快照，就将耗用大量的资源，包括网络资源和服务器资源。所以说，当发布服务器中的数据比较多时，采用快照复制不怎么合适。因为此时网络传输反而会成为其最重大的瓶颈资源。相反若能够采取细水长流的事务复制策略，那么对于企业网络性能的影响就会小的多，甚至可以忽略不计。
所以在采用快照复制的时候，数据库管理员一定要明白，快照复制会传送整个数据库对象。从而在快照复制传输过程中会侵蚀大量的网络带宽，从而明显的降低企业网络的性能，甚至导致网络拥塞。有时候为了保障快照能够准确、迅速的传递到其他的订阅服务器，还不得不采用VPN等技术来保障传输的准确性。为此，笔者认为只有发布服务器的数据库并不是很大的情况下，才适合采用快照复制。否则的话，采用快照复制是得不偿失。
从以上的分析中，可以得到一个结论。在考虑采用快照复制是否合适时，往往不能够采用一个指标来判断。而需要考虑多个因素，如数据库的大小、数据更新的频率、允许数据延迟的时间等等因素来进行判断。最后在数据的一致性与数据库的性能之间取得一个均衡。说实话，对于大部分数据库管理员来说，要做出一个抉择，确实有困难。因为这没有固定的指标可以拿来参考。如数据库容量小于多少时该采用快照复制。任何一个数据库管理专家都不能够下这个结论。所以在掌握影响其选择的相关因素外，就要依靠数据库管理员的经验了。在遇到类似的选择题时，往往经验可以帮助管理员迅速解决问题。最后需要提醒的是，无论最终采取了什么方案，最好能够持续跟踪一段时间，看看自己的选择是否合理。
创建Oracle数据库快照
创建快照需要使用数据库链.
一．首先创建数据库链：
A.在init<sid>.ora文件的global_name参数为false的情况下：
创建数据库链用命令：
1．create database link link_name connect to user_name identified by user_passwd using alias_name
例: create database link test connect to scott identified by tiger using ‘ccc’
注:link_name为数据库链名,此处为test
user_name为所连接的数据库的用户名
user_passwd为所连接的数据库的密码
alias_name在数据库所在的机器上为被连接的数据库起的一个别名，在tnsnames.ora中
建完数据库链后,在sql*plus中用此数据库链连接远程数据库用法如下:
create table emp as select * from emp@test
或
create table emp as select * from emp@test
这样将创建一个和原数据库一样的表。如果能创建出一样的表，表明数据库链可以正常工作。
B.在init<sid>.ora文件的global_name参数为true的情况下：
因为参数为true，要使用oracle的域名服务，所以要先看一下数据库的全局域名是否正确。查看语句如下：
在被连接的数据库服务器上做：
1．select * from global_name;
如果域名不正确，则修改域名：
2．alter database rename global_name to test.xyj.com.cn;
注意：此语句是在被连接的服务器上执行，即A服务器连接到B服务器上，则此语句在B服务器上执行。xyj.com.cn为sqlnet.ora文件中的names.default_domain字段的值.如
names.default_domain=xyj.com.cn
在连接的数据库服务器上做：
创建数据库链用命令：
3．create database link link_name.domain connect to user_name identified by user_passwd using alias_name
例: create database link test.xyj.com.cn connect to scott identified by tiger using ‘ccc’
注:link_name为数据库链名,此处为test
user_name为所连接的数据库的用户名
user_passwd为所连接的数据库的密码
domain为sqlnet.ora文件中的names.default_domain字段的值.如
names.default_domain=xyj.com.cn则domain为xyj.com.cn
alias_name在数据库所在的机器上为被连接的数据库起的一个别名，在tnsnames.ora中
建完数据库链后,在sql*plus中用此数据库链连接远程数据库用法如下:
create table emp as select * from emp@test.xyj.com.cn
这样将创建一个和原数据库一样的表。如果能创建出一样的表，表明数据库链可以正常工作。
二．其次编写一个快照
如：
从test数据库链连接的数据库中得到dc_admin_area表的一个快照dsnp_area，快照每天11点刷新。在应用中查询dsnp_area与查询dc_admin_area@test的效果是一样的.
创建快照语法：
create snapshot dsnp_area refresh fast start with sysdate next trunc(sysdate)+35/24
as select * from dc_admin_area@test;
-
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载,整理或搜集自网络.欢迎任何形式的转载，转载请注明出处.
转载请注明：文章转载自:[169IT-IT技术资讯]
本文标题:服务器存储快照和数据库快照详解
