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。可使用下列代码找到数据库当前的超时值:

   1. SELECT mirroring_connection_timeout  
2. FROM master.sys.database_mirroring
3. WHERE database_id = DB_ID ('mydbname');
4. GO

it知识库SQL问题与解答:行溢出、差异备份及更多内容,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。