存储快照-COW和ROW

存储快照主要解决数据丢失时的数据恢复，这种技术可以保存当前存储设备的状态，比如电脑的文件被误删除了，可以通过存储快照恢复到文件丢失之前的状态。

传统地，人们一直采用数据复制、备份、恢复等技术来保护重要的数据信息，定期对数据进行备份或复制。由于数据备份过程会影响应用性能，并且非常耗时，因此数据备份通常被安排在系统负载较轻时进行(如夜间)。另外，为了节省存储空间，通常结合全量和增量备份技术。显然，这种数据备份方式存在一个显著的不足，即数据恢复时间长、需要备份窗口。信息系统要求 247 不间断运行，一旦出现数据问题，需要依赖备份恢复时，需要做全量 + 增量的方式恢复，一般来说耗时都会很长。数据快照就是为了满足这样的需求而出现的数据保护技术。

快照的定义： 关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。从更具体的技术细节来讲，快照是指向保存在存储设备中的数据的引用标记或指针。我们可以这样理解，快照有点像是详细的数据地址目录表，但在计算机中快照被作为完整的数据备份来对待。

快照技术的作用 ：主要能够进行在线数据恢复，当存储设备发生故障或损坏时能够进行即时的数据恢复，将存储状态恢复到快照时间点的状态。另一个作用是能够为存储用户提供另外一个数据访问的通道，当源数据进行在线应用处理时，用户可以选择访问快照数据，还能够将快照应用到测试等工作。因此，所有存储系统，不论高中低端，只要应用于在线系统，那么快照就成为一个不可或缺的功能。快照在备份、数据保护过程中发挥着越来越大的作用。

快照的优势

快照的分类

COW(Copy-On-Write) ，也被称之为「即写即拷」快照技术或「写时复制」快照技术，这种方式通常也被称为“元数据(源数据指针表)”拷贝。顾名思义，如果有人试图改写源数据块上的原始数据，首先将原始数据拷贝到新数据块中，然后再进行改写。当你还原快照需要引用原始数据时，快照软件将原始数据原有的指针映射到新数据块上。

再来深入的看看 COW 的过程，COW 在创建快照时，并不会发生物理的数据拷贝动作，仅是拷贝了原始数据所在的源数据块的物理位置元数据。因此，COW 快照创建非常快，可以瞬间完成。在创建了快照之后，快照软件会监控跟踪原始数据的变化(即对源数据块的写 *** 作)，一旦源数据块中的原始数据被改写，则会将源数据块上的数据拷贝到新数据块中，然后将新数据写入到源数据块中覆盖原始数据。其中所有的源数据块就组成了所谓的源数据卷，而新数据块组成了快照卷。你应该能够看出 COW 有一个很明显的缺点，就是会降低源数据卷的写性能，因为每次改写新数据，实际上都进行了两次写 *** 作。

再再深入的看看 COW 的原理，在创建快照时，会同时创建快照卷，但只需分配相对少量的存储空间，用于保存创建快照后源数据卷中被更新的数据。每个源数据卷都具有一张数据指针表(元数据)，简称源数据指针表，表记录就是指向相应源数据块的地址指针。在创建快照时，存储子系统会建立源数据指针表的一个副本(元数据拷贝)，作为快照卷的数据指针表，简称快照数据指针表。所以，在创建快照之后，这个快照就相当于一个可供上层应用访问的存储逻辑副本，快照卷与源数据卷通过各自的指针表共享同一份物理数据。当源数据卷中任意数据将要被改写时，COW 需要确保对原始数据的拷贝 *** 作发生在原始数据的改写 *** 作之前，并且将原始数据在快照卷中的新地址更新到快照数据指针表记录中，使快照时间点后更新的数据不会出现在快照卷中，快照卷中的数据都必须是快照时间点那一刻的数据，以此保证了快照数据的完整性。

NOTE1 ：在步骤 3 中使用了「首次」一词，意思是说当源数据卷中同一位置上的数据被修改了多次也仅仅会在第一次修改时被拷贝，换句话说就是只有原始数据被更新时才会触发拷贝 *** 作，新数据被更新的数据更新并不会影响到快照数据的完整性。所以 COW 偶尔也会被表述为 COFW(Copy-On-First-Write)

NOTE2 ：源数据指针表至此至终都不会发生变化，所以 COW 对源数据卷的读 *** 作和对源数据卷中单个位置的多次写 *** 作性能都不会有很大的影响。相对的，快照卷数据是非连续的，而且在执行多次快照 *** 作之后，数据会变得非常离散，所以快照卷数据的读写延时较大。

应用场景 ：这种实现方式在第一次写入某个存储位置时需要完成一个读 *** 作（读原位置的数据），两个写 *** 作（写原位置与写快照空间），如果写入频繁，那么这种方式将非常消耗IO时间。因此可推断，如果预计某个卷上的I/O多数以读 *** 作为主，写 *** 作较少的场景，这种方式的快照实现技术是一个较理想的选择，因为快照的完成需要较少的时间。除此之外，如果一个应用易出现写入热点，即只针对某个有限范围内的数据进行写 *** 作，那么COW的快照实现方式也是较较理想的选择。因为其数据更改都局限在一个范围内，对同一份数据的多次写 *** 作只会出现一次写时复制 *** 作。但是这种方式的缺点也是非常明显的。如果写 *** 作过于分散且频繁，那么 COW造成的开销则是不可忽略的，有时甚至是无法接受的。因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。

在了解了 COW 的实现原理之后再回头对比一下 COW 与备份之间的区别，COW 技术在创建快照前，并不会占用任何的存储资源，也不会影响系统性能。而且 COW 在使用上非常灵活，能够在任意时间点为任意数据卷创建快照。在快照时间点产生的“备份窗口”的长度与源数据卷的容量成线性比例，一般为几秒钟，对应用影响甚微，并且为快照卷分配的存储空间也大大的减少。拷贝的 *** 作只在源数据卷发生更新时才被触发，因此系统开销很小。但是由于快照卷仅保存了源数据卷被更新的数据，因此快照技术并不能够得到数据的完整物理副本。

ROW(Redirect-On-Write)，也被称之为写时重定向。ROW 的实现原理与 COW 非常相似，区别在于「ROW 对原始数据卷的首次写 *** 作，会将新数据重定向到预留的快照卷中」，而非 COW 一般会使用新数据将原始数据覆盖。所以，ROW 快照中的原始数据依旧保留在源数据卷中，并且为了保证快照数据的完整性，在创建快照时，源数据卷状态会由读写变成只读的。如果对一个虚拟机做了多次快照，就产生了一个快照链，虚拟机的磁盘卷始终挂载在快照链的最末端，即虚拟机的写 *** 作全都会落盘到最末端的快照卷中。该特征导致了一个问题，就是如果一共做了 10 次快照，那么在恢复到最新的快照点时，则需要通过合并 10 个快照卷来得到一个完整的最新快照点数据；如果是恢复到第 8 次快找时间点，那么就需要将前 8 次的快照卷合并成为一个完整的快照点数据。从这里可以看出 ROW 的主要缺点是没有一个完整的快照卷，其快照之间的关系是链式的，如果快照层级越多，进行快照恢复时的系统开销会比较大。但 ROW 的优势在于其解决了 COW 快照写两次的问题，所以就写性能而言，ROW 无疑是优于 COW 的。

再深入的来看看 ROW 的原理，创建快照时，ROW 也会 Copy 一份源数据指针表作为快照数据指针表，此时两张表的指针记录都相同的。在创建快照之后，也就是在快照时间点之后，发生了写 *** 作，那么新数据会直接被写入到快照卷中，然后再更新源数据指针表的记录，使其指向新数据所在的快照卷地址。可以看出，ROW 与 COW 最大的不同就是： COW 的快照卷存放的是原始数据，而 ROW 的快照卷存放的是新数据 。因为 ROW 这种设定，所以其多个快照之间的关系必定是链式的，因为最新一次快照的原始数据很可能就存放在了上一次快照时创建的快照卷中。

值得注意的是：ROW 在传统存储场景下最大的问题是对读性能影响比较大。的确，ROW 的写性能基本没有损耗，只是修改指针，实现效率很高。但多次读写 *** 作后，某时刻的源数据卷的数据会变得非常离散(源数据指针表记录都被更新了)，这是 ROW 的连续读写性能就不如 COW 了。所以，ROW 更适合应用到 Write-Intensive(写密集型)的存储系统中。但是，但是，但是，在分布式存储的情况下，ROW 的连续读写的性能却会比 COW 更高。传统存储场景中读写性能的瓶颈一般是在磁盘上，但这种瓶颈在分布式存储场景中是不存在的。用户在业务层看到连续存储，实际上是分布在不同的服务器的不同硬盘中，数据越是分散，系统性能越高。而 ROW 把源数据卷中的原始数据打散之后，对性能反而有好处。所以现阶段而言，ROW + 分布式存储的快照方式是业界发展的主要方向。

任何能创建数据库的用户都可以创建数据库快照。创建快照的唯一方式是使用 Transact-SQL。注意：有关命名数据库快照、设置创建数据库快照的时间和限制数据库快照成员的注意事项，请参阅创建数据库快照。创建数据库快照根据源数据库的当前大小，确保有足够的磁盘空间存放数据库快照。数据库快照的最大大小为创建快照时源数据库的大小。使用 AS SNAPSHOT OF 子句对文件执行 CREATE DATABASE 语句。创建快照需要指定源数据库的每个数据库文件的逻辑名称。有关创建数据库快照的语法的正式说明，请参阅 CREATE DATABASE (Transact-SQL)。注意：创建数据库快照时，CREATE DATABASE 语句中不允许有日志文件、脱机文件、还原文件和不起作用的文件。示例本节包含创建数据库快照的示例。A 对 AdventureWorks 数据库创建快照此示例对AdventureWorks数据库创建数据库快照。快照名称AdventureWorks_dbss_1800及其稀疏文件的名称AdventureWorks_data_1800ss指明了创建时间 6 PM（1800 小时）。复制代码CREATE DATABASE AdventureWorks_dbss1800 ON( NAME = AdventureWorks_Data, FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10MSSQLSERVER\MSSQL\Data\AdventureWorks_data_1800ss' )AS SNAPSHOT OF AdventureWorks;GO注意：示例中随意使用了扩展名 ss。B 对 Sales 数据库创建快照此示例对Sales数据库创建数据库快照sales_snapshot1200。

快照读 即： snapshot read ，官方叫法是： Consistent Nonlocking Reads ，即： 一致性非锁定读 ，官方的解释是：

即：

即 快照读 的问题在于：在同一个事务中，能够读取到之前提交的数据。表现为：

字面意思：在事务中，为查询创建的快照，并不适用与 DML 语句。

也就是说：如果事务 A 开始时创建的快照，查询不到数据 col1=1 ，但此时事务 B 刚刚提交 insert col1=1 和 insert col1=1 ，此时如果事务 A 执行， delete col1=1 ，是能将事务 B 生成的数据删除的。

字面意思：即使事务 A 的快照是在事务 B 提交之前创建的，但事务 A 也只有在事务 A 和事务 B 都提交后，才能看到事务 B 新增的数据。

SQLServer数据库的快照只能通过SQL语句创建，以msdb数据库为例进行说明：

1、执行以下代码，看看MSDB数据库有多少数据文件

EXEC SP_HELPDB msdb

2、为每一个数据文件创建快照，代码如下：

create database snap_MSDBData_1811221202

ON ( NAME = MSDBData, FILENAME= 'D:\userdata\temp\Snap_MSDBDatasnap')

AS SNAPSHOT OF MSDB

3、在“数据库快照”那里就可以看到刚刚创建snap_MSDBData_1811221202这个快照了，对比一下快照和原库，内容是一样的

4、数据库快照其实也是一个数据库，可以在上面执行任何SQL语句，我们执行一个查询语句看看效果

SELECT   FROM [MSDB][dbo][MSdbms]

SELECT   FROM [snap_MSDBData_1811221202][dbo][MSdbms]

查询结果是完全一样的。

（如有帮助，请采纳，谢谢）

数据库快照为你现有的数据库创建了一个数据库的壳，然后无论何时当数据页被修改的时候，改变也同时被写入稀疏文件(sparse file)当中。当人们获取数据的时候，数据中没有变化的部分是从原始数据库中得到的，而改变的部分则是从稀疏文件中获得。

稀疏文件和数据库快照

当数据库快照被创建的时候，第一次的创建是十分迅速的。因为实际上只是创建了一个用来记录被修改文件的壳。随着时间的推移，文件不断的被修改，这些修改页都将被写进稀疏文件。你的主数据库中修改的文件越多，就有越多的文件被写入稀疏文件。因此，有越来越多的磁盘空间被用来保存你的主数据库和快照的数据库，也增加了你服务器的磁盘输入输出的次数。

稀疏文件被写入大小为64KB的分组块当中。每一个分组块增量能包含8个大小为8KB的数据页。所以，每次在你的主数据库中有任何的数据改变，都会先把数据页拷贝到稀疏文件当中，然后再将主数据库中文件的变化写入稀疏文件。一旦数据页被写入稀疏文件，他们就不再需要被写出来。因为页面的全部内容被保护起来，让其处于当快照建立时的状态。

为了实现优化磁盘并消除磁盘冲突，在主数据库以外的独立的驱动器和阵列中创建稀疏文件是一个明知之举。原因有二：

其一，当快照被建立的时候，没有数据被写入稀疏文件。从快照进行的所有的数据访问实际上都是在主数据库文件当中的。随着时间的推移，你会通过在不同的阵列和磁盘上从主文件数据库读取未被修改过的文件和从稀疏文件读取修改过的数据的方法来减少输入输出的负担。

其二，根据你数据库数据的易变动性和数据变化的数量，你可以通过将在主数据库的读取工作和稀疏文件的写入工作分离来减少输入输出的瓶颈大小。

使用数据库快照

在这里你一定要记住的事情就是，你的查询请求访问的依然是你的主数据库。当初始的快照被建立的时候，其实仅建立了一个空的壳子。所有的数据请求都是在主数据库文件中被完成的。随着时间的流逝和文件不断地被修改，就有一些数据请求从初始的数据库文件中分离出来指向了稀疏文件。所以，尽管看上去它是一个独立的数据库，那些根本的数据仍然是源于主数据库。

鉴于此，你需要确定不要试图去进行你日常活动范围以外的查询。这样说吧，你创建了一个快照，接着你进行了读写的 *** 作，并对每个人做了记录。当那些记录被执行查询 *** 作时，他们仍然继续影响着主数据库。所以你要保证任何新的活动都不会影响主数据的活动。

另外，你需要记住到底有哪些数据是被写入稀疏文件里的，而不是认为所有可能的数据都被写进了稀疏文件。基本上，当快照被创立时，主数据库的大小就是快照稀疏文件的潜在大小。如果稀疏文件中的数据量已经达到甚至超过数据库的一半时，也许再创造一个数据库的完整拷贝来取代现有的快照是一个更好的主意。

综上所述，我认为，数据库快照是一个非常新的功能。我也希望在SQL Server2005的所有版本，而不仅仅在企业版和开发版中可以应用这个功能。有一个没有讨论的地方就是我们没有讨论有关对数据库镜像使用快照。其实，无论是镜像还是原数据库，快照都给了你最好的方法。因为镜像是离线的，你并不能访问那些数据，所以说无论是镜像还是原数据库，它都给了你最好的方法。花一些时间去理解快照是如何应用于你的环境中的，并且确认你监视着维护快照的影响以及通过快照进行的数据存储。

与源数据库相比，快照存在以下限制：

1、快照是数据库的只读副本，不能进行修改 *** 作。

2、快照仅包含创建快照时的数据库内容，不包含后续的增量数据。

3、快照不能直接作为生产环境的数据库，只能用于读取和查询数据。

数据库是指一种可以组织、存储、管理和查询数据的软件系统。

快照复制就是在某一时刻对出版数据进行一次“照相”，生成一个描述出版数据库中数据瞬时状态的静态文件，最后在规定时间将其复制到订购者数据库。快照复制并不像事务复制那样要不断地监视、跟踪在出版数据库中发生的数据变化，它所复制的内容不是 INSERT、 UPDATE、 DELETE 语句（事务复制的特征），也不是仅限于那些被修改数据（合并复制的特征）。它实际上是对订购数据库进行一次阶段性的表刷新，把所有出版数据库中的数据从源数据库送至目标数据库，而不仅仅是那些发生了变化的数据。如果论文很大，那么要复制的数据就很多，因此对网络资源需求较高，不仅要有较快的传输速度，而且要保证传输的可靠性。

快照复制是最为简单的一种复制类型，能够在出版者和订购者之间保证事务的潜在一致性。快照复制通常使用在以下场合：不需要实时数据时，如在进行决策支持、查询静态表信息时；只读订购者（订购者不对出版数据进行修改），并且不需要最近的数据；使用立即更新订购者时对数据库的修改次数和数据量较少。

快照复制的执行仅需要快照代理和分发代理。快照代理准备快照文件（包括出版表的数据文件和描述文件）并将其存储在分发者的快照文件夹中，除此之外快照代理还要在分发者的分发数据库中跟踪同步作业。分发代理将在分发数据库中的快照作业分发至订购者服务器的目的表中。分发数据库仅用于复制而不包括任何用户表。

每一次快照代理执行时，都要创建将被分发至订购者的数据文件和描述文件（也称为同步集合）。

镜像就是镜中的影像，是一模一样的意思，系统镜像也就是克隆系统

百度更新快照之前的快照都是删掉了，快照回档是指百度的快照被退回到之前日期的快照。做seo的比较看重百度快照更新频率，因为百度快照在一定程度上反映了网站的权重，但不是绝对的。很多站长常常遇到这种情况，一段时间网站快照更新正常，但是，过一段时间网站快照就会停止，有些会出现回档的情况，不在进行更新。快照回档的原因如下[1]：

主机空间不稳定

主机空间不稳定很有可能造成百度快照回档，但不是绝对的。为什么呢因为一个权重高的网站，即使有几天出现空间打不开，或者不稳定，快照仍然可以每天更新。但是对于权重相对低些的网站，出现空间不稳定，很容易出现快照回档。这是为什么呢因为空间不稳定，有时打不开，蜘蛛不能正常去抓取，快照就会回档到之前空间稳定期间的一个快照。另一个原因是服务器的时间修改了，也会造成快照回档。

网站首页的改动

修改网站首页的标题是很多seo新手常犯的一个错误。对网站首页做了较大的调整，网站上线前没有好好的去拟定网站标题，网站上线后修改标题，刚上线几天的修改标题问题不大，要是网站上线有一段时间了，再去修改标题，这样很容易出现百度快照回档，如果经常去更改标题，很容易出现网站被k的情况。

友链链接

百度站长帮助有明文说到，如果你的网站导向了不好的站点，你是要负连带责任的，网站要是链向了不健康网站，那么被百度惩罚是难免的。快照回档的情况也时有出现。此外，若是外部的友情链接被删除，可也能造成回档现象的发生。所以如果你的网站出现快照回档或者降权的情况时，一定要及时的检查你的友情连接站点。

百度算法的调整

还有一种回档就是搜索内部算法出现重大调整的时候出现回档现象。而“快照回档”圈定的对象到底怎么确定呢一是短期给予过高权重、收录过快的站点，容易被波及回档区域;二是长期没有获得很高权重，收录几乎不更新的，容易被波及回档区域。在这个时期，我们要做的工作其实很简单，不要理会搜索，自己正常的进行站点维护，添加新内容，尤其是原创性内容，让搜索蜘蛛兴奋起来。

总结：出现百度快照回档有时可能不是一种原因造成的，也有可能是多个原因造成的。要避免被“快照回档”，最要紧的还是做好自己。很多比较年长的站长都明白，经历过两三次“快照回档”的站点，只要过程都是稳定更新，最后都能成功走出“快照回档”的迷局。不要慌，不要乱，就是做站的真谛。

优化过度造成快照回档

关键词堆积，关键词过度优化，其中最主要的原因是友情链接和外链，友情链接不当，如果和降权的网站交换友情链接，而且你的站权重又不高，或者是新站，那么很可能被降权，快照回档。短时间内大量增加外链，引起百度主要也是非常常见的，引起快照回档。内容更新没有规律，短时间内大量更新，长时间不更新，更新内容转载过度，都会引起快照回档。

以上就是关于存储快照-COW和ROW全部的内容，包括:存储快照-COW和ROW、如何创建数据库快照、MySQL之快照读等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！