Windows存储 SQL行溢出差异备份及疑问-交流共享-唐山网站建设

Windows存储 SQL行溢出差异备份及疑问

核心提示：我最近升级了1个利用程序，使其可以在 SQL Server 2005 上运行。我利用了答应行长度超出 8,060 个字节这项功能，以便用户可以创建较长的数据字段而不会收到从 SQL Server 返回的毛病。

问：我最近升级了1个利用程序，使其可以在 SQL Server 2005 上运行。我利用了答应行长度超出 8,060 个字节这项功能，以便用户可以创建较长的数据字段而不会收到从 SQL Server 返回的毛病。现在，将这个利用程序利用到实际环境以后，1些扫描查询开始出现性能题目，在架构更改之前，这些查询运行正常。我也检查过各种索引的碎片，1切正常。那为甚么查询在 SQL Server 2005 上运行时速度比较慢呢?

答：您所利用的“行溢出”功能，对在特定情况下答应行长度大于 8,060 个字节效果很好，但却不合适大多数长度过大的行，而且可能使查询性能大打折扣，正如您所碰到的情况那样。

产生这类情况的缘由是，当某行的长度开始变得过大时，该行中的其中1个可变长度列会被“推出行”。这意味着该列会在数据或索引页上从行中移到文本页中。至于原来列中的值，会由指针取代，指向该列中的值在数据文件中的新位置。

这与用来存储 XML、文本、图象或 varchar(max) 等常规 LOB(大型对象)列的机制完全相同。请留意，假设表架构包括多个可变长度列，就没法保证在多个行的长度变得过大时推出的会是同1列。

这类机制可能会产生性能题目。假设查询从1个表格行中检索的可变长度列已被推出该行，可能忽然之间需要额外的 I/O 来读取内含行外位置的值的文本页。假设有多个行的长度过大，从多个行中检索相同的可变长度列的查询，可能产生没法预感的性能题目，严重程度取决于被推出行的值的数目。

在您碰到的情况中，对包括可变长度列的选择列表履行范围扫描或表扫描的查询，正是因行溢出及其影响而导致性能降落。这与索引是否是履行过完全的碎片整理无关，当可变长度列被推出行时，由于必须使用随机 I/O 读取内含行外的值的文本页，所以之前有效的扫描作业已基本中断。

固然行溢出在特定的情况下对长度过大的行依然很有用，但假设查询的性能相当重要，则不应当在您的设计里面过度利用。

问：我们刚在两个故障转移群集之间引进了数据库镜像，作为以低于存储区域网络 (SAN) 复制的本钱取得地理冗余的方法。由于数据中心位于同1个城市，所以我们能够使用同步镜像。题目在于当本地群集上产生故障转移时，镜像数据库会故障转移到远程群集，而这其实不是我们希看产生的情况。我们该如何避免出现这类情况?我们只希看在本地群集没法使用的时才进行故障转移。

答：为了进步可用性，镜像会安装1个见证服务器，以便在主体服务器没法使用时自动产生故障转移。其理论基础是：假设全部本地群集出现故障，数据库镜像将故障转移到第2个群集，这样利用程序便可以够继续履行了。

此题目出现在群集故障转移期间。故障转移所花的时间超过了数据库镜像的默许超时设置，而见证服务器和镜像服务器(即第2个群集上活动的 SQL Server 实例)均以为它们看不到主体服务器，因而镜像服务器便开始将镜像故障转移到第2个群集。

预防这类现象最简单的方法是删除见证服务器，以便数据库镜像在本地群集出现故障时不会自动进行故障转移。固然，这类做法会下降可用性，由于这样1来就需要人为启动故障转移。

第2种方法是更改数据库镜像的默许超时设置，也就是更改肯定主体服务器不可用之前，它响应“ping”信息(每秒1次)失败的次数。这类设置称为“火伴超时”(Parnter Timeout)，默许值为 10。可使用以下代码找到数据库当前的超时值：

SELECT mirroring_connection_timeout

FROM master.sys.database_mirroring

WHERE database_id = DB_ID ('mydbname');

可使用以下代码更改超时值：

ALTER DATABASE mydbname

SET PARTNER TIMEOUT ;

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

1 2 下1页

问：我使用的备份策略包括完全备份和日志备份，但有人建议我应当加进差异备份来缩短还原时间。我每周进行1次完全备份，每个小时进行1越日志备份。我试过每天添加差异备份，但我留意到1个异常现象：每个星期结束时的差异备份与每周的完全备份大小差未几。我记得差异备份与日志备份1样都属于增量备份啊!难道是我记错了吗?

答：这是对差异备份的本质有所误解酿成的。差异备份与日志备份不同，不属于增量备份。差异备份包括自上次完全备份后所有更改的数据文件范围(这适用于数据库、文件组和文件级别备份)。

假设范围(包括8个连续数据文件页的逻辑组)有任何更改，都会标记在称为差异图的特殊位图页中。每个数据文件的每 4GB 就有1个差异图。进行差异备份时，备份子系统会扫描所有差异图，并复制所有已更改的范围，但不会重置差异图。这表示连续的差异备份之间更改的范围越大，后者的备份会越大。只有在履行完全备份时才会重置差异图。

假设利用程序工作负载太大，以致于数据库内容在短时间(假定在1个星期)内进行了大量更改，那末每周的完全备份大小几近会与在下1个完全备份前进行的差异备份的大小相同。这也解释了您看到的现象。

另外，差异备份确切提供了1种在灾害恢复的情况下缩短还原时间的方法。假设您采取的备份策略是每周进行1次完全备份，每小时进行1越日志备份，那末您必须履行以下操纵才能最迅速地实现还原：

运行尾日志备份(自最近的日志备份后天生的所有日志)。

还原最近的完全数据库备份。

按顺序还原自最近的完全数据库备份后的所有日志备份。

还原尾日志备份。

这可能需要还原大量日志备份，特别是在灾害恰好产生在进行下次完全备份之前。(最糟的情况是需要还原 24 + 24 + 24 + 24 + 24 + 24 + 23 个日志备份!)在此策略中每天添加差异备份，还原的顺序会变成这样：

运行尾日志备份(自最近的日志备份后天生的所有日志)。

还原最近的完全数据库备份。

还原最近的差异备份。

按顺序还原自最近的差异备份后的所有日志备份。

还原尾日志备份。

这样就没必要还原大量的日志备份了，由于还原差异备份与还原差异备份涵盖期间内的所有日志备份基本相同。

在每天履行差异备份的情况下，即使是在该周的最后1天，最糟的情况也不过是 23 个日志备份。差异备份不属于增量备份，它的1个缺点是它们可能会占用更多的空间，但与缩短还原时间相比，这是值得的。

问：我有1个两节点的故障转移群集，每个节点都运行1个 SQL Server 2005 实例。我依照通常的要求，将每个实例设置为只使用 50% 的可用内存。现在我碰到了1些题目，由于两个实例上的工作负载都需要更多的内存才能保持相同的性能级别。假设我删除内存限制，或是增加内存，我想我会碰到这样的题目：其中1个实例故障转移，然后两个实例都只在1个节点上运行。您有甚么建议?

答：我会针对两节点、双实例的情况来解答这个题目，但以下内容也适用于其他多实例设置(N⑴ 故障转移群集，其中有 N 个节点和 N⑴ 个 SQL Server 实例)。

很多人在两个实例上都碰到太高工作负载的情况(占用的服务器内存超过 50%)，而没有考虑到两个实例在产生故障转移后最后会在1个节点上运行对工作负载的影响。假设没有特殊的配置，实例之间的内存分配很可能会不成比例，结果1个工作负载正常运行，而另1个却慢得不行。

对 SQL Server 2000，建议将每个实例限制为最多使用 50% 的群集节点内存。这是由于 SQL Server 2000 中的内存治理器其实不会对内存不足做出响应 — 假设 SQL Server 占用了节点 80% 的内存，它其实不会下降内存使用量。这表示在故障转移的情况下，另1个刚启动的实例只有 20% 的内存可用。通过将两个实例限制为最多使用节点 50% 的内存，可保证每个故障转移实例有 50% 的内存。不过，这类方法产生的题目是每个实例上的工作负载也会限制为使用 50% 的内存。

而对 SQL Server 2005(和 SQL Server 2008)，内存治理器可以响应内存不足，因此 50% 的上限不再适用。但是没有这类限制，假设两个实例都在1个群集节点上运行，它们可能会争用内存直到产生不成比例的内存分配。

答案是将每个实例设置为最低内存量，这样1来，它们就不会***开释过量的内存。对两节点、双实例的情况，最多见的设置是为每个实例最少配置 40% 的内存。这表示当每个实例在不同的节点上运行时，它们可以占用任意内存量。而当产生故障转移时，会保证每个实例有特定的内存量，以保持固定的工作负载性能级别，并留1些内存在二者之间共享。固然这意味着两个工作负载的性能在产生故障转移时可能会降落(在乎料当中)，但是每个实例在不同的群集节点上运行的大多数时间完全不会遭到限制。

上1页 1 2 http://www.fw8.net/

TAG:备份,故障,内存,实例,差异

评论加载中...