江西广告网

标题: Windows存储：SQL行溢出、差异备份及疑问 [打印本页]

作者: 云海顽石 时间: 2009-1-7 11:16
标题: Windows存储：SQL行溢出、差异备份及疑问
问：我最近升级了一个应用程序，使其可以在 SQL Server 2005 上运行。我利用了允许行长度超出 8,060 个字节这项功能，以便用户可以创建较长的数据字段而不会收到从 SQL Server 返回的错误。现在，将这个应用程序应用到实际环境之后，一些扫描查询开始出现性能问题，在架构更改之前，这些查询运行正常。我也检查过各种索引的碎片，一切正常。那为什么查询在 SQL Server 2005 上运行时速度比较慢呢? 　　答：您所利用的“行溢出”功能，对于在特定情况下允许行长度大于 8,060 个字节效果很好，但却不适合大多数长度过大的行，而且可能使查询性能大打折扣，正如您所遇到的情况那样。　　发生这种情况的原因是，当某行的长度开始变得过大时，该行中的其中一个可变长度列会被“推出行”。这意味着该列会在数据或索引页上从行中移到文本页中。至于原来列中的值，会由指针取代，指向该列中的值在数据文件中的新位置。　　这与用来存储 XML、文本、图像或 varchar(max) 等常规 LOB(大型对象)列的机制完全相同。请注意，如果表架构包含多个可变长度列，就无法保证在多个行的长度变得过大时推出的会是同一列。　　这种机制可能会产生性能问题。如果查询从一个表格行中检索的可变长度列已被推出该行，可能突然之间需要额外的 I/O 来读取内含行外位置的值的文本页。如果有多个行的长度过大，从多个行中检索相同的可变长度列的查询，可能产生无法预料的性能问题，严重程度取决于被推出行的值的数量。　　在您遇到的情况中，对包含可变长度列的选择列表执行范围扫描或表扫描的查询，正是因行溢出及其影响而导致性能下降。这与索引是否执行过完全的碎片整理无关，当可变长度列被推出行时，因为必须使用随机 I/O 读取内含行外的值的文本页，所以之前有效的扫描作业已基本中断。　　虽然行溢出在特定的情况下对于长度过大的行仍然很有用，但如果查询的性能至关重要，则不应该在您的设计里面过度利用。　　问：我们刚在两个故障转移群集之间引入了数据库镜像，作为以低于存储区域网络 (SAN) 复制的成本获得地理冗余的方法。因为数据中心位于同一个城市，所以我们能够使用同步镜像。问题在于当本地群集上发生故障转移时，镜像数据库会故障转移到远程群集，而这并不是我们希望发生的情况。我们该如何避免出现这种情况?我们只希望在本地群集无法使用的时才进行故障转移。　　答：为了提高可用性，镜像会安装一个见证服务器，以便在主体服务器无法使用时自动发生故障转移。其理论基础是：如果整个本地群集出现故障，数据库镜像将故障转移到第二个群集，这样应用程序就可以继续执行了。　　此问题出现在群集故障转移期间。故障转移所花的时间超过了数据库镜像的默认超时设置，而见证服务器和镜像服务器(即第二个群集上活动的 SQL Server 实例)均认为它们看不到主体服务器，于是镜像服务器便开始将镜像故障转移到第二个群集。　　预防这种现象最简单的方法是删除见证服务器，以便数据库镜像在本地群集出现故障时不会自动进行故障转移。当然，这种做法会降低可用性，因为这样一来就需要人为启动故障转移。　　第二种方法是更改数据库镜像的默认超时设置，也就是更改确定主体服务器不可用之前，它响应“ping”信息(每秒一次)失败的次数。这种设置称为“伙伴超时”(Parnter Timeout)，默认值为 10。可使用下列代码找到数据库当前的超时值： SELECT mirroring_connection_timeout FROM master.sys.database_mirroring WHERE database_id = DB_ID ('mydbname'); GO 　　可使用下列代码更改超时值： ALTER DATABASE mydbname SET PARTNER TIMEOUT <timeoutvalue>; GO 　对于这种情况，设置的伙伴超时值必须大于在本地群集上进行群集故障转移的常规时间值。在镜像数据库上进行群集故障转移时确定运行恢复所需的时间变化，可能有些困难，不过您应该可以判断出上限。这种方法的缺点在于超时值可能必须以分钟为单位，不适合在发生真正的灾难时使用。 [1] [2] < 　　问：我使用的备份策略包括完整备份和日志备份，但有人建议我应该加入差异备份来缩短还原时间。我每周进行一次完整备份，每个小时进行一次日志备份。我试过每天添加差异备份，但我注意到一个异常现象：每个星期结束时的差异备份与每周的完整备份大小差不多。我记得差异备份与日志备份一样都属于增量备份啊!难道是我记错了吗? 　　答：这是对差异备份的本质有所误解造成的。差异备份与日志备份不同，不属于增量备份。差异备份包含自上次完整备份后所有更改的数据文件范围(这适用于数据库、文件组和文件级别备份)。　　如果范围(包含八个连续数据文件页的逻辑组)有任何更改，都会标记在称为差异图的特殊位图页中。每个数据文件的每 4GB 就有一个差异图。进行差异备份时，备份子系统会扫描所有差异图，并复制所有已更改的范围，但不会重置差异图。这表示连续的差异备份之间更改的范围越大，后者的备份会越大。只有在执行完整备份时才会重置差异图。　　如果应用程序工作负载太大，以至于数据库内容在短时间(假设在一个星期)内进行了大量更改，那么每周的完整备份大小几乎会与在下一个完整备份前进行的差异备份的大小相同。这也解释了您看到的现象。　　另外，差异备份确实提供了一种在灾难恢复的情况下缩短还原时间的方法。如果您采用的备份策略是每周进行一次完整备份，每小时进行一次日志备份，那么您必须执行下列操作才能最迅速地实现还原：　　运行尾日志备份(自最近的日志备份后生成的所有日志)。　　还原最近的完整数据库备份。　　按顺序还原自最近的完整数据库备份后的所有日志备份。　　还原尾日志备份。　　这可能需要还原大量日志备份，尤其是在灾难刚好发生在进行下次完整备份之前。(最糟的情况是需要还原 24 24 24 24 24 24 23 个日志备份!)在此策略中每天添加差异备份，还原的顺序会变成这样：　　运行尾日志备份(自最近的日志备份后生成的所有日志)。　　还原最近的完整数据库备份。　　还原最近的差异备份。　　按顺序还原自最近的差异备份后的所有日志备份。　　还原尾日志备份。　　这样就不必还原大量的日志备份了，因为还原差异备份与还原差异备份涵盖期间内的所有日志备份基本相同。　　在每天执行差异备份的情况下，即使是在该周的最后一天，最糟的情况也不过是 23 个日志备份。差异备份不属于增量备份，它的一个缺点是它们可能会占用更多的空间，但与缩短还原时间相比，这是值得的。问：我有一个两节点的故障转移群集，每个节点都运行一个 SQL Server 2005 实例。我按照通常的要求，将每个实例设置为只使用 50% 的可用内存。现在我遇到了一些问题，因为两个实例上的工作负载都需要更多的内存才能维持相同的性能级别。如果我删除内存限制，或是增加内存，我想我会碰到这样的问题：其中一个实例故障转移，然后两个实例都只在一个节点上运行。您有什么建议? 　　答：我会针对两节点、双实例的情况来解答这个问题，但下列内容也适用于其他多实例设置(N-1 故障转移群集，其中有 N 个节点和 N-1 个 SQL Server 实例)。　　许多人在两个实例上都遇到过高工作负载的情况(占用的服务器内存超过 50%)，而没有考虑到两个实例在发生故障转移后最后会在一个节点上运行对工作负载的影响。如果没有特殊的配置，实例之间的内存分配很可能会不成比例，结果一个工作负载正常运行，而另一个却慢得不行。　　对于 SQL Server 2000，建议将每个实例限制为最多使用 50% 的群集节点内存。这是因为 SQL Server 2000 中的内存管理器并不会对内存不足做出响应 — 假如 SQL Server 占用了节点 80% 的内存，它并不会降低内存使用量。这表示在故障转移的情况下，另一个刚启动的实例只有 20% 的内存可用。通过将两个实例限制为最多使用节点 50% 的内存，可保证每个故障转移实例有 50% 的内存。不过，这种方法产生的问题是每个实例上的工作负载也会限制为使用 50% 的内存。　　而对于 SQL Server 2005(和 SQL Server 2008)，内存管理器可以响应内存不足，因此 50% 的上限不再适用。但是没有这类限制，如果两个实例都在一个群集节点上运行，它们可能会争用内存直到产生不成比例的内存分配。　　答案是将每个实例设置为最低内存量，这样一来，它们就不会被迫释放过多的内存。对于两节点、双实例的情况，最常见的设置是为每个实例至少配置 40% 的内存。这表示当每个实例在不同的节点上运行时，它们可以占用任意内存量。而当发生故障转移时，会保证每个实例有特定的内存量，以保持固定的工作负载性能级别，并留一些内存在两者之间共享。虽然这意味着两个工作负载的性能在发生故障转移时可能会下降(在意料之中)，但是每个实例在不同的群集节点上运行的大多数时间完全不会受到限制。 [1] [2] <

欢迎光临江西广告网 (http://bbs.jxadw.com/)