SQL 问题与解答 备份压缩，客户端重定向使用镜像，和更多信息
Paul S. Randal
问： 我们打算升级到 SQL Server 2008，大部分我们的服务器，而我希望转发将放到生产环境的功能之一是备份的压缩。 我知道我可以将其打开默认情况下，每个服务器上的所有数据库，但我也听过我不想要的。 我不确定为什么我不希望默认情况下启用，功能为好像已获得任何丢失。 您可以帮助解释后面我已经听到原因？
A </a0>-答案是我 perennial 收藏： 它取决于 ！ 让我提供解释的一些背景。
要考虑的要点是启用备份压缩时拥有每个数据库备份的压缩比率。 由被压缩的实际数据确定的任何内容被压缩的任何算法压缩比率。
查找 SQL Server 提示？
有关 SQL Server 的提示，请访问， TechNet 杂志 》 SQL Server 提示 页。
有关其他产品的更多提示，请访问， TechNet 杂志 》 提示索引.
随机数据 （小整数值，实例） 很是好不将压缩以便表和数据库中的索引的内容将确定，在很大程度压缩比率可以实现的。
当备份压缩可能会不产生高压缩比率，此处是的一些示例：
- 如果数据库包含启用透明的数据加密，然后压缩率将非常低被压缩的数据是随机的小值。
- 如果在列级加密数据库中数据的大部分，则压缩率将低，再次因为列加密实质上是 randomizes 数据。
- 如果数据库中的大多数表启用数据压缩，然后压缩率将低 ； 压缩已主要通常压缩的数据具有很少的效果。
在种情况下压缩率不足时该问题不低比事实的 CPU 资源用于运行没有获得的压缩算法。 无论程度可以压缩的数据块，CPU 资源始终用于运行压缩和解压缩算法。
这意味着您需要检查每个数据库决定要始终为该数据库中使用备份压缩之前备份中将压缩的程度。 否则您可能会可能被浪费 CPU 资源。 这是您已经听说的基础。
若要汇总，如果数据库的大部分将受益于备份的压缩有意义启用在服务器级别的备份压缩，并手动更改几个备份作业，特别是使用 WITH NO_COMPRESSION 选项。 或者，如果大部分数据库将不受益备份压缩，有意义保留在服务器级别已关闭的备份压缩，并手动更改几个备份作业，特别是使用 WITH COMPRESSION 选项。
问： 最后一年我们升级了数据库镜像，这样如果出现故障，我们可以故障转移到镜像中，并应用程序将继续我们数据库。 尽管我们已设计系统，我们 practiced 执行数据库和所有的故障转移可以正常工作。 上周我们有一个真正的故障数据库故障转移发生，但所有停止应用程序交易记录和应用程序没有连接进行故障转移服务器。 在将来如何可以设置 SQL Server 以便它不在故障转移期间删除应用程序连接，以便交易记录可以继续?
A 我这分解为两个部分如何应用程序可以处理故障转移以及管理客户端与数据库镜像的重定向。
在故障转移发生与 SQL Server 使用任何可用的高可用性技术时, 到失败服务器则客户端连接断开，并且所有正在进行的交易记录会丢失。 不能将服务器之间的未决事务 （在故障转移情况下还是其他方式）。 根据该高可用性技术正在进行的交易记录是将不存在根本故障转移服务器上或者它将作为正在进行的交易记录存在，但将作为故障转移服务器上使数据库联机过程的一部分的回滚。
使用不断一起从主体服务器的事务日志记录提供将镜像服务器与数据库镜像的考虑时，通常第二种情况下，任何未决事务将回滚作为使镜像数据库联机作为新的主体的一部分。
因此，个应用程序必须能够时可能遇到的服务器上运行故障转移到另一台服务器，请执行正常的两个事项：
- 必须能够正常处理服务器连接被丢弃，，然后尝试在短时间时间间隔后重新连接。
- 它必须能够正常处理被中止的事务，并且与故障转移服务器 （可能使用 mid-tier 事务管理器） 建立连接后的交易记录，然后重试。
在仅高可用性技术这里不需要客户端对特别允许在故障转移之后的客户端连接的重定向的是故障转移群集。 客户端连接到虚拟服务器名称，并以透明方式重定向到任何物理群集节点处于活动状态。
与高可用性技术如日志传送和复制，服务器名称故障转移服务器是不同的这意味着该手动重定向的客户端连接后需要故障转移。 在几种方法中进行此手动重定向：
- 因此重新连接尝试进行故障转移服务器到客户端可以硬编码故障转移服务器名称。
- 您可以使用网络负载平衡用于 100 / 0，然后将允许连接到将切换到故障转移服务器的 0 / 100 配置。
- 您可以使用内容 （如服务器名称别名或切换 DNS 表中的项。
与数据库镜像，任何这些选项将工作。 但数据库镜像也有内置的客户端方向功能。 客户端连接字符串可以显式指定镜像服务器的名称并且如果主体服务器不能联系，镜像将然后自动尝试。 此过程称为显式重定向。
如果客户端连接字符串不能更改，然后隐式的重定向或许可以如果出现故障的服务器现在作为镜像服务器运行。 与它的任何连接将被重自动定向到新的主体，这只配合如果镜像服务器运行。
SQL Server 2005 白皮书中" 实现应用程序与数据库镜像的故障转移"说明了详细的这些选项。
重新 问： 时我们升级到 SQL Server 2005，我们设计我们大型表来将分区，以便我们可以利用分区的维护和滑动窗口机制。 您 8 月 2008 部分中描述此 （" 分区、 一致性检查以及更多"). 但我们已经遇到问题。 有时，阻止在整个表，查询不甚至访问同一个分区时遇到并发应用程序的查询。 我听过 SQL Server 2008 解决此问题，可以则请解释如何我可以阻止此阻止？
图 1 检查已分区表上的锁
A </a0>-问题要查看由一种称为锁升级的机制。 SQL Server 获得对查询进行读取或写入该数据时保护它们的数据锁定。 它可以获得对整个表、 数据文件页，或单个表 / 索引行，锁定，并且每个锁占用一个小的内存。
如果查询导致需要太多的锁定，SQL Server 可以决定替换整个表上的单个锁定的行或表格中的页的所有锁 （这发生时, 阈值是大约 5000 个锁但确切算法复杂并且可配置）。 此过程称为锁定升级。
在 SQL Server 2005，如果查询 A 运行单个分区表的并导致要采取以触发锁定升级，不足，无法锁定然后整个表将成为锁定。 这可以防止查询 B 相同的表的不同的分区上运行。 因此，查询 B 被阻止直到查询 A 完成，并且其锁将被删除。
SQL Server 2008 中, 锁定升级机制已得到改进允许表有分区级别锁定升级。 使用上面的示例，这意味着由 A 将只锁定单个分区查询使用 A，而不是整个表的查询引起锁定升级。
查询 B 就可以不阻止对另一个分区。 查询 B 甚至可能触发锁定升级本身，然后会锁定该分区的 B 运行，而不是整个表的查询。
可以使用以下语法来设置此模型的锁定升级：
ALTER TABLE MyTable SET (LOCK_ESCALATION = AUTO);
GO
此语法指示 SQL Server 锁管理器使用分区级别锁定升级如果表将是分区和常规表级锁定升级，如果表不进行分区。 默认行为是使用表级锁定升级。 设置此选项，因为它可能会导致死锁，具体取决于您的查询的行为时应采取谨慎。
是例如如果查询 A 和 B 都导致锁定升级表的不同分区，但它们都然后尝试访问其他查询已锁定该分区一个查询将被中止的死锁监视器进程。
在图显示查询 sys.partitions 系统目录视图 （结果在第一个组） 和 sys.dm_os_locks DMV （结果在第二个组） 来检查在所持有锁的查询对已分区表分区级别锁定升级所发生的一个示例。 在这种情况下有两个分区级别独占锁 (HOBT 输出中锁)，但表锁 （在输出中对象锁定） 不独占，以便即使锁定升级已发生多个查询可以访问的分区。 请注意这些两个分区锁的资源 ID 匹配 sys.partitions 输出中表格的前两个分区在分区 ID。
前面本年度我 blogged 有关的示例脚本显示如何 分区级别锁定升级工作和潜在的死锁。 SQL Server 2008 联机联机主题称为" 数据库引擎中的锁定"有锁定 SQL Server 2008 中的所有方面的详细说明。
问： 一个我们的服务器的一些问题与磁盘存放在的数据库在事务日志，数据库成为问题。 最新的完整备份从五个星期前，它要花费太多时间太还原所有日志备份。 它已超出问题的发生时间的时间以便我们重建损坏的事务日志以避免停机时间。 在某些情况下，这可能导致问题。 但是，如果任何已访问数据，然后我想我们安全。 我们是否执行正确的操作？
A </a0>-简单的答案，只有种我认为重建事务日志时就不可以从备份恢复。 尽管知道重建事务日志 （对于那些这些读者不，看到我的博客发布，"的危险 最后会用户首先尝试..."事实数据库运行恢复过程中失败的可疑意味着，运行故障恢复或者回滚事务时。 这意味着有实际可能在数据库中的数据损坏。
虽然您静音期间出现的问题，做您考虑计划的作业和后台任务？ 维护作业可能已运行的是重新生成或重新组织聚集的索引，日志被损坏时。 后台任务可能已运行幻影清理在一个堆集或聚集的索引的网页上。 任一这些，是例如可能已被更改了如果不正确回滚，会导致损坏数据库和可能的数据丢失的聚集的索引结构。
底行是重新生成事务日志应该始终是在由于到巨大可能导致多个损坏和数据丢失任何灾难恢复方案中绝对最后的办法。 最起码，应当检查是否存在任何损坏的数据库上运行完整的 DBCC CHECKDB。
进度，应更改备份策略，以便您能够执行及时还原并无需借助于如事务日志重建的强硬量值。 设计备份的策略的步骤超出了本专栏中的范围，但我计划在未来的年中涉及在某个时候 full-length 功能文章中的本主题。 请保持调整 ！
Randal Paul S。 被管理的 Director SQLskills.com和 SQL Server MVP。 HeHe 从事 SQL Server 存储引擎团队 Microsoft 从 1999 年可以 2007。 Paul 写 DBCC CHECKDB / 修复 SQL Server 2005 但负责核心存储引擎 SQL Server 2008 开发过程中。 Paul 有关灾难恢复、 高的可用性和数据库维护的专家且为常规的演示者在世界各地的会议。 在他博客 SQLskills.com/blogs/Paul.