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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有