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

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

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

　　使用数据库快照

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

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

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

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