恢复数据库

如果您喜欢外将数据库恢复到最近的事务处理日志备份结束时的状态，您应该使用最近的完全数据库备份进行启动。可以将这种完全数据库备份恢复为SQLSERVER实例的任何一种实例，而不仅仅是它得以备份时的状态。如果您在使用差异数据库备份，那么您可以恢复到最近的差异数据库备份。最后，您将恢复比最近的完整或差异数据库备份更近的事务处理日志备份。作为恢复最后的事务处理日志备份的一部分，SQL Server还将执行一个手工恢复过程，将显著的事务处理适当向前和向后滚动。

如果最近的完整数据库或差异数据库备份受到损坏或丢失，您仍然可以使用以前的事务处理日志备份进行恢复。因此，如果您保留了一个完整的事务处理日志备份链，那么，您总可以恢复，因为单个的完整数据库备份与所有事务处理备份日志一起存在。显然，应用其他的事务处理日志备份将花费其他的时间。经常性的执行完全和差异数据库备份可以减少修复时间，因为它需要的应用事务处理日志备份少。保留并保护（以及复制）完整的事务处理日志备份链，可以提供一些其他的容错性，以防备份媒体的损失或丢失。

恢复文件和文件组

如果您希望将文件或文件组恢复到最近的事务处理日志备份点时的状态，您应该使用最近的文件或文件组备份开始。该最近的备份可以来自文件或文件组备份，也可以来自完全数据库备份。从完全数据库备份恢复单个文件比从文件备份恢复单个文件花费的时间要长。如果您正使用差异文件或文件组备份，那么可以恢复最近的文件或文件组备份。最后，按照顺序恢复比最近恢复了的差异文件或文件组备份更近的每个事务处理日志备份。作为恢复最后事务处理日志备份过程的一部分，SQLSERVER将执行一个手工的恢复过程，将显著的事务处理过程适当向前和向后滚动。这些文件或文件组将得以正确恢复，而不会丢失数据。

与完整和差异数据库备份不同，文件和文件组备份必须应用事务处理日志备份，以便使恢复的文件或文件组在逻辑上与数据库的其他保持一致。如果您正在使用文件或文件组备份恢复整个数据库，那么任何一个备份媒体的丢失都将导致整个数据库的不可恢复。

恢复所有的数据文件或所有的文件组，并应用所有的事务处理日志，在功能上与恢复整个数据库等效。

恢复和修复到某个以前的时间点

有时，可能因为某种用户或应用程序错误，您希望将数据库恢复到某个以前时间的某一点状态。将数据库恢复到事务处理日志中某个特定的时间点，或事务处理日志中某个命名标记的状态，就可以达到此目的。为了恢复到某个特定的时间点，您可以恢复完全数据库备份，并选择某个差异数据库备份。然后按顺序将事务处理日志备份恢复到您打算恢复的时间点。当恢复了希望恢复的最后一个事务处理日志时，应该将恢复过程仅指定到事务处理日志备份中的某个特定的时间点。

完全数据库备份: 将数据库中所有数据文件全部复制，包括完全数据库备份过程中数据库的所有行为。所有用户数据以及所有数据库对象，包括系统表，索引和用户自定义表，都包括在内。

差异数据库备份: 差异数据库备份复制最后一次完全数据库备份以来所有数据文件中修改过的数据，包括差异数据库备份过程中发生的所有数据库行为。

文件和文件组备份: 文件备份只复制单个数据文件，文件组备份复制单个文件组中的每个数据文件，包括文件或文件组备份过程中发生的所有数据库行为。此类型的备份比完全数据库备份占用的时间和空间都要小。文件和文件组备份需要进行详细计划，以便相关的数据和索引可以共同备份（恢复）。此外，在逻辑上将文件和文件组恢复到与数据库中的其他部分一致的状态，需要一个事务处理日志文件备份 的完整子集。

差异文件和差异文件组备份:差异文件和文件组备份在概念上与差异数据库备份一致。它们比复制整个文件或文件组花费的时间和空间更少，由于它减少必须应用的事务处理日志备份的数量。

事务处理日志备份: 事务处理日志备份是对最后一次事务处理日志备份以来事务处理日志中记录的所有事务处理的一种顺序记录。事务处理日志备份使您可以将数据库恢复到某个特定的时间点，如输入错误数据前。事务处理日志备份只以BULK-LOGGED RECOVERY模型和FULL RECOVERY模型使用。SIMPLE RECOVERY模型不使用事务处理日志备份来对数据库进行恢复和修复。

SQL Server 2000完成事务处理日志备份: （除非专门指定）时，它将截断并没有包含事务处理日志中活动部分的所有虚拟日志文件VLF。这使得可以重复使用这些VLF。事务处理日志的活动部分包括：事务处理日志中所有含有活动事务处理，或者标记为复制但是还没有复制的事务处理的部分。在产品数据库中，您通常将使用BULK-LOGGED RECOVERY模型或者FULL RECOVERY模型，并且周期性的执行事务处理日志备份，以截断事务处理日志。如果不经常截断事务处理日志，它将可能积累过多。如果事务处理日志运行越界，SQL Server将被关闭。您应该通过周期性的事务处理日志备份来截断事务处理日志，而不应该手工截断事务处理日志，因为手工截断中断日志文件备份链。您只需要备份事务处理日志而不用截断它的唯一时候是：当数据文件失效并且必须备份当前的活动事务处理日志时，在这种情况下，就不能截断，因为数据文件被损坏或不存在了。

理解修复过程: SQL Server 2000具有两种修复过程：自动修复过程（每次启动SQL Server时自动执行）和手工修复过程。

设计自动修复过程的目的是为了保证一旦启动了SQL Server，每个数据库中的数据可以在逻辑上保证一致，而不管SQL Server是如何或为什么关闭。SQL Server使用事务处理日志来完成该任务。它读取每个数据事务处理日志的活动部分，并对自最近检查点以来发生的所有事务处理进行检查。它对所有提交的事务处理进行判断，并将它们向前滚动。这意味着将它们再次在数据库上加以应用。然后，它判断所有未提交的事务处理，将它们向后滚动。这可以保证只部分写入数据库的事务处理全部被删除。该过程可以保证每个数据库逻辑上的连续状态得以保存。自动修复过程还可以发布一个检查点，来标记事务处理日志与该点保持一致。

SQL Server从修复主数据库开始。主数据库包含了用于定位，打开和恢复剩余的数据库。其次，它修复模型和MSDB数据库（和可能存在的分布式数据库）。再次，修复每个用户数据库。最后，清除并启动TEMPDB数据库而结束。您可以通过查询SQL Server错误日志来检查修复过程。

注意，你不能直接控制自动修复过程。

手工恢复涉及到应用一个或多个数据库备份，然后手工将它们完全修复或修复到某个特定点。在手工修复过程结束时，数据库逻辑上应该是一致的。