SQL 问题与解答：备份和设置
SQL Server 是一个强大的平台，但需要在考虑事务日志设置和其他配置问题时注意技巧。
Paul S. Randal
XXXL 事务日志
**问：**我们的产品使用 SQL Server 来存储数据。我们会不时发布新的产品版本，其中包含针对数据库运行的升级脚本。由于我们在典型的测试数据库中测试我们最新的升级脚本，事务日志文件的大小增长到了 40GB 以上。我们希望阻止日志文件增长到如此之大。我们可以选择哪种方案？出于灾难恢复的目的，我们需要继续使用完整恢复模式。
**答：**首先，我很高兴得知您正在使用典型的客户数据进行测试。我多次发现分层应用程序供应商会使用小型数据集来测试这种脚本，然后即投入发行并提供给客户使用，而客户在生产过程中则会遇到各种各样的问题。如果您是用户，我会解答您的问题。然后您可以根据客户的具体情况来应用我的答案。
您说您需要继续使用完整恢复模式。这意味着您已进行事务日志备份，且您没有遇到事务日志增长失控等常见问题。这很好，因为进行事务日志备份是在提交事务之后唯一能够清除事务日志的操作。（有关这个问题的背景，请参见 technet.microsoft.com/magazine/2009.02.logging，以了解事务日志的工作原理以及不同的恢复模式如何影响其行为。）
因此，执行事务日志备份的频率在一方面决定了清除事务日志以阻止其增长的速率。例如，如果您的定期备份作业每 30 分钟执行一次事务日志备份，事务日志文件必须足以保存在 30 分钟内生成的最大的事务日志数据量。否则，数据量将增长。
如果您的升级脚本运行 60 分钟且每 30 分钟生成 20 GB 的事务日志，则事务日志文件大小应为 20GB。可能这样文件仍然太大，因此您需要在运行升级脚本时提高事务日志备份的频率。这样可以更频繁地清除事务日志，从而阻止其过度增长。我们在客户办事处曾遇到过相似的问题，结果他们需要在大型数据库中运行相似的脚本的数小时内每分钟执行一次事务日志备份。
我们需要记住一件事，即这些“额外的”事务日志备份构成了日志备份链的一部分，并且是灾难恢复所必须的。确保它们的名字都有意义且未被删除。
另外，还应考虑以下事项：作为您所设计的升级过程的一部分，发生的最大的单项事务是什么？仅当日志记录来自已提交的事务时，可清除事务日志（这样说可能过于简单，有关详细信息，请参见前面所提到的文章）。这意味着长期运行的事务不允许清除日志，即便事务日志备份不备份所生成的事务日志。
如果您的升级脚本包含一个需要 15GB 日志空间的事务，则事务日志文件将需要至少 15GB 来在提交事务前保存整个事务。在这种情况下，无论您执行事务日志备份的频率如何，该事务日志都不会被清除。这种情况下唯一的解决办法是，如果可能，将大型事务拆分成较小的事务。
请记住，运行升级脚本所需的事务日志大小取决于事务日志备份的频率以及您所创建的最大的单个事务的大小。
配置难题
**问：**我们正在为我们的一个数据库服务器配置一些新的直接连接存储，我们希望确保我们理解了所有的选择方案并正确配置。您能不能解释一下对于 SQL Server，我们应了解哪些不同的配置设置？
**答：**配置存储时需要有策略的设置和配置选项，因此，我倾向于由专门的存储管理员来负责。SQL Server 管理员肯定需要关注一些选项，以确保正确设置。
首先是底层 RAID 级别。涉及到性能与冗余性问题时，各种 RAID 级别的权衡互不相同。例如，仍能提供一定冗余性的最便宜的 RAID 配置为 RAID-5，但此配置只能用于处理单驱动器故障（除非采用 RAID-6 或配置了热备用驱动器），并且根据阵列中驱动器的数量，它有时会削弱大量写入工作负荷的性能。
RAID-10 提供了最佳的冗余性，但更为昂贵。阵列的总容量最高为构成驱动器总容量的一半。有关各种 RAID 级别的深入探讨，请参见 TechNet 白皮书物理数据库存储设计附录 A。
需要考虑的其他主要因素为 RAID 条带大小、NTFS 分配单元大小（簇大小）以及磁盘分区对齐方式。如果设置有误，所有上述因素都会导致性能明显下降。其中最重要的一个因素为使用 Windows Server 2003 创建的磁盘卷的磁盘分区对齐方式。默认的对齐方式为 31.5KB，但这与 64KB 的常用 RAID 条带大小（或者其中的多个条带大小）不匹配。因此，每个 I/O 事实上需要读或写两个 RAID 条带来满足 IO。很明显，这会导致性能急剧降低。
默认情况下，Windows Server 2008 采用 1MB 的对齐方式。在 Windows Server 2003 上创建并升级到由 Windows Server 2008 托管的任何卷的对齐方式都不会变化，因此它们仍有可能会受到影响。要想解决这一问题就必须重新格式化卷，由于这样能够提高性能，所以还是值得的。
对于这些问题的详细探讨很明显已超出了此专栏的主题范围，但是您可以阅读我的博客帖子您的磁盘分区偏移量、RAID 条带大小和 NTFS 分配单元设置是否正确？，以了解详细信息（包括更多相关帖子的链接）。
配置任何新的存储时，最好在开始应用生产负载之前进行压力测试和性能测试。压力测试使您能够排除可导致停机或数据丢失的任何配置问题。性能测试可帮助您验证新的存储能否提供您的工作负载所需的 I/O 能力。Microsoft 提供可帮助实现这些操作的免费工具，请参见白皮书预部署 I/O 最佳实践以了解详细信息。
镜像，镜像
**问：**我对于设置数据库镜像时见证服务器的性质有些不解。见证服务器需要有多强大？它是否依赖于它执行故障转移的数据库的数量？将见证服务器放置在哪个数据中心有没有影响？我希望确保镜像数据库能够获得最高的可用性。
**答：**见证服务器的角色是任何数据库镜像系统中最容易被误解的一个方面。同步数据库镜像配置中见证服务器存在的唯一目的是，当主体服务器变得不可用时帮助促进自动故障转移。
主体服务器会持续向镜像服务器而不是见证服务器发送事务日志记录。作为自动故障检测机制的一部分，主体服务器、镜像服务器和见证服务器每秒都会相互 ping。如果出于任何原因镜像服务器判定它无法与主体服务器通信，除非见证服务器同意它也无法与主体服务器通信，否则镜像服务器无法启动自动故障转移。如果两台服务器达成一致，便形成仲裁，并由镜像服务器启动自动故障转移。如果见证服务器不存在，则无法形成仲裁且无法启动自动故障转移。
因此，见证服务器存在的唯一目的就是帮助形成仲裁。它不会启动故障转移或在托管镜像数据库中扮演任何角色。通常，这种仲裁存在于主体服务器与镜像服务器之间。
由于见证服务器不会做任何上述处理，它不需要非常强大。它可以托管任意版本的 SQL Server，包括免费的 SQL Server Express Edition。对于可作为见证服务器的 SQL Server 的特定实例，数据库镜像会话数也没有限制。
见证服务器最好放置在与主体服务器或镜像服务器不同的数据中心。但是，大多数公司并不具备三个数据中心，因此问题是应将见证服务器与镜像服务器还是与主体服务器放置在一起。
如果仅有两个数据中心可用，应始终将见证服务器与主体服务器放置在一起。这与形成仲裁有关系。如果将见证服务器与镜像服务器放置在一起，当主体服务器失去网络链接时，见证服务器和镜像服务器会形成仲裁并由镜像服务器启动故障转移。
这种情况下主体服务器可能没有任何问题，当未形成仲裁时，它会使主体数据库脱机。它假定在这种情况下镜像会执行故障转移。为防止出现这种问题，应将主体服务器与见证服务器放置在一起，这样可以在发生网络故障时使主体服务器维持与见证服务器的仲裁。从而使主体数据库保持可用。
见证服务器完全可选，但如果不存在见证服务器则不可能发生自动故障转移，因此无法保证镜像的数据库的最高可用性。对于其他方式，数据库镜像操作均相同。如果配置了见证服务器但由于某些原因它不可用，除了执行自动故障转移的功能以外，镜像功能不受影响。
每个数据库镜像会话也可以配置两个见证服务器。为见证服务器角色增加更高冗余性的唯一方法是，在故障转移群集中托管见证 SQL Server 实例。有关数据库镜像配置的详细信息，请参见 TechNet 白皮书 SQL Server 2005 中的数据库镜像。
.jpg)
Paul S. Randal是 SQLskills.com 常务董事、Microsoft 区域总监兼 SQL Server MVP。从 1999 年到 2007 年，他一直在 Microsoft 的 SQL Server 存储引擎团队工作。他曾编写过 DBCC CHECKDB/repair for SQL Server 2005，并在 SQL Server 2008 的开发过程中负责核心存储引擎部分的工作。Randal 是灾难恢复、高可用性和数据库维护方面的专家，经常在全球出席一些会议。您可以访问他的博客 SQLskills.com/blogs/paul，也可以通过 Twitter (Twitter.com/PaulRandal) 与他联系。