Question

谁能给我翻译一下这篇文章？谢谢！着急啊！翻译出来额外给奖励！

How Database Snapshots Work
A database snapshot provides a read-only, static view of a source database as it existed at snapshot creation, minus any uncommitted transactions. Uncommitted transactions are rolled back in a newly created database snapshot because the Database Engine runs recovery after the snapshot has been created (transactions in the database are not affected).
Database snapshots are dependent on the source database. The snapshots of a database must be on the same server instance as the database. Furthermore, if that database becomes unavailable for any reason, all of its database snapshots also become unavailable.
Snapshots can be used for reporting purposes. Also, in the event of a user error on a source database, you can revert the source database to the state it was in when the snapshot was created. Data loss is confined to updates to the database since the snapshot's creation.
Understanding how snapshots work is helpful though not essential to using them. Database snapshots operate at the data-page level. Before a page of the source database is modified for the first time, the original page is copied from the source database to the snapshot. This process is called a copy-on-write operation. The snapshot stores the original page, preserving the data records as they existed when the snapshot was created. Subsequent updates to records in a modified page do not affect the contents of the snapshot. The same process is repeated for every page that is being modified for the first time. In this way, the snapshot preserves the original pages for all data records that have ever been modified since the snapshot was taken.
To store the copied original pages, the snapshot uses one or more sparse files. Initially, a sparse file is an essentially empty file that contains no user data and has not yet been allocated disk space for user data. As more and more pages are updated in the source database, the size of the file grows. When a snapshot is taken, the sparse file takes up little disk space. As the database is updated over time, however, a sparse file can grow into a very large file.
The following figure illustrates a copy-on-write operation. The light gray rectangles in the snapshot diagram represent potential space in a sparse file that is as-yet unallocated. On receiving the first update to a page in the source database, the Database Engine writes to the file and the operating system allocates space in the snapshot's sparse files and copies the original page there. The Database Engine then updates the page in the source database. The following figure illustrates such a copy-on-write operation.

Answer 1

如何数据库快照的工作
数据库快照提供了一个唯读，静止观的一个源数据库，因为它存在于快照的创造，减去任何未交易。未提交的事务回滚在一个新建的数据库快照，因为数据库引擎的运行复苏后的快照已创建（交易在数据库中不会受到影响） 。
数据库快照是依赖于源数据库。该快照一个数据库，必须在同一台服务器上，例如作为数据库。此外，如果该数据库变得不可用任何理由，它的所有数据库的快照也成为不可用。
快照可用于报告的目的。此外，在活动的用户错误的来源数据库，您可以回复源数据库到时的状态的快照，已创建。数据丢失是限于更新到数据库快照以来的创作。
了解如何快照的工作是有益的，虽然没有必要使用它们。数据库快照操作在数据页的水平。前一个网页的源数据库是改装的第一时间，原来的网页是复制，从源头上数据库的快照。这个过程是所谓的副本-对-写操作。快照店原始网页，保存的数据记录，因为他们存在时，快照已创建。随后的更新记录，在修改网页，不影响内容的快照。相同的过程是重复的每一页，就是被修改为第一次。这样一来，快照保留原始页面的所有数据记录都被修改以来，采取了快照。
存储复制的原始网页，快照使用一个或多个稀疏文件。最初，稀疏文件是一个基本上是空的文件，其中包含没有用户数据和尚未分配的磁盘空间，为用户数据。随着越来越多的网页更新，在源数据库，档案的大小增长。当一个快照所采取的，稀疏的文件占用了很少的磁盘空间。作为数据库的更新，随着时间的推移，然而，稀少的档案可以成长为一个非常大的文件。
以下数字显示的副本-关于-写操作。根据灰色矩形在快照图所代表的潜在空间在一个稀疏文件是作为尚未未分配。在收到第一次更新的网页，在源数据库，该数据库引擎写信给文件和作业系统分配的空间在快照的稀疏文件并复制原始页。数据库引擎，然后更新网页，在源数据库。以下的数字，说明这种复制对-写操作。

参考