Hyper-V虚拟机快照占用磁盘空间过多，导致虚拟机不能启动怎么办

通常，为了捕获虚拟机某个时刻的状态和数据，我们会执行快照 *** 作。但是存储快照

的.avhd文件会占用大量的存储空间。因此，我们有时需要在Hype-V管理器中手动删除一些快照，

以节省磁盘空间.

虚拟机快照磁盘空间问题，可以根据程度不同分为以下集中情况:

虚拟机仍有很多磁盘空间未使用，虚拟机可以正常运行，手动删除快照以便释放磁盘空间

虚拟机磁盘空间严重不足，虚拟机自动暂停，虚拟机手动不能正常启动

第一种情况比较简单，也最容易 *** 作:

1. 打开Hyper-v管理器，选中要维护的虚拟机，在快照树中删除不在使用的快照；

2. 关闭虚拟机.虚拟机会自动开始合并磁盘空间，同时会显示合并进度。直至合并100%完成，

磁盘空间成功释放，这时就可以重新启动虚拟机了.

合并磁盘并释放磁盘空间的前提是：你得虚拟机所在磁盘仍有足够的磁盘空间来进行磁盘合并，

否则不能执行正常合并。也就是第二种情况.

第二种情况:

这时候磁盘空间严重不足，已经不能通过停机使磁盘合并来释放磁盘空间了。这时可以使用虚拟机

导出导入功能。这里详细介绍执行过程.

任何能创建数据库的用户都可以创建数据库快照。创建快照的唯一方式是使用 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 AdventureWorksGO注意：示例中随意使用了扩展名 .ss。B. 对 Sales 数据库创建快照此示例对Sales数据库创建数据库快照sales_snapshot1200。

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

稀疏文件和数据库快照

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

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

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

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

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

使用数据库快照

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

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

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

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

---