用于还原和恢复数据的数据副本称为“备份”。使用备份可以在发生故障后还原数据。通过妥善的备份，可以从多种故障中恢复，例如：
介质故障。
用户错误（例如，误删除了某个表）。
硬件故障（例如，磁盘驱动器损坏或服务器报废）。 自然灾难。
此外，数据库备份对于进行日常管理（如将数据库从一台服务器复制到另一台服务器，设置数据库镜像以及进行存档）非常有用。
1. 备份概述 (SQL Server)
所有的恢复模式都允许您完整或部分备份 SQL Server 数据库或数据库的单个文件或文件组。不能创建表级备份。 数据备份
数据的备份（“数据备份”）的范围可以是完整的数据库、部分数据库或者一组文件或文件组。对于这些范围，SQL Server 均支持完整和差异备份：
完整备份
“完整备份”包含特定数据库（或者一组特定的文件组或文件）中的所有数据，以及可以恢复这些数据的足够的日志。
差异备份
“差异备份”基于数据的最新完整备份。这称为差异的“基准”或者差异基准。差异基准是读/写数据的完整备份。差异备份仅包含自建立差异基准后发生更改的数据。通常，建立基准备份之后很短时间内执行的差异备份比完整备份的基准更小，创建速度也更快。因此，使用差异备份可以加快进行频繁备份的速度，从而降低数据丢失的风险。通常，一个差异基准
会由若干个相继的差异备份使用。还原时，首先还原完整备份，然后再还原最新的差异备份。
经过一段时间后，随着数据库的更新，包含在差异备份中的数据量会增加。这使得创建和还原备份的速度变慢。因此，必须重新创建一个完整备份，为另一系列的差异备份提供新的差异基准。
注意： 通常，差异备份所涵盖的数据文件与单个差异基准中所涵盖的文件相同。在简单恢复模式下，一个差异备份只能有一个差异基准。尝试使用多个基准会引发错误，并且备份操作将会失败。在完整恢复模式下，差异文件备份可以使用多个基准，但这可能难以管理。有关详细信息，请参阅使用多基准差异备份。
每个数据备份都包括部分事务日志，以便备份可以恢复到该备份的结尾。 第一次数据备份之后，在完整恢复模式或大容量日志恢复模式下，需要定期进行“事务日志备份”（或“日志备份”）。每个日志备份都包括创建备份时处于活动状态的部分事务日志，以及先前日志备份中未备份的所有日志记录。
1.1 数据库备份
数据库备份易于使用，在数据库大小允许时都建议使用这种方式。SQL Server 支持以下数据库备份类型。
备份类型 说明 数据库备份 整个数据库的完整备份。数据库备份表示备份完成时的整个数据库。 差异数据库数据库中所有文件的备份。此备份只包含自每个文件的最新数据库备份 备份之后发生了修改的数据区。 部分备份
在 SQL Server 2005 中引入了部分备份和部分差异备份。这些备份的设计目的在于：为在简单恢复模式下对包含一些只读文件组的数据库的备份工作提供更多的灵活性。但是，所有恢复模式都支持这些备份。 SQL Server 2008 支持下列类型的文件备份。
备份类说明 型 部分备备份主文件组、所有读/写文件组以及任何选择指定的只读文件或文件份 组中的所有完整数据。只读数据库的部分备份仅包含主文件组。 部分差这种备份仅包含自同一组文件组的最新部分备份以来发生了修改的数异备份 据区。 文件备份
可以分别备份和还原数据库中的文件。使用文件备份使您能够只还原损坏的文件，而不用还原数据库的其余部分，从而加快了恢复速度。例如，如果数据库由位于不同磁盘上的若干个文件组成，在其中一个磁盘发生故障时，只需还原故障磁盘上的文件。但计划和还原文件备份可能会十分复杂；因此，只有在文件备份能够为您的还原计划带来明显价值时，才应使用这种备份方式。 SQL Server 支持下列类型的文件备份。
备份说明 类型 一个或多个文件或文件组中所有数据的完整备份。 文件重要提示： 备份 在简单恢复模式下，文件备份基本上仅限于只读辅助文件组。您可以创建读/写文件组的文件备份，但必须先将文件组设置为只读，并执行差异只读文件备份，然后才能还原读/写文件备份。 一个或多个文件的备份，包含自每个文件的最新完整备份之后发生了更改的数据区。 差异文件备份 注意： 在简单恢复模式下，此备份假定自完整备份之后已经将数据更改为只读。 注意：
可以备份和还原全文目录。有关详细信息，请参阅备份和还原 SQL Server 2008 全文目录和段落还原和全文索引。
1.2 事务日志备份（仅用于完整恢复模式或大容量日志恢复
模式）
在完整恢复模式或大容量日志恢复模式下，需要定期进行“事务日志备份”（或“日志备份”）。每个日志备份都包括创建备份时处于活动状态的部分事务日志，以及先前日志备份中未备份的所有日志记录。不间断的日志备份序列包含数据库的完整（即连续不断的）日志链。在完整恢复模式下（或者在大容量日志恢复模式下的某些时候），连续不断的日志链让您可以将数据库还原到任意时间点。 在创建第一个日志备份之前，您必须先创建一个完整备份（如数据库备份）。因此，定期备份事务日志十分有必要，这不仅可以使工作丢失的可能性降到最低，而且还能截断事务日志。有关详细信息，请参阅使用事务日志备份。
重要提示：
若要限制需要还原的日志备份的数量，必须定期备份数据。例如，可以制定这样一个计划：每周进行一次完整数据库备份，每天进行若干次差异数据库备份。
1.3 仅复制备份
通常，进行备份会更改数据库并影响其后备份的还原方式。但是，有时需要针对特殊目的执行备份，同时不影响数据库的整体备份和还原过程。为此，SQL Server 2005 中引入了仅复制备份。这种备份独立于 SQL Server 备份的正常顺序。有关详细信息，请参阅仅复制备份。
1.4 备份设备
SQL Server 备份数据在备份设备（如磁盘文件或磁带媒体）上创建。可以将新备份数据追加到设备中的任意现有备份数据，或者覆盖任意现有备份数据。有关详细信息，请参阅在 SQL Server 中使用备份媒体。
计划备份
执行备份操作对运行中的事务影响很小，因此可以在正常操作过程中执行备份操作。在备份操作过程中，SQL Server 将数据从数据库文件直接复制到备份设备中。这不会更改数据，也不会延迟在备份过程中运行的事务。因此，您可以在对生产工作负荷的影响很小的情况下执行 SQL Server 备份。有关备份过程中的并发限制的信息，请参阅本主题后面的“SQL Server 中备份操作的限制”。 可以计划定期自动执行备份。有关如何为数据库备份和日志备份计划备份作业的信息，请参阅维护计划向导。
1.5 备份压缩
SQL Server 2008 Enterprise 及更高版本支持压缩备份，并且每个 SQL Server 2008 及更高版本都可以还原压缩后的备份。有关详细信息，请参阅备份压缩 (SQL Server)。
1.6 SQL Server 中备份操作的限制
在 SQL Server 2005 及更高版本中，可以在数据库在线并且正在使用时进行备份。但是，存在下列限制。
无法备份脱机数据
隐式或显式引用脱机数据的任何备份操作都会失败。一些典型示例包括：
您请求完整数据库备份，但是数据库的一个文件组脱机。由于所有文件组都隐式包含在完整数据库备份中，因此，此操作将会失败。
若要备份此数据库，可以使用文件备份并仅指定联机的文件组。 请求部分备份，但是有一个读/写文件组处于脱机状态。由于部分备份需要使用所有读/写文件组，因此该操作失败。
请求特定文件的文件备份，但是其中有一个文件处于脱机状态。该操作失败。若要备份联机文件，可以省略文件列表中的脱机文件并重复该操作。
通常，即使一个或多个数据文件不可用，日志备份也会成功。但如果某个文件包含大容量日志恢复模式下所做的大容量日志更改，则所有文件都必须都处于联机状态才能成功备份。
备份过程中的并发限制
数据库仍在使用时，SQL Server 可以使用联机备份过程来备份数据库。在备份过程中，可以进行多个操作；例如：在执行备份操作期间允许使用 INSERT、UPDATE 或 DELETE 语句。但是，如果在正在创建或删除数据库文件时尝试启动备份操作，则备份操作将等待，直到创建或删除操作完成或者备份超时。 在数据库备份或事务日志备份的过程中无法执行的操作包括：
文件管理操作，如含有 ADD FILE 或 REMOVE FILE 选项的 ALTER DATABASE 语句。
收缩数据库或文件操作。这包括自动收缩操作。
如果在进行备份操作时尝试创建或删除数据库文件，则创建或删除操作将失败。
如果备份操作与文件管理操作或收缩操作重叠，则产生冲突。无论哪个冲突操作首先开始，第二个操作总会等待第一个操作设置的锁超时。（超时期限由会话超时设置控制。）如果锁在超时期限内释放，则第二个操作继续执行。如果锁超时，则第二个操作失败。
注意：
有关如何创建备份的信息，请参阅创建 SQL Server 数据库的完整备份和差异备份和使用事务日志备份。
2. 简单恢复模式下的备份
介绍一个备份策略示例并说明如何在简单恢复模式下最大程度地减少工作损失。
重要提示：
简单恢复模式并不适合生产系统。因为对生产系统而言，丢失最新的更改是无法接受的。在这些情况下，我们建议使用完整恢复模式。有关详细信息，请参阅在完整恢复模式下备份。
简单恢复模式是最简单的备份和还原形式。该恢复模式同时支持数据库备份和文件备份，但不支持日志备份。事务日志数据仅与关联的用户数据一起备份。缺少日志备份可简化备份和还原的管理。但是，数据库只能还原到最近备份的末尾。
2.1 备份策略示例
下图显示了简单恢复模式下最简单的备份与还原策略。此策略仅使用包含数据库中所有数据的完整数据库备份。存在五个完整数据库备份，但只需要还原最近的备份（在 t5 时点执行的备份）。还原此备份会将数据库恢复到 t5 时点。由 t6 框表示的所有后续更新都将丢失。
注意：
在简单恢复模式下，会自动截断事务日志，以删除所有不活动的虚拟日志文件。截断通常发生在每个检查点之后，但在某些情况下可能会延迟。有关详细信息，请参阅事务日志截断。
2.2 最大程度地降低工作丢失的风险
在简单恢复模式下，在执行下次完整备份或差异备份前，所做工作丢失的风险会随时间的推移而增加。与完整备份不同的是，差异备份仅包括自上次完整备份以来所做的更改。因此，我们建议您在不影响备份管理的前提下时常备份，以免丢失大量数据。
下图显示了仅使用数据库备份的备份计划的工作丢失风险。此策略仅适用于可经常备份的小型数据库。
下图显示的备份策略通过使用差异数据库备份对数据库备份进行补充，从而减少了工作丢失风险。在第一个数据库备份完成后，会接着进行三个差异数据库备份。第三个差异备份足够大，因而下一个备份为完整数据库备份。该数据库备份将成为新的差异基准。
2.3 创建数据库备份 2.3.1 创建完整数据库备份
如何创建完整数据库备份 (Transact-SQL) 如何备份数据库 (SQL Server Management Studio) SqlBackup (SMO)
2.3.2 创建差异数据库备份
如何创建差异数据库备份 (Transact-SQL)
如何创建差异数据库备份 (SQL Server Management Studio) SqlBackup (SMO)
2.3.3 计划备份作业
维护计划向导
2.4 使用备份还原数据库
完整备份和差异备份只包含足以恢复数据库的日志数据。还原数据库的过程需要一个还原操作顺序（“还原顺序”）。还原顺序从还原完整备份开始，然后是相应的差异备份（可选）。在有些情况下，例如还原文件时，可能需要还原多对完整备份和差异备份。在还原了相关备份后，必须恢复数据库。有关还原方案的简介，请参阅 还原与恢复概述 (SQL Server)。
有关在简单恢复模式下执行还原备份时的各种限制，请参阅简单恢复模式下的还原限制
3. 在完整恢复模式下备份
介绍一个备份策略示例并说明如何在完整恢复模式下最大程度地减少工作损失。
完整恢复模式使用日志备份在最大范围内防止出现故障时丢失数据，这种模式需要备份和还原事务日志（“日志备份”）。使用日志备份的优点是允许您将数据库还原到日志备份中包含的任何时点（“时点恢复”）。可以使用一系列日志备份将数据库前滚到其中一个日志备份中包含的任意时点。请注意，为了最大程度地缩短还原时间，可以对相同数据进行一系列差异备份以补充每个完整备份。 假定可以在发生严重故障后备份活动日志，则可将数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们需要使用存储空间并会增加还原时间和复杂性。
注意：
如果使用日志备份的好处不足以抵消为管理备份所带来的开销，则建议使用简单恢复模式。
对于定期使用完整恢复模式的数据库，可以通过暂时使用大容量日志恢复模式来优化某些大容量操作。大容量日志恢复模式会带来多种限制，因此不适合用于日常使用。有关详细信息，请参阅在大容量日志恢复模式下备份。
3.1 备份策略示例
下图显示了在完整恢复模式下的最简单的备份策略。在此图中，已完成了完整数据库备份 Db_1 以及两个例行日志备份 Log_1 和 Log_2。在 Log_2 日志备份后的某个时间，数据库出现数据丢失。在还原这三个备份前，数据库管理员必须备份活动日志（日志尾部）。然后还原 Db_1、Log_1 和 Log_2，而不恢复数据库。接着数据库管理员还原并恢复结尾日志备份 (Tail)。这将把数据库恢复到故障点，从而恢复所有数据。
3.2 最大程度地降低工作丢失的风险
在第一个完整数据库备份完成并且常规日志备份开始之后，潜在的工作丢失风险的存在时间仅为数据库损坏时以及执行最新的常规日志备份时。因此，建议经常执行日志备份，以将工作丢失的风险限定在业务要求所允许的范围内。
下图显示的备份策略使用差异数据库备份来补充完整数据库备份和日志备份。事务日志备份可缩短潜在的工作丢失风险的存在时间，使该风险仅在最新日志备份 t14 之后存在。进行一系列差异备份（三次备份）来减少在出现故障时需要还原的事务日志数。第三个差异备份很大，足以使下一个备份成为完整数据库备份。该数据库备份将成为新的差异基准。
在此图中的第一个数据库备份创建之前，数据库存在潜在的工作丢失风险（从时间 t0 到时间 t1）。该备份建立之后，例行日志备份将工作丢失的风险降为丢失自最近日志备份之后所做的更改（在此图中，最近备份的时间为 t14）。如果在最新备份后出现故障，数据库管理员将尝试备份日志尾部（尚未备份的日志）。如果结尾日志备份成功，则数据库管理员可以通过将数据库还原到故障点来避免任何工作丢失。
有关差异数据库备份的信息，请参阅使用差异备份。
3.3 大容量操作和完整恢复模式
通过记录所有操作（包括大容量操作，如 SELECT INTO、CREATE INDEX）和大容量加载数据，可以使用完整恢复模式将数据库恢复到故障点或某个较早的时点（称为“时点还原”）。
在大容量加载数据和提高性能超过可能的数据丢失风险时，许多使用完整恢复模式的用户会临时切换到大容量日志恢复模式。大容量日志恢复模式按最小方式记录大容量操作（尽管会完整记录其他事务）。有关大容量日志恢复模式的详细信息，请参阅在大容量日志恢复模式下备份
注意：
在 SQL Server 2005 和更高版本中，从不要求使用 sp_dboption 的 select into/bulkcopy 数据库选项并应始终避免使用此选项。应当改用 ALTER DATABASE。在 SQL Server 以后的版本中，将删除 sp_dboption 存储过程。
3.4 使用备份还原数据库
还原数据库的过程需要一个还原操作顺序（“还原顺序”）。还原顺序从至少还原一个完整备份开始，后面可跟对应的差异备份。
每个完整备份和差异备份包含的日志记录刚好足够用来恢复数据库。但通常需要按顺序还原后续的日志备份，并以结尾日志备份结束（如果有）。因此，开始还原数据库之前，必须创建一个结尾日志备份。结尾日志备份允许您将数据库还原到故障点。还原上一个日志备份时，必须恢复数据库。
注意：
在完整恢复模式或大容量日志恢复模式下，SQL Server 2005 Enterprise Edition 及更高版本支持在数据库处于联机状态时还原文件和/或页面。这称为“联机还原”。无论数据库处于脱机还是联机状态，还原文件或页面的 RESTORE 语法都相同。
4. 在大容量日志恢复模式下备份
包含在大容量日志恢复模式下备份数据的特有信息，以及处理大容量日志事务之后将数据库更改为只读对备份的影响。
本主题与对通常使用完整恢复模式的 SQL Server 数据库执行的大容量操作优化有关。
大容量日志恢复模式是一种特殊用途的恢复模式，只应偶尔用于提高某些大规模大容量操作（如大量数据的大容量导入）的性能。完整恢复模式下有关备份的许多说明也适用于大容量日志恢复模式。本主题仅介绍对于大容量日志恢复模式需要特别注意的事项。
注意：
有关在大容量日志恢复模式下对哪些操作进行最小方式记录的信息，请参阅可以尽量减少日志量的操作。
建议尽量减少大容量日志恢复模式的使用。最好的方法是在一组大容量操作之前切换到大容量日志恢复模式，执行操作，然后立即切换回完整恢复模式。有关详细信息，请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。
4.1 大容量日志恢复模式的工作原理
与完整恢复模式（完全记录所有事务）相比，大容量日志恢复模式只对大容量操作进行最小记录（尽管会完全记录其他事务）。大容量日志恢复模式保护大容量操作不受媒体故障的危害，提供最佳性能并占用最小日志空间。
但是，大容量日志恢复模式会增加这些大容量复制操作丢失数据的风险，因为大容量日志操作阻止再次捕获对每个事务逐一所做的更改。如果日志备份包含大容量日志操作，则无法还原到该日志备份中的时点，而只能还原整个日志备份。 在大容量日志恢复模式下，如果日志备份覆盖了任何大容量操作，则日志备份包含由大容量操作所更改的日志记录和数据页。这对于捕获大容量日志操作的结果至关重要。合并的数据区可使日志备份变得非常庞大。此外，备份日志需要访问包含大容量日志事务的数据文件。如果无法访问任何受影响的数据库文件，则事务日志将无法备份，并且在此日志中提交的所有操作都会丢失。
为跟踪数据页，日志备份操作依赖于位图页的大容量更改，位图页针对每个区包含一位。对于自上次日志备份后由大容量日志操作所更新的每个区，在位图中将每个位都设置为 1。数据区将复制到日志中，后跟日志数据。下图显示了日志备份的构造方式。
重要提示：
在完整或大容量日志恢复模式下，如果没有其他因素使日志记录保持为活动状态，则到进行第一次完整备份时，自动检查点才会截断事务日志的未使用部分。第一次完整备份后，截断要求备份事务日志。有关截断延迟因素的信息，请参阅可能延迟日志截断的因素。
4.2 大容量日志恢复模式下的备份限制
在大容量日志恢复模式下，存在下列备份限制：
执行日志备份之前，如果将包含大容量日志更改的文件组设置为只读，则只要文件组保持只读，所有后续的日志备份将包含由大容量日志操作所更改的区数。这样的日志备份将更大，而且比在完整恢复模式下需要花费更长的时间来完成。
若要避免此类情况，请在将文件组设置为只读之前，将数据库切换到完整恢复模式并备份日志。然后再将文件组设置为只读。
如果在上次日志备份之后执行了大容量操作，则数据库中将存在大容量更改。在此情况下，执行日志备份时，所有文件必须处于联机状态或不起作用。这是因为对包含大容量日志操作的日志进行备份要求能访问包含大容量日志事务的数据文件。
有关还原限制的信息，请参阅在大容量日志恢复模式下进行还原。
4.2.1 大容量日志事务操作后将数据库设置为只读
在大容量日志恢复模式下，日志备份在数据库包含大容量日志更改的情况下可以正常运行。但是，如果读/写数据库在大容量日志操作后更改为提供只读访问，则后续日志备份可能会捕获一些不必要的数据。这是因为无法更新数据文件来跟踪大容量日志操作所更改的数据区。所有后续日志备份包含的信息都相同。 最佳方法 在将数据库更改为只读之前，切换到完整恢复模式并创建日志备份。然后将数据库更改为只读。实际上，为只读数据库创建日志备份的意义不大。相反，在数据库变为只读之后，可以执行完整数据库备份，也可以执行一整套文件的备份。有关如何切换恢复模式的信息，请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。
注意：
有关如何备份只读数据库的信息，请参阅备份只读数据库。
4.3 在大容量日志恢复模式下还原备份
有关如何还原大容量日志恢复模式的数据库备份的信息，请参阅在大容量日志恢复模式下进行还原。
使用 Microsoft SQL Server 能够备份和还原数据库。SQL Server 备份组件和还原组件为保护存储在 SQL Server 数据库中的关键数据提供了重要的安全保障。规划良好的备份和还原策略有助于防止数据库因各种故障而造成数据丢失。
通过还原一组备份，然后恢复数据库来测试您的策略，以便为有效地应对灾难做好准备。
用于还原和恢复数据的数据副本称为“备份”。使用备份可以在发生故障后还原数据。通过妥善的备份，可以从多种故障中恢复，例如：
介质故障。
用户错误（例如，误删除了某个表）。
硬件故障（例如，磁盘驱动器损坏或服务器报废）。 自然灾难。
此外，数据库备份对于进行日常管理（如将数据库从一台服务器复制到另一台服务器，设置数据库镜像以及进行存档）非常有用。
5. 本节内容
介绍备份的类型并说明关于备份的限制。
备份概述 (SQL Server)
简单恢复模式下的备份
介绍一个备份策略示例并说明如何在简单恢复模式下最大程度地减少工作损失。
在完整恢复模式下备份
介绍一个备份策略示例并说明如何在完整恢复模式下最大程度地减少工作损失。
在大容量日志恢复模式下备份
包含在大容量日志恢复模式下备份数据的特有信息，以及处理大容量日志事务之后将数据库更改为只读对备份的影响。
SQL Server 中的备份和还原策略简介
帮助您分析和完善数据可用性需求。
创建 SQL Server 数据库的完整备份和差异备份
包含有关差异基准、差异备份如何工作以及如何创建各种类型数据和以下各种差异备份的信息：数据库备份、部分和差异部分备份以及文件和文件组备份。
使用事务日志备份
包含有关如何备份和应用事务日志的信息。本主题仅适用于使用完整/大容量日志恢复模式的数据库。
仅复制备份
介绍仅复制备份。仅复制备份是作为特殊用途添加到定期计划常规备份中的独立备份。
6. 在 SQL Server 中使用备份媒体
若要确保在必要时可以还原系统，您必须认真管理备份。每个备份都包含创建备份时提供的描述性文本以及备份的到期信息。您可以使用这些信息执行以下操作：
识别备份。
确定何时可以安全地覆盖备份。
识别备份媒体（如磁带或磁盘）上的所有备份以确定必须还原的备份。
在处理备份时，建议您执行以下操作：
在安全的地方维护备份，最好是在存放数据以外的安全的站点。 将旧备份保存一段指定的时间，以防最新的备份损坏、销毁或丢失。 标注备份媒体以防因疏忽而覆盖关键备份。这样一来，还可以更容易地识别备份媒体或特定备份集上存储的数据。
对备份使用到期日期，也可防止因疏忽而覆盖备份。 建立覆盖备份的系统，以便首先重新使用最早的备份。
7. 备份和还原系统数据库的注意事项
7.1
管理日志备份
使用的是完整恢复模式或大容量日志恢复模式时，如果丢失了日志备份，则可能无法将数据库还原到上次备份之后的某个时点。可以考虑通过将日志备份到磁盘，然后将磁盘文件复制到其他设备（如单独的磁盘或磁带）来创建多个日志备份副本。
建议您为一系列数据库备份存储一条日志备份链。如果最新的完整数据库备份不可用，则可以先还原早期的完整数据库备份，然后再还原在该早期完整数据库备份之后创建的所有事务日志备份。
如果丢失了日志备份，则在将数据库还原到事务日志备份内的某个时点时，建议您保留丢失的日志备份之前的事务日志备份。
7.2 物理保护
为保护备份磁带，建议将其存储在另外一个安全的位置。
为保护备份磁盘文件，建议仅备份到受限制性访问控制列表 (ACL) 保护的磁盘文件。应该在创建备份的根目录下设置 ACL。在某些情况下，可能需要使用 NTFS 加密文件系统 (EFS) 进一步保护基于磁盘的备份。另外，还建议您使用 Windows 备份将 SQL Server 磁盘备份备份到磁带，然后再将磁带存储在另外一个安全的位置。有关详细信息，请参阅 Windows 文档。
7.3 备份密码保护
SQL Server 支持对备份媒体和备份集进行密码保护。
重要提示：
此密码很容易被破获。它的目的是为了阻止授权用户或非授权用户使用 SQL Server 工具进行不正确的还原，但不能防止通过其他方式或通过替换密码读取备份数据。 下一版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能，并着手修改当前还在使用该功能的应用程序。
执行备份操作时不需要密码，不过密码可提供额外的安全级别。可以将它们用作对使用 SQL Server 安全角色的补充。使用密码保护帮助您防止未经授权或无意识的操作，例如：
还原数据库 追加到媒体 覆盖媒体
重要提示：
密码安全不能防止通过格式化媒体或将媒体用作延续磁带来覆盖媒体。另外，指定密码不会以任何方式加密数据。
7.3.1 媒体集密码
它对媒体集中保存的数据提供较弱的保护。当写入媒体标头时，将保存媒体集密码；不能更改该密码。如果格式化媒体集时提供了密码，则在该媒体集上创建备份集时必须提供密码。另外，从该媒体集执行任何还原操作时也必须提供媒体密码。
注意：
只能对 SQL Server 备份和还原操作使用媒体。
若要指定媒体集密码，请在 BACKUP 或 RESTORE 语句中使用 MEDIAPASSWORD 选项。
7.3.2 备份集密码
它对特定的备份集提供较弱的保护。可以对媒体上的每个备份集使用不同的备份集密码。备份集密码是在将备份集写入媒体时创建的。如果为一个备份集指定了密码，必须提供这个密码才能对该备份集执行任何还原操作。
若要指定备份集密码，请在 BACKUP 或 RESTORE 语句中使用 PASSWORD 选项。
7.4 仅还原来自受信任源的备份
建议您不要从未知或不可信源附加或还原数据库。这些数据库可能包含恶意代码，这些代码可能会执行非预期 Transact-SQL 代码，或者通过修改架构或物理数据库结构导致错误。使用来自未知或不可信来源的数据库前，请在非生产服务器上对该数据库运行 DBCC CHECKDB。另外，还要检查该数据库中的代码，如存储过程或其他用户定义代码。
8. 优化 SQL Server 中的备份和还原性能
介绍如何优化数据备份、差异备份、事务日志备份、还原操作以及备份设备的性能。
Microsoft SQL Server 提供了以下两种加速备份和还原操作的方式：
使用多个备份设备使得可以将备份并行写入所有设备。备份设备的速度是备份吞吐量的一个潜在瓶颈。使用多个设备可以按使用的设备数成比例提高吞吐量。同样，可以将备份并行从多个设备还原。有关详细信息，请参阅本主题后面的“使用多个介质或设备”。
结合使用完整备份、差异备份（对于完整恢复模式或大容量日志恢复模式）以及事务日志备份可以最大程度地缩短恢复时间。创建差异数据库备份通常比创建完整数据库备份快，并减少了恢复数据库所需的事务日志量。有关详细信息，请参阅创建 SQL Server 数据库的完整备份和差异备份。
8.1 使用多个介质或设备
通过读取器/写入器线程将数据和事务日志从备份设备复制到数据库和事务日志文件；给每个备份设备指派一个线程。性能受备份设备传送数据的能力或数据库和事务日志文件接收数据的能力的限制。因此，性能随备份设备数量的增加而提升，直到达到数据库或事务日志文件接收数据的最大吞吐量。
使用多个备份设备进行备份和还原操作，SQL Server 可以使用并行 I/O 来提高备份和还原操作的速度，因为每个备份设备都可以与其他备份设备同时执行写操作或读操作。对于具有大型数据库的企业，使用多个备份设备可以明显减少执行备份和还原操作所花的时间。SQL Server 最多支持 64 个备份设备同时执行一个备份操作。
当一个备份写入多个备份设备时，会出现几个内部同步点。最重要的同步点在已备份完数据库内的所有数据且即将开始备份事务日志时出现。
重要提示：
使用多个备份设备执行备份操作时，所用的备份介质只能用于 SQL Server 备份操作。有关详细信息，请参阅使用备份媒体。
使用多个备份设备创建和还原备份与使用单个设备创建和还原备份相同。唯一的区别是使用多个备份设备时，必须指定操作中用到的所有备份设备，而不是仅指定一个。例如，如果使用三个磁带备份设备（如 \\\\.\\TAPE0、\\\\.\\TAPE1 和 \\\\.\\TAPE2）创建数据库备份，则必须将每个磁带设备指定为备份操作的一部分，尽管以后还原和备份时很少会用到这些磁带备份设备。
使用可移动介质在多个备份设备上创建备份时，这些设备可以以不同的速度运行，介质卷的可用空间也可以有所不同。在备份操作过程中，如果备份设备上介质卷的空间已用完，此操作将停止对该设备执行写操作并提示您更换新的介质卷。该设备将处于阻塞状态，直到您使用空卷替换空间已满的介质卷。与此同时，备份操作继续向其介质仍具有可用空间的设备写入数据。替换空间已满的介质卷后，该设备将变为可用，备份继续向该设备写入数据。但是，请注意，如果在任何设备阻塞时出现内部同步点，整个备份操作将暂停，直到该设备再次可用。
8.1.1 示例
请考虑使用三个相同速度的磁带备份设备存储完整数据库备份的方案。前两个磁带有 10 GB 的可用空间，而第三个磁带只有 5 GB 的可用空间。如果将 20 GB 的数据库同时备份到这三个磁带备份设备上，第三个磁带将在备份完成之前填满。5 GB 的数据写入第三个磁带后，备份操作将立即停止对第三个设备执行写操作。备份操作将阻塞该设备，并提示您更换新的磁带。与此同时，备份操作继续向另两个设备写入数据。但是，在更换第三个磁带之前，会出现内部同步点。此时，整个备份操作将暂停，直到第三个设备中装入了新磁带。
8.2 优化完整备份和差异备份的性能
创建完整备份或差异备份包含以下步骤：
1. 将数据库文件中的数据复制到备份设备。
2. 复制事务日志中用于将数据库前滚到与相同的备份设备状态一致的那部分。
创建差异备份与创建完整备份相同，不过创建差异备份仅复制更改的数据。备份数据库文件只需把文件中的数据复制到备份设备。
用于存储数据库的数据库文件按磁盘设备排序，并给每个设备指派读取器线程。该读取器线程从数据库文件中读取数据。给每个备份设备指派写入器线程。写入器线程将数据写入备份设备。通过在更多的逻辑驱动器中分布数据库文件可以增加并行读取操作。同样，通过使用更多的备份设备可以增加并行写操作。 一般情况下，瓶颈要么是数据库文件，要么是备份设备。如果读取吞吐总量比备份设备吞吐总量大，则瓶颈在备份设备这一侧。添加更多的备份设备（如果必要还添加 SCSI 控制器）可以提高性能。但是，如果备份吞吐总量比读取吞吐总量大，则应通过添加更多数据库文件或设备（或通过添加更多磁盘到 RAID 设备）以增加读取吞吐量。
8.3 优化事务日志备份性能
创建事务日志备份只需将日志中尚未备份的部分复制到备份设备。虽然可能有多个事务日志文件，但事务日志在逻辑上是某个线程按顺序读取的一个流。 给每个备份设备指派写入器线程。通过添加更多的备份设备可以获得更高的性能。
瓶颈既可能是包含事务日志文件的磁盘设备也可能是备份设备，这取决于它们的相对速度和所使用备份设备的数量。添加更多备份设备可以使性能呈线性增长，直到达到包含事务日志文件的磁盘设备的最大容量，此后只有提高包含事务日志的磁盘设备的速度（例如，使用磁盘条带化），才能得到更多的性能收益。
8.4 优化还原性能
还原数据库备份或差异备份包括四个步骤：
1. 创建数据库和事务日志文件（如果它们不存在）。 2. 将数据从备份设备复制到数据库文件。 3. 从事务日志文件复制事务日志。
4. 前滚事务日志，然后（如果需要）重新启动恢复。
应用事务日志备份包括两个步骤：
1. 将数据从备份设备复制到事务日志文件。 2. 前滚事务日志。
还原数据库文件包括两个步骤：
1. 创建所有丢失的数据库文件。 2. 将数据从备份设备复制到数据库文件。
8.5 文件初始化
如果数据库和事务日志文件还不存在，必须先创建它们才能将数据还原到其中。创建数据库和事务日志文件并将文件内容初始化为零。单独的工作线程并行创建和初始化文件。按磁盘设备排序数据库和事务日志文件，并给每个磁盘设备指派单独的工作线程。创建和初始化文件需要很大的吞吐量，因此在可用的逻辑驱动器中均匀分布文件能产生最佳性能。
8.6 即时文件初始化
在 SQL Server 2005 及更高版本中，可以即时初始化数据文件，因而可以快速执行数据库或文件组还原操作。即时文件初始化功能将收回使用的磁盘空间，不会使用零填充。而是，新数据写入文件时覆盖磁盘内容。日志文件初始化仍需要零位调整，但此操作将与从备份传输数据并行进行。传输所有数据并初始化整个日志之前，不能开始还原的前滚步骤。
注意：
只有在 Microsoft Windows XP、Windows Server 2003 或更高的系统中才可以使用即时文件初始化功能。
若要使用即时文件初始化，必须在 Windows 帐户下运行 MSSQLSERVER 服务帐户并为该 Windows 帐户分配 Windows SE_MANAGE_VOLUME_NAME 特权。此权限默认情况下分配给 Windows 管理员组。如果拥有系统管理员权限，您可以通过将 Windows 帐户添加到“执行卷维护任务”安全策略来分配此权限。有关分配用户权限的详细信息，请参阅 Windows 文档。
8.7 优化磁带备份设备性能
有多个变量影响磁带备份设备的性能，并使 SQL Server 备份和还原性能操作随磁带设备的添加大致呈线性增长：
软件数据块大小。
共享一个小型计算机系统接口 (SCSI) 总线的磁带设备数。 磁带设备类型。
软件数据块大小是由 SQL Server 为最佳性能计算的，不应更改。最大 BLOCKSIZE 为 64 KB。
许多高速磁带机如果对每个所使用的磁带机有专用 SCSI 总线，将运行得更好。本机传输速率超过 SCSI 总线速度的 50% 的驱动器必须在专用 SCSI 总线上，以避免降低性能。有关影响磁带机性能的设置的更多信息，请参阅磁带机供应商文档。
重要提示：
永远不要将磁带机与磁盘或 CD-ROM 驱动器放置在同一个 SCSI 总线上。对这些设备的错误处理操作互不兼容。
对已加载的磁带执行多个备份操作时，可以通过指定 NOREWIND 来提高性能。此选项导致 SQL Server 在完成备份操作后使磁带保持打开状态。NOREWIND 意即 NOUNLOAD。
8.8 优化磁盘备份设备性能
磁盘备份设备的原始 I/O 速度影响磁盘备份设备性能，并使 SQL Server 备份和还原性能操作随磁盘设备的添加大致呈线性增长：
对磁盘备份设备使用 RAID 时需认真考虑。例如，RAID 5 的写入性能低，大致与单个磁盘的速度相同（由于必须维护奇偶信息）。另外，将数据追加到文件的原始速度明显比原始设备写入速度慢。
如果将备份设备高度条带化，以便使对备份设备的最大写入速度远远超过备份设备将数据追加到文件的速度，则在相同的条带集上放置几个逻辑备份设备会比较合适。换句话说，可以通过在相同的逻辑驱动器上放置几个备份介质家族来提高备份性能。然而，需要采用经验方法确定这对每个环境是收益还是损失。通常情况下，最好将每个备份设备放置在单独的磁盘设备上。
一般在 SCSI 总线上只有少数几个磁盘可以最大速度运行，但 Ultra-wide 和 Ultra-2 总线可以处理更多磁盘。不过，很可能需要认真配置硬件以获得最佳性能。
有关影响磁盘性能的设置的更多信息，请参阅磁盘供应商文档。
8.9 数据压缩
如今的磁带机有内置的硬件数据压缩，可显著提高将数据传送到驱动器的有效传送速率。数据库内实数据的可压缩性取决于数据本身和所使用的磁带机。对于大范围的数据库，典型的数据压缩率是从 1.2:1 到 2:1。该压缩率对于在多种业务应用程序中使用的数据是典型的，但有些数据库可能有更高或更低的压缩率。例如，主要包含已压缩图像的数据库将不能再由磁带机进一步压缩。有关数据压缩的更多信息，请参阅磁带机供应商文档。
默认情况下，SQL Server 支持硬件压缩，但可以使用 3205 跟踪标志禁用硬件压缩。在极少数情况下，禁用硬件压缩可以提高备份性能。例如，如果数据已经完全压缩，禁用硬件压缩可防止磁带机浪费时间试图进一步压缩数据。 有关跟踪标志的详细信息，请参阅跟踪标志 (Transact-SQL)。
8.10 备份压缩
默认情况下，使用备份压缩进行备份会显著增加 CPU 使用率，并且压缩进程占用的额外 CPU 可能会对并发操作造成不利影响。因此，您可能需要在会话中创建低优先级的压缩备份，当发生 CPU 争用时，此备份的 CPU 使用率受资源调控器限制。有关详细信息，请参阅如何使用资源调控器限制备份压缩的 CPU 使用量 (Transact-SQL)。
8.11 传送到磁带的数据量
创建数据或差异备份只捕获数据库中包含实际数据的部分，而不备份未使用的空间。其结果将使备份操作的速度更快。
虽然您可以根据需要将 SQL Server 数据库配置为自动增长，但是也可以继续保留数据库内的空间以保证它可用。保留数据库内的空间对备份吞吐量和备份数据库所需的总时间没有负面影响。
8.12 优化日志传送同步
尝试同步日志传送目标时，不必在 RESTORE LOG 步骤之间使用 WITH STANDBY。
9. 了解 SQL Server 的恢复性能
包含有关崩溃恢复过程中的性能信息以及如何提高恢复已还原数据性能
的信息。
恢复性能主要与崩溃恢复而不是还原备份后的恢复相关。但是，也可能对从备份还原后的恢复进行优化。
恢复时间是由从上一次检查点之后做了多少工作和在数据丢失时所有活动事务做了多少工作共同决定的。SQL Server 使用名为 recovery interval 的配置选项设置 SQL Server 恢复数据库时每个数据库所用的近似最大分钟数。此 recovery interval 设置控制检查点的频率。对于联机事务处理 (OLTP) 系统（使用短事务的系统），recovery interval 是确定恢复时间的主要因素。 安装完成后，SQL Server 将 recovery interval 设置为零。只要 recovery interval 的设置是默认设置，而且没有长时间运行的事务，则恢复每个数据库大约需要一分钟或更少的时间。恢复还原的数据时，如果长时间运行的事务在数据丢失时是活动的，那么恢复时间就由回滚这些事务的效果花费的时间控制。但
是，在 SQL Server 2005 及更高版本中，数据库在崩溃恢复的撤消阶段或数据库镜像故障转移阶段可用，此功能称为“快速恢复”。
如果一个数据库的常规恢复所用时间远长于 1 分钟，recovery interval 设置为零，而且没有要回滚的长时间运行的事务，那么请与您的主要支持提供商联系，以解决这个恢复性能的问题。
恢复根据数据库的虚拟日志文件报告进度。在恢复开始时，从上一个检查点恢复分析和扫描日志。根据分析阶段的结果，恢复估计在恢复过程中将会读取多少日志。读取的日志量用于报告恢复进度。
如果 recovery interval 设置不再是默认值，那么完成数据库恢复所用时间要长多倍。例如，如果 recovery interval 更改为 10，那么完成恢复所用时间大约比 recovery interval 为默认设置零时长 10 倍。
日志增大时，需要使用较大（而非较小）的增量来确保 SQL Server 的启动时间较短。日志增量越小，SQL Server 对其进行初始化的时间越长。
还原操作后恢复时，如果长时间运行的事务已终止，就让服务器完成回滚进程。在回滚长时间运行的事务时终止服务器进程会导致恢复时间较长。如果关注回滚进程的长度，请询问系统管理员以确认活动是在服务器上发生的。
如果当前有长时间运行的事务而且其间发生了崩溃，则 SQL Server 开始恢复进程。在这种情况下，由于数据库在撤消阶段可用，因此恢复速度会加快。 有关在完整恢复模式下从备份还原数据时减少恢复时间的方法，请参阅减少还原数据库时所用的恢复时间。
10. 在大型重要环境中备份和还原
介绍几种提高备份和还原操作速度（尽可能减少两种操作对用户造成的影响）的方法。
本主题仅与在完整恢复模式或大容量恢复模式下包含多个文件组的数据库有关。 重要环境通常要求数据库连续可用，或者在最短中断时间内完成维护任务并在更长时间可用。因此，在需要还原数据库的情况下，花费的时间必须尽可能的短。另外，重要数据库通常很大，需要较长的时间进行备份和还原。SQL Server 提供了几种提高备份和还原操作速度的方法，从而将进行这两种操作时对用户造成的影响降到最小。
注意：
还原是一项修复功能，而非可用性功能。重要数据库需要制订可用性计划。有关
高可用性功能的信息，请参阅高可用性解决方案概述。 下列做法对您有所帮助：
同时使用多个备份设备，使得备份可以同时写入所有设备。同样，也可以同时从多个设备还原备份。有关在条带媒体集（条带集）中使用备份设备的信息，请参阅 BACKUP (Transact-SQL) 中的“备注”。
请考虑使用镜像媒体集。每个媒体集可能总共包含四个镜像。对于镜像媒体集，备份操作写入到多组备份设备。每组备份设备组成镜像媒体集中的一个镜像。每个镜像都必须使用相同数量和类型的物理备份设备，而且这些设备必须具有相同的属性。有关使用镜像媒体集的信息，请参阅使用镜像备份介质集以及 BACKUP (Transact-SQL) 中的“备注”。
在完整恢复模式下，组合使用数据库备份、差异数据库备份和事务日志备份可以将数据库恢复至故障点所需备份数减到最少。
使用文件和文件组备份以及事务日志备份。利用这些备份，您可以只备份或还原那些包含相关数据的文件，而不必备份或还原整个数据库。 使用快照备份将备份和还原时间减到最少。第三方供应商支持快照备份。有关详细信息，请参阅快照备份。
11. 适用于独立软件供应商的备份和还原 API
介绍独立软件供应商 (ISV) 可用于将 SQL Server 备份和还原功能集成到其产品中的 API。
本主题适用于独立软件供应商 (ISV)。
注意：
如果您使用的是第三方备份解决方案并对如何将其与 Microsoft SQL Server 集成感兴趣，请与备份解决方案供应商联系。
许多第三方备份解决方案都支持 Microsoft SQL Server。SQL Server 提供的应用程序编程接口使 ISV 可以将 SQL Server 集成到他们的产品中。这些 API 具有最高的可靠性和最佳性能，并支持 SQL Server 的全部备份和还原功能。 有关如何访问这些示例和相关文档的信息，请参阅 Microsoft 下载中心上的 SQL Server 2005 虚拟备份设备接口 (VDI) 规范。
12. 重新生成系统数据库
描述如何重新生成系统数据库，例如在更改数据库引擎实例的默认排序规则时。
必须重新生成系统数据库才能修复 master、model、msdb 或 resource 系统数据库中的损坏问题或者修改默认的服务器级排序规则。本主题提供如何重新生成系统数据库的分步说明。
12.1 重新生成系统数据库之前
重新生成 master、model、msdb 和 tempdb 系统数据库时，将删除这些数据库，然后在其原位置重新创建它们。如果在重新生成语句中指定了新排序规则，则将使用该排序规则设置创建系统数据库。用户对这些数据库所做的所有修改都会丢失。例如，您在 master 数据库中的用户定义对象、msdb 中的预定作业或 model 数据库中对默认数据库设置的更改都会丢失。
在重新生成系统数据库之前执行下列任务，以确保可以将系统数据库还原至它们的当前设置。
1. 记录所有服务器范围的配置值。
复制代码
SELECT * FROM sys.configurations;
2. 记录所有应用到 SQL Server 实例和当前排序规则的 Service Pack 和修补程序。重新
生成系统数据库后必须重新应用这些更新。
复制代码
SELECT
SERVERPROPERTY('ProductVersion ') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ResourceVersion') AS ResourceVersion, SERVERPROPERTY('ResourceLastUpdateDateTime') AS ResourceLastUpdateDateTime,
SERVERPROPERTY('Collation') AS Collation;
3. 记录系统数据库的所有数据文件和日志文件的当前位置。重新生成系统数据库会将
所有系统数据库安装到其原位置。如果已将系统数据库数据文件或日志文件移动到其他位置，则必须重新移动这些文件。
复制代码
SELECT name, physical_name AS current_file_location FROM sys.master_files
WHERE database_id IN (DB_ID('master'), DB_ID('model'), DB_ID('msdb'), DB_ID('tempdb'));
4. 找到 master、model 和 msdb 数据库的当前备份。
5. 如果将 SQL Server 的实例配置为复制分发服务器，请找到该分发数据库的当前备
份。 6. 确保您有重新生成系统数据库的相应权限。必须是 sysadmin 固定服务器角色的成
员才能执行此操作。有关详细信息，请参阅服务器级别角色。 7. 请验证本地服务器上是否有 master、model、msdb 数据模板文件和日志模板文件
的副本。模板文件的默认位置是 C:\\Program Files\\Microsoft SQL Server\\MSSQL10_50.MSSQLSERVER\\MSSQL\\Binn\\Templates。在重新生成过程中要用到这些文件，而且若想让安装成功这些文件就必须存在。如果缺少这些文件，请运行安装程序的“修复”功能或者手动从安装介质中复制这些文件。若要在安装介质上查找这些文件，请导航到相应的平台目录（x86、x64 或 ia64），然后导航到
12.2 系统数据库重新生成过程
以下过程将重新生成 master、model、msdb 和 tempdb 系统数据库。无法指定要重新生成哪些系统数据库。对于群集实例，必须在活动节点上执行此过程。此过程不重新生成 resource 数据库。请参阅本主题后面的“resource 数据库重新生成过程”部分。
重新生成 SQL Server 2008 实例的系统数据库：
1. 将 SQL Server 2008 安装介质插入到磁盘驱动器中，或者在本地服务器上，从命令提示符处将目录更改为 setup.exe 文件的位置。在服务器上的默认位置为 C:\\Program Files\\Microsoft SQL Server\\100\\Setup Bootstrap\\Release。
2. 在命令提示符窗口中，输入以下命令。方括号用来指示可选参数。不要输入括号。在使用 Windows Vista 操作系统且启用了用户帐户控制 (UAC) 时，运行安装程序需要提升的特权。必须以管理员身份运行命令提示符。 Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName /SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ] [ /SQLCOLLATION=CollationName]
参数名称 说明 /QUIET 或 /Q 指定在没有任何用户界面的情况下运行安装程序。 /ACTION=REBUILDDATABASE 指定安装程序将重新创建系统数据库。 是 SQL Server 实例的名称。对于默认实例，请输入 /INSTANCENAME=实例名称 MSSQLSERVER。对于命名实例，请以 server_name\\instance_name 格式输入其名称。 指定要添加到 sysadmin 固定服务器角色中的 Windows 组或单个帐户。指定多个帐户时，请用空格/SQLSYSADMINACCOUNTS=帐将帐户隔开。例如，请输入 BUILTIN\\Administrators 户 MyDomain\\MyUser。当您在帐户名称内指定包含空格的帐户时，用双引号将该帐户引起来。例如，输入 NT AUTHORITY\\SYSTEM。 指定 SQL Server sa 帐户的密码。如果实例使用混合身份验证（SQL Server 和 Windows 身份验证）模式，则此参数是必需的。 [ /SAPWD=强密码 ] 安全说明： sa 帐户是一个广为人知的 SQL Server 帐户，并且经常成为恶意用户的攻击目标。因此，为 sa 登录名使用强密码非常重要。 不要为 Windows 身份验证模式指定此参数。 指定新的服务器级排序规则。此参数可选。如果没有指定，则使用服务器的当前排序规则。 重要提示： [ /SQLCOLLATION=排序规则更改服务器级排序规则不会更改现有用户数据库的排序规名称 ] 则。默认情况下，所有新创建的用户数据库都将使用新排序规则。 有关详细信息，请参阅设置和更改服务器排序规则。 3. 在安装程序完成系统数据库重新生成后，它将返回到命令提示符，而且不
显示任何消息。请检查 Summary.txt 日志文件以验证重新生成过程是否成功完成。此文件位于 C:\\Program Files\\Microsoft SQL Server\\100\\Setup Bootstrap\\Logs。
12.3 重新生成后的任务
重新生成数据库后，您可能需要执行以下额外任务：
应用最新的 Service Pack 和任何适用的修补程序。
还原 master、model 和 msdb 数据库的最新完整备份。有关详细信息，请参阅备份和还原系统数据库的注意事项。
重要提示：
如果更改了服务器排序规则，请不要还原系统数据库。否则，将使新排序规则替换为以前的排序规则设置。
如果没有备份或者还原的备份不是最新的，请重新创建所有缺失的条目。例如，重新创建用户数据库、备份设备、SQL Server 登录名、端点等缺少的所有条目。重新创建这些条目的最佳方法是运行创建它们的原始脚本。
安全说明：
建议您保护好脚本，以防未经授权的人员更改脚本。
如果将 SQL Server 实例配置为复制分发服务器，则必须还原分发数据库。有关详细信息，请参阅备份和还原复制的数据库。
将系统数据库移到您以前记录的位置。有关详细信息，请参阅移动系统数据库。 验证服务器范围的配置值是否与您以前记录的值相符。
12.4 resource 数据库重新生成过程
以下过程将重新生成 resource 系统数据库。重新生成 resource 数据库时，所有的 Service Pack 和修补程序都将丢失，因此必须重新应用。
重新生成 resource 系统数据库：
1. 从 SQL Server 2008 分发介质中启动 SQL Server 安装程序 (setup.exe)。
2. 在左侧导航区域中单击“维护”，然后单击“修复”。
3. 安装程序支持规则和文件例程将运行，以确保您的系统上安装了必备组件，并且计算机能够通过安装程序验证规则。单击“确定”或“安装”以继续操作。
4. 在“选择实例”页上，选择要修复的实例，然后单击“下一步”。 5. 将运行修复规则以验证修复操作。若要继续，请单击“下一步”。
6. 在“准备修复”页上，单击“修复”。“完成”页指示修复操作已完成。
12.5 重新生成错误疑难解答
语法和其他运行时错误会显示在命令提示符窗口中。检查 Setup 语句中是否存在以下语法错误：
每个参数名称前面缺少斜杠标记 (/)。 参数名称和参数值之间缺少等号 (=)。 参数名称和等号之间存在空格。
存在逗号 (,) 或语法中未指定的其他字符。
重新生成操作完成后，请检查 SQL Server 日志中是否存在任何错误。默认的日志位置是 C:\\Program Files\\Microsoft SQL Server\\100\\Setup Bootstrap\\Logs。若要查找包含重新生成过程的结果的日志文件，请从命令提示符处将目录更改到“Logs”文件夹，然后运行 findstr /s RebuildDatabase summary*.*。此搜索将引导您找到包含系统数据库重新生成结果的所有日志文件。打开日志文件，检查其中有无相关错误消息。
13. 使用备用服务器
当日志传送配置的主服务器开始不可用时，辅助服务器上的所有辅助数据库可能不会完全同步。在主服务器上创建的一些事务日志备份可能尚未应用于辅助服务器。而且，上次事务日志备份之后，主服务器上的数据库可能已发生更改。在使用备用数据库之前，同步主数据库和备用数据库，并按照下列步骤将备用服务器设置为联机：
1. 按顺序将主服务器上创建的未应用的事务日志备份应用到备用服务器。 2. 在主服务器上创建活动事务日志的备份，并将该备份应用于备用服务器上的数据库。将活动事务日志的备份应用于备用服务器时，可以使用户使用故障发生前一刻的主数据库副本，但所有未提交的事务均永久丢失。有关详细信息，请参阅使用事务日志备份。 3. 恢复备用服务器上的数据库。此操作将在不创建备用文件的情况下恢复数据库，使用户可以修改数据库。 4. 如果主服务器没有损坏，则在计划的维护或升级发生时，可以使用 NORECOVERY 备份活动事务日志。这样可以使数据库保持还原状态。有关详细信息，请参阅结尾日志备份。
5. 也可以使用辅助服务器的事务日志备份更新主服务器。然后便可以切换回主服务器，而不必备份和还原辅助数据库。有关详细信息，请参阅应用事务日志备份。 若要减少资源需求，可以在一台备用服务器上存储来自多台主服务器的数据库备份。例如，有一个部门使用了多台主服务器，并且其中每台服务器都在运行重要的数据库系统。此部门的计算环境经过配置，以尽可能地降低多台主服务器同时出现故障的可能性。在这五台主服务器上，每台服务器的最近数据库备份都已复制到一台公用的备用服务器上。为了解决会对主服务器产生影响的并发故障这个可能发生的问题，需要优先指定备用服务器，而不是主服务器。如果任何一台主服务器发生了严重的故障，则都可以从备用服务器还原并恢复其数据库备份。
14. 当数据库在其他服务器实例上可用时管理元数据
本主题适用于使用 Microsoft SQL Server 2005 和更高版本的下列情况：
设置数据库镜像。
准备在日志传送配置中交换主服务器和辅助服务器的角色。 将数据库还原到其他服务器实例。 在其他服务器实例上附加数据库副本。
某些应用程序依赖于单个用户数据库范围之外的信息、实体和/或对象。通常，应用程序具有对 master 和 msdb 数据库的依赖关系，并且还具有对用户数据库的依赖关系。用户数据库正确运行所需的存储在该数据库外部的任何内容必须在目标服务器实例上可用。例如，应用程序的登录名作为元数据存储在 master 数据库中，您必须在目标服务器上重新创建这些登录名。如果应用程序或数据库维护计划依赖于 SQL Server 代理作业（其元数据存储在 msdb 数据库中），则必须在目标服务器实例上重新创建这些作业。同样，服务器级触发器的元数据存储在 master 中。
将应用程序的数据库移动到其他服务器实例时，必须在目标服务器实例的
master 和 msdb 中重新创建依赖实体和依赖对象的所有元数据。例如，如果数据库应用程序使用服务器级触发器，则仅在新系统上附加或还原数据库是不够的。如果不手动在 master 数据库中重新创建这些触发器的元数据，则数据库不能按预期方式工作。
14.1 存储在用户数据库外部的信息、实体和对象
此主题的其余部分概要说明了可能影响在其他服务器实例上可用的数据库的潜在问题。最好重新创建以下列表中列出的一种或多种信息、实体或对象。若要查看概要内容，请单击该项的链接。
服务器配置设置 凭据 跨数据库查询 数据库所有权
分布式查询/链接服务器 加密数据
用户定义的错误消息
事件通知和 Windows Management Instrumentation (WMI) 事件（服务器级） 扩展存储过程
SQL Server 属性的全文引擎 作业 登录名 权限 复制设置
Service Broker 应用程序 启动过程
触发器（服务器级）
14.2
服务器配置设置
SQL Server 2005 及更高版本会选择性地安装和启动密钥服务和功能。这有助于减少系统可遭受攻击的外围应用。在新安装的默认配置中，许多功能并未启用。
如果数据库依赖于默认处于禁用状态的服务或功能，则必须在目标服务器实例上启用此服务或功能。
有关这些设置以及启用或禁用它们的详细信息，请参阅了解外围应用配置器和设置服务器配置选项。 [返回页首]
14.3 凭据
凭据是包含连接到 SQL Server 以外的资源时所需的身份验证信息的记录。大多数凭据包含一个 Windows 登录名和密码。
有关此功能的详细信息，请参阅凭据（数据库引擎）。
注意：
SQL Server 代理的代理帐户使用凭据。若要了解代理帐户的凭据 ID，请使用 sysproxies 系统表。
14.4 跨数据库查询
DB_CHAINING 和 TRUSTWORTHY 数据库选项默认设置为 OFF。如果针对原始数据库将这两个选项之一设置为 ON，则可能必须对目标服务器实例上的数据库启用这两个选项。有关详细信息，请参阅 ALTER DATABASE (Transact-SQL)。 在 SQL Server 2000 Service Pack 3 (SP3) 和更高版本的 SQL Server 中，附加和分离操作会禁用数据库的跨数据库所有权链接。有关如何启用链接的信息，请参阅 cross db ownership chaining 选项。 有关详细信息，请参阅：
所有权链
使用 EXECUTE AS 扩展数据库模拟
如何将镜像数据库设置为使用 Trustworthy 属性
[返回页首]
14.5 数据库所有权
在其他计算机上还原数据库时，启动还原操作的 SQL Server 登录用户或 Windows 用户将自动成为新数据库的所有者。还原数据库时，系统管理员或新数据库所有者可以更改数据库所有权。
14.6 分布式查询和链接服务器
OLE DB 应用程序支持分布式查询和链接服务器。分布式查询访问相同或不同计算机上多个异类数据源中的数据。链接服务器配置使 SQL Server 可以对远程服务器上的 OLE DB 数据源执行命令。有关这些功能的详细信息，请参阅分布式查询、链接服务器和从链接服务器中获取元数据。
14.7 加密数据
如果在其他服务器实例上可用的数据库包含加密数据，并且数据库主密钥由原始服务器上的服务主密钥保护，则最好重新进行服务主密钥加密。“数据库主密钥”是一种对称密钥，用于在加密数据库中保护证书的私钥和非对称密钥的私钥。当创建数据库主密钥时，会使用 Triple DES 算法以及用户提供的密码对其进行加密。
若要对服务器实例上的数据库主密钥启用自动解密，请使用服务主密钥对此密钥的副本进行加密。此加密副本存储在此数据库以及 master 中。通常，每当主密钥更改时，便会在不进行提示的情况下更新存储在 master 中的副本。SQL Server 首先尝试使用实例的服务主密钥对数据库主密钥进行解密。如果解密失败，则 SQL Server 将搜索凭据存储区以查找与需要主密钥的数据库具有相同系列 GUID 的主密钥凭据。然后，SQL Server 尝试使用每个匹配的凭据对数据库主密钥进行解密，直到成功解密或者不再有凭据为止。必须使用 OPEN MASTER KEY 语句和密码打开未使用服务主密钥进行加密的主密钥。
对加密数据库执行复制、还原或附加到新的 SQL Server 实例等操作时，由服务主密钥加密的数据库主密钥的副本不存储在目标服务器实例上的 master 中。在目标服务器实例上，必须打开数据库的主密钥。若要打开主密钥，请执行以下语句：OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password'。建议您通过执行下面的语句对数据库主密钥启用自动解密：ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY。此 ALTER MASTER KEY 语句使用数据库主密钥（使用服务主密钥加密）的副本来设置服务器实例。有关详细信息，请参阅 OPEN MASTER KEY (Transact-SQL) 和 ALTER MASTER KEY (Transact-SQL)。
有关如何对镜像数据库的数据库主密钥启用自动解密的信息，请参阅设置加密的镜像数据库。
有关详细信息，请参阅：
加密层次结构 设置加密的镜像数据库
如何在两个服务器上创建相同的对称密钥
[返回页首]
14.8 用户定义的错误消息
用户定义的错误消息位于 sys.messages 目录视图中。此目录视图存储在
master 中。如果数据库应用程序依赖于用户定义的错误消息并且此数据库在其他服务器实例上可用，则请使用 sp_addmessage 在目标服务器实例上添加这些用户定义的消息。 [返回页首]
14.9 事件通知和 Windows Management
Instrumentation (WMI) 事件（服务器级） 14.9.1 服务器级事件通知
服务器级事件通知存储在 msdb 中。因此，如果数据库应用程序依赖于服务器级事件通知，则必须在目标服务器实例上重新创建该事件通知。若要查看服务器实例上的事件通知，请使用 sys.server_event_notifications 目录视图。有关详细信息，请参阅事件通知（数据库引擎）。
此外，使用 Service Broker 传递事件通知。传入消息的路由不包括在包含服务的数据库中。相反，显式路由存储在 msdb 中。如果服务使用 msdb 数据库中的显式路由将传入的消息路由到该服务，则在将数据库附加到其他实例时，必须重新创建此路由。有关详细信息，请参阅 Service Broker 路由。 设置用于远程消息传递的数据库
迁移 (Service Broker)
14.9.2 Windows Management Instrumentation (WMI) 事件
使用服务器事件的 WMI 提供程序，可以使用 Windows Management Instrumentation (WMI) 监视 SQL Server 中的事件。必须在目标服务器实例所在的计算机上定义任何依赖于服务器级事件（此事件通过数据库所依赖的 WMI 提供程序显示）的应用程序。WMI 事件提供程序使用在 msdb 中定义的目标服务创建事件通知。
注意：
有关详细信息，请参阅 WMI Provider for Server Events 的概念。
使用 SQL Server Management Studio 创建 WMI 警报
如何创建 WMI 事件警报 (SQL Server Management Studio)
14.9.3 镜像数据库事件通知工作原理
因为镜像数据库可以进行故障转移，所以涉及镜像数据库的事件通知的跨数据库传递是按照定义以远程方式进行的。Service Broker 以“镜像路由”的形式为镜像数据库提供特殊支持。镜像路由有两个地址：一个针对主体服务器实例，另一个针对镜像服务器实例。
通过设置镜像路由，您可以使 Service Broker 路由支持数据库镜像。使用镜像路由，Service Broker 能够透明地将会话重定向到当前的主体服务器实例。例如，有一项由镜像数据库 Database_A 承载的服务 Service_A。假定您需要由 Database_B 承载的另一项服务 Service_B 与 Service_A 进行对话。为了实现此对话，Database_B 必须包含 Service_A 的镜像路由。此外，Database_A 必须包含 Service_B 的非镜像 TCP 传输路由，与本地路由不同的是，该路由在故障转移后保持有效。这些路由使 ACK 能够在故障转移后恢复。由于发送方的服务始终以相同方式命名，因此路由必须指定 Broker 实例。
不管镜像数据库中的服务是发起方服务还是目标服务，下列情况均要求使用镜像路由：
如果目标服务位于镜像数据库中，则发起方服务必须具有返回目标的镜像路由。但是，目标可以具有返回发起方的常规路由。
如果发起方服务位于镜像数据库中，则目标服务必须具有返回发起方的镜像路由，以传递确认和应答。但是，发起方可能拥有指向目标的常规路由。
有关详细信息，请参阅：
Service Broker 路由
将警告阈值和警报用于镜像性能指标
[返回页首]
14.10 扩展存储过程
重要提示：
后续版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能，并着手修改当前还在使用该功能的应用程序。请改用 CLR 集成。
扩展存储过程使用 SQL Server 扩展存储过程 API 进行编程。sysadmin 固定服务器角色的成员可以使用 SQL Server 实例注册扩展存储过程，并授予用户执行此过程的权限。扩展存储过程只能添加到 master 数据库。
扩展存储过程直接在 SQL Server 实例的地址空间中运行，它们可能会引起内存泄漏或其他问题，从而降低服务器的性能和可靠性。您应考虑将扩展存储过程存储在独立于包含被引用数据的实例的 SQL Server 实例中。还应考虑使用分布式查询访问数据库。有关详细信息，请参阅分布式查询。
重要提示：
将扩展存储过程添加到服务器并向其他用户授予 EXECUTE 权限之前，系统管理员应全面查看每个扩展存储过程，以确保它不包含有害代码或恶意代码。有关详细信息，请参阅扩展存储过程。
有关详细信息，请参阅 GRANT 对象权限 (Transact-SQL)、DENY 对象权限 (Transact-SQL) 和 REVOKE 对象权限 (Transact-SQL)。 [返回页首]
14.11 SQL Server 属性的全文引擎
全文引擎的属性是通过 sp_fulltext_service 设置的。请确保目标服务器实例具有这些属性的必需设置。有关这些属性的详细信息，请参阅 FULLTEXTSERVICEPROPERTY (Transact-SQL)。
此外，如果原始服务器实例和目标服务器示例具有不同版本的断字符和词干分析器组件或全文搜索筛选器组件，则全文索引和查询的行为可能有所不同。此外，同义词库存储在特定于实例的文件中。您必须将这些文件的副本传输到目标服务器实例上的相同位置，或者在新的实例上重新创建这些文件。
注意：
将包含全文目录文件的 SQL Server 2005 数据库附加到 SQL Server 2008 服务器实例上时，会将目录文件从以前的位置与其他数据库文件一起附加，与在 SQL Server 2005 中一样。有关详细信息，请参阅全文搜索升级。
有关详细信息，请参阅：
备份和还原 SQL Server 2008 全文目录 数据库镜像和全文目录 段落还原和全文索引
[返回页首]
14.12 作业
如果数据库依赖于 SQL Server 代理作业，则必须在目标服务器实例上重新创建这些作业。作业取决于其环境。如果计划在目标服务器实例上重新创建现有作业，则可能必须修改目标服务器实例，以便与原始服务器实例上此作业的环境相匹配。下面是重要的环境因素：
作业使用的登录名
若要创建或执行 SQL Server 代理作业，首先必须将作业所需的所有 SQL Server 登录名添加到目标服务器实例。有关详细信息，请参阅如何配置用户以创建和管理 SQL Server 代理作业 (SQL Server Management Studio)。
SQL Server 代理服务启动帐户
服务启动帐户可以定义运行 SQL Server 代理的 Microsoft Windows 帐户及其网络权限。SQL Server 代理在指定的用户帐户下运行。代理服务的上下文会影响作业及其运行环境的设置。帐户必须有权访问作业所需的资源（如网络共享）。有关如何选择和修改服务启动帐户的信息，请参阅为 SQL Server 代理服务选择帐户。
为了正常操作，必须对服务启动帐户进行配置，使其具有正确的域、文件系统和注册表权限。此外，作业可能还需要必须针对服务帐户配置的共享网络资源。有关信息，请参阅设置 Windows 服务帐户。
SQL Server 代理服务与特定的 SQL Server 实例关联，具有自己的注册表配置单元，并且其作业通常与此注册表配置单元中的一个或多个设置具有依赖关系。若要按预期方式运行，作业需要这些注册表设置。如果使用脚本在其他 SQL Server 代理服务中重新创建一个作业，则此服务的注册表中可能没有用于该作业的正确设置。为使重新创建的作业在目标服务器实例上正常运行，原始和目标 SQL Server 代理服务应具有相同的注册表设置。
注意：
如果其他作业需要当前设置，则通过更改目标 SQL Server 代理服务上的注册表设置来处理重新创建的作业可能会出现问题。此外，错误编辑注册表可能会严重损坏您的系统。更改注册表项之前，建议您备份计算机中的所有重要数据。
SQL Server 代理的代理帐户
SQL Server 代理的代理帐户定义指定作业步骤的安全上下文。对于要在目标服务器实例上运行的作业，必须在此实例上手动重新创建此作业所需的所有代理。有关详细信息，请参阅创建 SQL Server 代理的代理帐户和排除使用代理的多服务器作业的故障。
有关详细信息，请参阅：
执行作业
在角色切换后管理登录名和作业（用于数据库镜像） 设置 Windows 服务帐户（安装 SQL Server 实例时） 配置 SQL Server 代理（安装 SQL Server 实例时） 实现 SQL Server 代理安全性
查看现有作业及其属性
监视作业活动
sp_help_job (Transact-SQL)
如何查看作业步骤信息 (SQL Server Management Studio) sysjobs (Transact-SQL)
创建作业
如何创建作业 (SQL Server Management Studio) 如何创建 SQL Server 代理作业 (Transact-SQL)
编写现有作业脚本
如何使用 Transact-SQL 编写作业脚本 (SQL Server Management Studio)
14.12.1.1 使用脚本重新创建作业的最佳实践
建议您首先编写简单作业的脚本，接下来在其他 SQL Server 代理服务上重新创建此作业，然后运行此作业以查看它是否按预期方式工作。这样便可确定不兼容性并尝试进行解决。如果已编写脚本的作业在新环境中未按预期方式工作，则建议您创建可在此环境中正常工作的等价作业。 [返回页首]
14.13 登录名
登录到 SQL Server 实例需要有效的 SQL Server 登录名。在身份验证过程中会使用此登录名，以验证主体是否可以连接到 SQL Server 实例。在服务器实例上未定义或错误定义了其相应 SQL Server 登录名的数据库用户无法登录到实例。这样的用户被称为此服务器实例上的数据库的“孤立用户”。当数据库还原、附加或复制到 SQL Server 的其他实例之后，数据库用户便可变为孤立用户。 若要为数据库原始副本中的部分或全部对象生成脚本，可以使用生成脚本向导，并在“选择脚本选项”对话框中将“编写登录脚本”选项设置为 True。有关详细信息，请参阅如何生成脚本 (SQL Server Management Studio)。 有关如何查看 SQL Server 登录名以及在服务器实例上检测并解析孤立用户的信息，请参阅孤立用户故障排除。
注意：
有关如何设置镜像数据库的登录名的信息，请参阅设置用于进行数据库镜像的登录帐户和在角色切换后管理登录名和作业。
[返回页首]
14.14 权限
当数据库在其他服务器实例上可用时，下列类型的权限可能受到影响。
对系统对象的 GRANT、REVOKE 或 DENY 权限
对服务器实例的 GRANT、REVOKE 或 DENY 权限（服务器级权限）
14.14.1 对系统对象的 GRANT、REVOKE 和 DENY 权限
对系统对象（例如存储过程、扩展存储过程、函数和视图）的权限存储在 master 数据库中，并且必须在目标服务器实例上进行配置。
若要为数据库原始副本中的部分或全部对象生成脚本，可以使用生成脚本向导，并在“选择脚本选项”对话框中将“编写对象级权限脚本”选项设置为 True。有关详细信息，请参阅如何生成脚本 (SQL Server Management Studio)。
重要提示：
如果编写登录脚本，则不编写密码的脚本。如果登录名使用 SQL Server 身份验证，则必须在目标上修改脚本。
在 sys.system_objects 目录视图中可以查看系统对象。在 master 数据库中的 sys.database_permissions 目录视图中可以查看对系统对象的权限。有关查询这些目录视图并授予系统对象权限的信息，请参阅 GRANT 系统对象权限 (Transact-SQL)。有关详细信息，请参阅 REVOKE 系统对象权限 (Transact-SQL) 和 DENY 系统对象权限 (Transact-SQL)。
14.14.2 对服务器实例的 GRANT、REVOKE 和 DENY 权限
服务器范围的权限存储在 master 数据库中，并且必须在目标服务器实例上进行配置。有关服务器实例的服务器权限的信息，请查询 sys.server_permissions 目录视图；有关服务器主体的信息，请查询 sys.server_principals 目录视图；有关服务器角色成员身份的信息，请查询 sys.server_role_members 目录视图。 有关详细信息，请参阅 GRANT 服务器权限 (Transact-SQL)、REVOKE 服务器权限 (Transact-SQL) 和 DENY 服务器权限 (Transact-SQL)。
14.14.2.1 证书或非对称密钥的服务器级权限
不能向证书或非对称密钥直接授予服务器级权限。相反，可以向专门针对特定证书或非对称密钥创建的映射登录名授予服务器级权限。因此，每个需要服务器级权限的证书或非对称密钥都需要自己的“证书映射登录名”或“非对称密钥映射登录名”。若要为证书或非对称密钥授予服务器级权限，请向其映射登录名授予相应权限。
注意：
映射登录名仅用于对使用相应证书或非对称密钥签名的代码进行授权。映射登录名不能用于身份验证。
映射登录名及其权限都位于 master 中。如果证书或非对称密钥位于 master 之外的数据库中，则必须在 master 中重新创建证书或非对称密钥并将其映射到登录名。如果将数据库移动、复制或还原到其他服务器实例，则必须在目标服务器实例的 master 数据库中重新创建其证书或非对称密钥，将证书或非对称密钥映射到登录名，并向此登录名授予必需的服务器级权限。 创建证书或非对称密钥
CREATE CERTIFICATE (Transact-SQL) CREATE ASYMMETRIC KEY (Transact-SQL)
将证书或非对称密钥映射到登录名
CREATE LOGIN (Transact-SQL)
为映射登录名分配权限
GRANT 服务器权限 (Transact-SQL)
有关证书和非对称密钥的详细信息，请参阅加密层次结构。 [返回页首]
14.15 复制设置
如果将复制数据库的备份还原到其他服务器或数据库，则无法保留复制设置。在这种情况下，您必须在还原备份后重新创建所有发布和订阅。为使此过程更加简单，请创建用于当前复制设置以及启用和禁用复制的脚本。有关详细信息，请参阅如何编写复制对象脚本 (SQL Server Management Studio)。为了帮助重新创建复制设置，请复制这些脚本，并更改服务器名称引用以用于目标服务器实例。 有关详细信息，请参阅备份和还原复制的数据库、复制和数据库镜像和复制和日志传送。 [返回页首]
14.16 Service Broker 应用程序
Service Broker 应用程序的许多相关内容都将随数据库一起移动。但是，应用程序的某些相关内容必须在新位置重新创建或重新配置。有关详细信息，请参阅迁移 (Service Broker)。 [返回页首]
14.17 启动过程
启动过程是指标记为自动执行并在每次启动 SQL Server 时执行的存储过程。如果数据库依赖于启动过程，则必须在目标服务器实例上定义这些启动过程并将其配置为启动时自动执行。
有关详细信息，请参阅自动执行存储过程。 [返回页首]
14.18 触发器（服务器级）
DDL 触发器激发存储过程以响应各种数据定义语言 (DDL) 事件。这些事件主要与以关键字 CREATE、ALTER 和 DROP 开头的 Transact-SQL 语句对应。执行 DDL 式操作的系统存储过程也可以激发 DDL 触发器。 有关此功能的详细信息，请参阅 DDL 触发器。 [返回页首]
因篇幅问题不能全部显示，请点此查看更多更全内容