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 ;

GO

对于这种情况，设置的伙伴超时值必须大于在本地群集上进行群集故障转移的常规时间值。在镜像数据库上进行群集故障转移时确定运行恢复所需的时间变化，可能有些困难，不过您应该可以判断出上限。这种方法的缺点在于超时值可能必须以分钟为单位，不适合在发生真正的灾难时使用。