python urllib2技术补充参考--中文版01

一、还原的级别

SQL Server 支持在以下级别还原数据：（1）数据库（“数据库完整还原”）　　还原和恢复整个数据库，并且数据库在还原和恢复操作期间处于脱机状态（2）数据文件（“文件还原”）　　还原和恢复一个数据文件或一组文件。在文件还原过程中，包含相应文件的文件组在还原过程中自动变为脱机状态。访问脱机文件组的任何尝试都会导致错误。　　注意： 不能备份或还原单个表。（3）数据页（“页面还原”）　　在完整恢复模式或大容量日志恢复模式下，可以还原单个数据库。可以对任何数据库执行页面还原，而不管文件组数为多少。　　注意：在 SQL Server 2008 中，可以还原使用 SQL Server 2000、SQL Server 2005 或 SQL Server 2008 创建的数据库备份。但是，SQL Server 2008 无法还原使用 SQL Server 2000 或 SQL Server 2005 创建的 master、model 和 msdb 备份。此外，任何早期版本的 SQL Server 都无法还原 SQL Server 2008 备份。　　SQL Server 备份和还原对所有支持的操作系统都有效，不管它们是 64 位还是 32 位系统。
二、还原方案　　SQL Server 中的“还原方案”是从一个或多个备份还原数据、继而恢复数据库的过程。支持的还原方案取决于数据库的恢复模式和 SQL Server 的版本。1、数据库完整还原（1）在简单恢复模式下　　这是基本的还原策略。数据库完整还原可能涉及完整数据库备份的简单还原和恢复。另外，完整的数据库还原还可能涉及还原完整数据库备份，以及还原和恢复差异备份。（2）在完整/大容量日志恢复模式下　　这是基本的还原策略。数据库完整还原涉及还原完整数据库备份或差异备份（如果有），以及还原所有后续日志备份（按顺序）。通过恢复并还原上一次日志备份 (RESTORE WITH RECOVERY) 完成数据库完整还原。2、文件还原（1）在简单恢复模式下　　还原损坏的只读文件，但不还原整个数据库。仅在数据库至少有一个只读文件组时才可以进行文件还原。
（2）在完整/大容量日志恢复模式下　　还原一个或多个文件，而不还原整个数据库。可以在数据库处于脱机状态时执行文件还原，对于 SQL Server 2005 的某些版本及更高版本，也可以在数据库仍处于联机状态时执行。在文件还原过程中，包含正在还原的文件的文件组一直处于脱机状态。3、页面还原（1）在简单恢复模式下　　不适用。（2）在完整/大容量日志恢复模式下　　还原损坏的页面。可以在数据库处于脱机状态时执行页面还原，对于 SQL Server 2005 的某些版本及更高版本，也可以在数据库仍处于联机状态时执行。在页面还原过程中，正在还原的页面一直处于脱机状态。　　必须具有完整的日志备份链（包含当前日志文件），并且必须应用所有这些日志备份以使页面与当前日志文件保持一致。
4、段落还原（1）在简单恢复模式下　　按文件组级别并从主文件组和所有读写辅助文件组开始，分阶段还原和恢复数据库。
（2）在完整/大容量日志恢复模式下　　按文件组级别并从主文件组开始，分阶段还原和恢复数据库。 　　在 SQL Server 2005 Enterprise Edition 及更高版本中，还原文件或页面的操作可能会允许数据库中的其他数据在还原操作期间仍保持联机状态（联机还原）。　　无论以何种方式还原数据，在恢复数据库前，SQL Server 数据库引擎都会保证整个数据库在逻辑上的一致性。例如，若要还原一个文件，则必须将该文件前滚足够长度，以便与数据库保持一致，才能恢复该文件并使其联机。
三、恢复模式和支持的还原操作　　可用于数据库的还原操作取决于所用的恢复模式。1、数据恢复　　完整恢复模式时，可完整还原（如果日志可用）。大容量日志恢复模式时，某些数据将丢失。简单恢复模式时，自上次完整备份或差异备份后的任何数据将丢失。

2、时点还原完整恢复模式时，可恢复到日志备份所涵盖的任何时间。大容量日志恢复模式时，当日志备份包含任何大容量日志更改时，不允许恢复到时间点。简单恢复模式时，不支持时点还原。

3、文件还原、页面还原、逐级（文件组级）还原　　仅在 SQL Server 2005 Enterprise Edition 及更高版本中提供。　　完整恢复模式时，完全支持。大容量日志恢复模式时，不完全支持。简单恢复模式时，仅对只读辅助文件可用文件还原和逐级（文件组级）还原，不支持页面还原。
四、还原阶段　　还原是一个多阶段过程。还原可能涉及的阶段包括数据复制、重做（前滚）以及撤消（回滚）阶段。　　数据复制阶段涉及从数据库的备份介质将所有数据、日志和索引页复制到数据库文件中。　　重做阶段将记录的事务应用到从备份复制的数据，以将这些数据前滚到恢复点。在此点，数据库通常有未提交的事务，并处于不可用的状态。在这种情况下，恢复数据库操作就包括撤消阶段。　　撤消阶段（恢复的第一部分）将回滚任何未提交的事务并使数据库可供用户使用。回滚阶段后将无法还原后续的备份。1、数据复制阶段　　还原过程的第一个阶段为“数据复制阶段”。在数据复制阶段，将对要还原的数据库、文件或页中的内容进行初始化。此阶段执行的操作包括使用完整备份或差异备份来还原数据库、文件和页。　　数据复制阶段涉及从一个或多个完整备份和（可选）差异备份复制数据，然后将受影响的数据库、文件或页中的内容重置到被备份捕获的时间。　　前滚集中最早的文件或页将决定下一阶段（重做，即前滚）的起点。
2、重做阶段（前滚）　　“重做”（即“前滚”）是指重做对前滚集中的数据记录的更改以使数据及时前滚的过程。为了完成前滚，SQL Server 数据库引擎 按照还原日志备份的方式并从完整备份中的日志开始处理日志备份。　　还原能够避免不必要的前滚。通常，如果数据在备份时为只读并且现在仍为只读，则没有必要前滚并将跳过。
（1）前滚集　　对于差异备份，如果自创建差异基准后，将任何文件添加到了数据库，则还原差异备份可能会用差异备份中的数据覆盖前滚集中的页。还原差异备份仅在下列情况下才会更新页：前滚集中包含页，备份中包含页，RESTORE 语句可以列出页或其文件，或者 RESTORE 语句不列出任何文件或页。　　在完整恢复模式和大容量日志恢复模式下，必须单独备份日志。还原数据和（可选）差异备份后，通常会还原后续日志备份以将数据库恢复到故障点。还原日志备份将对前滚集中的所有页进行前滚。
（2）恢复点　　回滚的目的是将数据返回至其在恢复点的原始状态。“恢复点”是用户指定将数据集恢复到的点。在完整恢复模式下，可以将恢复点指定为特定时间点、标记的事务或日志序列号。在大容量日志恢复模式下，仅当上次日志备份以来尚未执行大容量操作时，才可还原到某个时间点。
（3）重做一致性　　在重做阶段，始终将数据前滚到与数据库在恢复点的状态保持“重做一致性”的点。所有数据都已前滚至可执行撤消的点。　　数据库状态由主文件定义。如果正在还原主文件，则恢复点将确定整个数据库的状态。例如，如果正在将数据库恢复到刚好在意外删除表之前的时点，则必须将整个数据库还原到同一时点。如果不还原主文件，则数据库状态已知，并且还原的数据前滚到与数据库事务一致的恢复点。SQL Server 强制实施这一点。　　但是，数据库可能包含在恢复点处未提交的事务所做的更改。对于联机还原，数据将恢复到与数据库联机部分的当前状态一致的时点。　　差异备份将向前跳到进行差异备份的时间点。前滚集中的页将由差异备份中较新的页覆盖。
3、撤消（回滚）阶段和恢复　　在重做阶段已前滚所有日志事务后，数据库中通常包含在恢复点处未提交的事务所做的更改。这会导致前滚数据在事务上不一致。恢复过程通过打开事务日志来标识未提交的事务。通过回滚未提交的事务以将它们撤消，除非它们持有防止其他事务查看事务上不一致数据的锁。此步骤称为“撤消”（或“回滚”）阶段。如果数据在恢复过程开始时在事务方面已经是一致的，则将跳过撤消阶段。在使数据库事务一致后，恢复操作使数据库联机。　　在一个或多个备份已还原后，恢复通常会包含重做和撤消两个阶段。每个完整备份和差异备份都包含足够的事务日志记录，以便将该备份中的数据恢复到自我一致的状态。　　注意：在崩溃恢复或数据库镜像故障转移期间，SQL Server 2005 Enterprise Edition 及更高版本允许用户在撤消阶段访问数据库。这称为“快速恢复”。快速恢复是可能的，因为崩溃发生时未提交的事务重新获得它们在崩溃前所持有的所有锁。回滚这些事务时，事务的锁可以保护它们免受用户的干扰。
4、RECOVERY 和 NORECOVERY 选项与还原阶段的关系

　　根据特定 RESTORE 语句是否指定了 WITH NORECOVERY，该语句会在重做阶段之后结束或继续完成撤消阶段，如下所示：（1）WITH RECOVERY 包含重做和撤消两个阶段，并可以恢复数据库；不能还原其他备份。这是默认设置。　　如果前滚集前滚得不够远，无法与数据库一致，则不会出现撤消阶段。数据库引擎将发出错误，恢复将停止。　　如果整个前滚集与数据库一致，则执行恢复，并且可使数据库联机。（2）WITH NORECOVERY 省略撤消阶段以保留未提交的事务。省略撤消阶段允许还原其他备份以将数据库进一步前滚。有时，RESTORE WITH NORECOVERY 会将数据前滚到其与数据库一致的位置。在这种情况下，数据库引擎将发出信息性消息，声明现在可以使用 RECOVERY 选项恢复前滚集。（3）注意：第三种方法 WITH STANDBY 指定一个允许撤消恢复效果的备用文件（在 SQL Server 2000 中，该文件被称为“撤消文件”）。STANDBY 选项可以用于脱机还原（包括部分还原），但不能用于联机还原。尝试为联机还原操作指定 STANDBY 选项将会导致还原操作失败。　　备用文件用于为 RESTORE WITH STANDBY 的撤消过程中修改的页面保留一个“写入时副本”预映像。备用文件允许用户在事务日志还原期间以只读方式访问数据库，并允许数据库用于备用服务器情形，或用于需要在日志还原操作之间检查数据库的特殊恢复情形。　　该文件与其他数据库文件不同，数据库引擎仅在活动还原操作过程中持续打开该文件。当数据库处于 STANDBY 状态时，您应将这个备用文件视为和任何其他数据库文件同样重要。执行完 RESTORE WITH STANDBY 操作之后，下一个 RESTORE 操作会自动删除撤消文件。如果在下一个 RESTORE 操作之前手动删除了这个备用文件，则必须重新还原整个数据库。
四、还原顺序　　可以使用 SQL Server 还原来快速轻松地完成一些简单操作，用户还可以将需要还原的数据控制在最少，时间控制在最短。下面将说明如何将多个 RESTORE 语句组合到还原顺序（复制数据、前滚数据及在回滚阶段结束时使数据联机）中。1、日志序列号SQL Server 事务日志中的每个记录都由一个日志序列号 (LSN) 唯一标识。LSN 是这样排序的：如果 LSN2 大于 LSN1，则 LSN2 所标识的日志记录描述的更改发生在日志记录 LSN1 描述的更改之后。　　发生重大事件的日志记录的 LSN 对于构造正确的还原顺序可能很有用。因为 LSN 是有顺序的，所以可以比较它们是否相等（即 <、>、=、<=、>=）。构造还原顺序时，这种比较很有用。注意：LSN 是数据类型为 numeric 的值 (25,0)。算术运算（例如加法或减法）对 LSN 没有任何意义，请不要与 LSN 一起使用。　　RESTORE 顺序期间，在内部使用 LSN 跟踪数据还原到的时间点。还原备份后，数据被还原到与进行备份的时间点相对应的 LSN。差异和日志备份将还原的数据库推到稍后的时间，该时间与一个更高的 LSN 相对应。　　使用下列一种或几种方法可以查看发生给定备份和还原事件的日志记录的 LSN：　　msdb 数据库中 backupset 表、backupfile表　　sys.database_files；sys.master_files　　RESTORE HEADERONLY 返回包含特定备份设备上所有备份集的所有备份标头信息的结果集　　RESTORE FILELISTONLY 返回由备份集内包含的数据库和日志文件列表组成的结果集。
2、还原计划在完整恢复模式时，对于还原计划，最重要的日志序列号 (LSN) 是第一个和最后一个 LSN。可以从下列位置获取这些 LSN：　　msdb 中的 backupset 表。名为 first_lsn 和 last_lsn 的列。　　RESTORE HEADERONLY 语句。名为 FirstLSN 和 LastLSN 的列。（1）日志序列号和数据备份或差异备份　　对于数据备份和差异备份，first_lsn 和 last_lsn 之间的日志数据包含在备份中。这使得使用该备份（而无需日志备份）就可以恢复到 last_lsn。对于数据备份或差异备份，如果按还原顺序使用备份，则 last_lsn 可能是最早的恢复点。如果需要更早的恢复点，则必须使用更早的备份。当您计划在还原数据备份或差异备份后使用哪个日志备份前滚时，通常将从该数据备份或差异备份之后的第一个日志备份开始。检查备份的属性时，您就会发现这样一个日志备份，其 first_lsn 小于或等于数据备份或差异备份中的 last_lsn，并且 last_lsn 大于数据日志备份或差异日志备份中的 last_lsn。
（2）日志序列号和日志链中的日志备份　　新的日志链将随数据库创建后的第一个完整数据库备份而启动，或在从简单恢复模式切换到完整或大容量日志恢复模式后启动。在链的第一个日志备份中，backupset.begins_log_chain = 1。　　first_lsn 和 last_lsn 用于将日志备份连成一个连续的序列（即日志链）。您可以使用连续日志备份序列前滚数据库（可以从最近的数据备份或差异备份前滚，也可以从丢失或损坏的数据备份和差异备份的早期备份前滚）。　　在日志备份中，first_lsn 是备份中第一个日志记录的 LSN，从此日志记录开始，日志备份最多包含到 LSN 为 last_lsn 的日志记录（但不包含该日志记录）。当且仅当早期备份 (Backup_A) 中的最后一个日志记录的 LSN 大于或等于后期备份 (Backup_B) 中的第一个日志记录的 LSN 时，两个日志备份才是连续的；也就是说，Backup_A.last_lsn >= Backup_B.first_lsn。如果不是这样，则两个备份之间将存在空白。　　如果 A.last_lsn = B.first_lsn，则 B 通常是紧跟在 A 后进行的日志备份。　　下图说明了此关系。请注意，日志备份 B 中出现的日志记录 n，在日志备份 A 中记录为 last_lsn，在日志备份 B 中记录为 first_lsn。

　　如果 A.last_lsn > B.first_lsn，则存在重叠。重叠通常是由于创建仅复制日志备份或在时点恢复后备份第一个日志引起的。重叠可能会涉及不同的恢复分叉。（3）日志链断开的原因　　通常，SQL Server 数据库引擎会防止日志备份序列中出现空白，从而使日志链保持完整。但是，如果数据库管理员先将恢复模式更改为简单恢复模式，然后再将其更改回完整或大容量日志恢复模式，会使日志链断开。　　由于日志链已断开，因此无法在涉及简单恢复模式的恢复模式切换中前滚。更改到完整或大容量日志恢复模式后，应使用新的差异基准或差异基准集。此外，也可以使用差异备份填补空白。
3、恢复路径（1）理解恢复路径　　如果您使用差异或日志备份并且通过下列方式之一将数据库恢复到以前的时间点，则很有必要理解恢复路径：执行时点还原
执行恢复而不先还原所有日志备份或最新的差异备份。
　　如果将数据库恢复到更早的恢复点并从该点开始使用数据库，会生成一个新的恢复路径。“恢复路径”是指通过正常的数据库使用或特定的数据和日志还原将数据库恢复到特定时间点的数据和日志备份的序列。恢复路径由一组不同的转换（随着时间的变化对数据库进行演变并保持一致性）组成。下图说明了恢复点与其生成的恢复路径之间的关系。

　　下列情况会创建新的恢复路径，因为数据库未还原到“结束时间”。此后，会出现使数据库进入两个或两个以上恢复路径的备份，它们都使用同一组 LSN。在不使用任何其他备份类型的情况下，还原完整数据库备份并恢复数据库。
将数据库恢复到非最新的差异备份的结尾处。
不应用现有的事务日志备份还原完整数据库备份和差异数据库备份并恢复数据库。
将数据库恢复到非最新的事务日志备份的结尾处。
将数据库恢复到特定时间或事务日志备份中的某个标记事务处。
　　通常，如果某恢复点导致事务回滚，则该恢复点将启动一个新的恢复路径。预先存在的备份现在可能具有比此恢复点的日志序列号 (LSN) 更大的 LSN。这些备份中的 LSN 存在于由当前恢复操作创建的新分支以外的恢复分支中。最佳方法：若要避免创建具有多个恢复分叉的恢复路径，请在恢复数据库之后尽快执行一组完整的数据备份。此方法可保证对单个恢复分支执行所有备份。若要对此进行验证，可以在备份数据后查看 backupset 表中的 last_recovery_fork_guid 列或 RESTORE HEADERONLY 结果集。（2）恢复路径示例　　最初，数据库的所有备份构成一个恢复路径，如下图所示。在该图中，恢复路径包含一个数据库备份（时间为 t1）和三个日志备份（时间分别为 t2、t3 和 t4）。

　　下图显示了将数据库恢复到一个旧时点时所获得的一个恢复分叉。备份 t4 的问题导致数据库管理员在 t3 日志备份的末尾恢复数据库。该还原操作导致了一个恢复分叉。在时间 t5 处，一个新的日志备份启动了一个新的恢复分支，即恢复分支 2。

　　注意：t5 日志备份包含将此备份连接至恢复分支 1 上的 t3 日志备份的恢复分叉元数据。　　上图中的示例创建了一个新的恢复路径，如下图所示。新恢复路径包含恢复分支 1 上的部分备份（t1 到 t3）以及恢复分支 2 上的所有日志备份（t5 到 t9）。从此恢复路径的角度看，日志备份 t4 已过时。

　　时点还原之后的下一个备份始终会导致恢复分叉。在下图中，在 t4 日志备份的中间完成了一个时点还原。将数据库恢复到该时点导致了一个恢复分叉。然后，在时间 t5 处为恢复的数据库创建了一个日志备份，从而建立了恢复分支 2 并创建了一个新的恢复路径。新分支上的第一个日志备份 t5 所包含的第一个 LSN 与日志备份 t3 相同，并将替换后者。因此，t3 和 t4 备份在新的恢复路径上均已过时。

　　若要沿此新恢复路径还原备份，则其还原顺序为：t1、t2 和 t5。将来在恢复分支 2 上做备份时，这些备份将纳入该新恢复路径中。
4、 管理恢复分叉（1）还原并沿旧路径前滚　　通常，当存在多个恢复路径时，其中最新的恢复路径将是还原数据库的首选路径。建议您不要使用旧的恢复路径。但是，如有必要，可以按照在创建当前恢复路径之前所做的备份顺序，沿着旧的恢复路径前滚。例如，可以使用在时点恢复之前所做的备份来到达旧路径上后面的各个时点。　　例如，根据上图中创建的备份，在创建日志备份 t5 之后，仍可以从 t1 处所做的完整数据库备份还原到日志备份 t4 的末尾。这是在旧恢复路径上进行的。（2）还原并从旧路径前滚到新路径　　SQL Server 数据库引擎禁止在一个还原顺序中使用来自不同路径的备份（即试图沿不同恢复路径前滚）。此限制使得数据库在恢复之后仍能保持一致。　　若要还原并沿新恢复路径前滚，请为恢复点之前和之后的备份构造不同的还原顺序：还原在引入新恢复路径的恢复之前所做的备份。排除包含恢复点的备份。
通过还原在创建恢复路径之后所做的备份，沿新恢复路径前滚。

（3）管理恢复分叉　　“恢复分支”是共享同一 GUID 的一组 LSN。恢复路径描述从“起点” (LSN,GUID) 到“终点” (LSN,GUID) 的一组 LSN。恢复路径中的 LSN 可以从起点到终点遍历一个或多个恢复分支。创建数据库并用 RESTORE WITH RECOVERY 生成恢复分叉之后，会生成新的恢复分支。　　“恢复分叉”指每次执行 RESTORE WITH RECOVERY 时，开始新的恢复分支的点 (LSN,GUID)。每个恢复分叉都确定了恢复分支之间的父子关系。　　恢复数据库会将整个数据库状态（包括下一个 LSN）设置到恢复点。然后从 fork_point_lsn 开始重用 LSN。因此，在构造还原顺序时，必须按恢复分叉和 LSN 将备份链接起来，因为同一 LSN 可能存在于多个分叉中。下图说明了如何重用 LSN。它显示了在不同的恢复分叉中如何重用 LSN。图中的绿框表示使用相同 LSN 的两个备份。

　　如果还原顺序必须包含遍历恢复分叉的备份，则在构造还原顺序时必须使所用的备份沿正确的恢复路径到达恢复点。因此，备份将包括第一个恢复分叉 GUID 和最后一个恢复分叉 GUID。　　这些 GUID 连同其他与跟踪恢复路径相关的元数据都存储在 backupset 历史记录表中，也可以由 RESTORE HEADERONLY 语句返回。