【IT168 评论】新阵列移动日

　　问：我们当前的 RAID 很快就填满了，因此需要将一些 SQL Server 2005 数据库移到其他位置。新阵列已准备就绪，并且我一直在为移动数据库作准备。我刚刚发现其中一个数据库是事务复制发布服务器，我知道这表示我不能移动该数据库。我应怎样做?

　　答：对您来说有一个好消息 - 只有 SQL Server 2000(和更早版本)具有以下局限性：限制在未重新初始化事务复制或直接更改各种系统表的情况下移动发布数据库。

　　对于 SQL Server 2005 和 SQL Server 2008，有一个记录下来的过程，您可以按照它移动数据库，而不必对事务复制执行任何操作，但要求数据库保持连接到同一 SQL Server 实例。移动时必须停机一段时间，因为当数据库文件仍处于联机状态时无法将其移动。过程如下：

　　首先，使用下面的代码使数据库脱机。如果有用户连接到数据库，则需要先断开这些用户的连接，此过程才能成功：

　　接着，将数据文件复制到新位置。使用复制而不是移动，可在发生任何错误时进行快速回滚(否则，必须执行还原)。然后，使用以下代码告知 SQL Server 每个文件的新位置：

　　物理上复制了所有文件并更新了 SQL Server 中的文件位置后，使用以下代码使数据库恢复联机状态：

　　关闭页锁存

　　问：我在理解一些性能优化相关概念时存在疑问。我几次读到需要防止“页锁存”问题。我不知道“页”或“锁存”是什么意思，或者说为什么页锁存甚至是一个问题。您能解释所有这些疑问吗?

　　答：SQL Server 数据库中的所有数据都存储在数据文件中。在内部，这些文件组织成大小为 8 KB 的数据块序列，称为页。页是 SQL Server 可以管理的基本存储和 I/O 单位。页通常位于磁盘上的数据文件中，并且在处理任何查询之前，需要 SQL Server 的缓存(称为缓冲池)来进行读取。

　　SQL Server 使用各种页来存储不同类型的关系数据(例如，表中的行、非群集索引中的行或者文本/LOB 数据)。还有一些页存储 SQL Server 组织和访问存储关系数据的页所需的内部数据结构部分。

　　锁存 是一种轻量级内部机制，SQL Server 使用它来同步对缓存内的某个页的访问。您需要注意两种类型的页锁存 - 常规页锁存 和页 I/O 锁存。如果 SQL Server 线程必须等待获取其中一个锁存，则表示出现性能问题。

　　当 SQL Server 正等待从磁盘中读取数据文件的某部分时，则可能会导致页 I/O 锁存等待。如果页 I/O 锁存持续很长时间，则通常表明底层磁盘子系统出现性能问题(即，该子系统过载)。

　　当 SQL Server 中的多个线程尝试访问内存中的相同 8 KB 数据文件页时，就存在对该页访问权的争用，这可能会导致页锁存等待。最常见的这种情况涉及大量使用 tempdb 数据库中的临时小对象。

　　有关如何监视和减少页锁存等待的更深入说明不属于本专栏文章的范围，但您可以在以下资料中找到更多信息：

　　· SQL Server 2008 联机丛书中的“SQL Server Wait Statistics 对象”部分，它说明如何使用系统监视器监视等待统计数据。

　　· SQL Server 2008 联机丛书中的“sys.dm_os_wait_stats”部分，它列出了常见的 SQL Server 等待类型及其含义，并说明如何从 SQL Server 内部监视等待统计数据。

　　· 白皮书《SQL Server 2008 中的性能问题故障排除》，它提供各种故障排除查询和技术，包括等待统计数据。　　

点击查看更多TechNet精彩文章 

　　通查数据库快照

　　问：我刚刚发现了数据库快照。现在，我考虑将它们用作完全恢复模式和日志备份的替代方法。我将大约每小时创建一次快照，这样当出现错误时，我可以拉回损坏的数据。这似乎是一种更省事且更快的还原方法。您认为进行这种更改会产生任何问题吗?

　　答：会产生问题，数据库快照不是全面的灾难恢复策略的实用或可行替代方法。在从灾难完全恢复方面，数据库快照不具备与事务日志备份相同的功能。数据库快照不包含数据库中所有页的副本，它只包含自第一次创建数据库后更改过的页的副本。这意味着，如果数据库有任何损坏，则没有底层数据库的数据库快照将没有任何用处。它只是数据库中不同页的集合，不能用于恢复。

　　您可以通过数据库快照拉回不小心从数据库中删除的数据，但前提是数据库本身仍可用。例如，如果从数据库中删除的表仍存在于快照中，则可以使用快照重新创建该表。

　　也就是因为潜在的性能问题，创建太多数据库快照(作为每一个半小时的事务日志备份的替代方法)不是一个好主意。在可以交换数据库页之前(请参阅“关闭页锁存”部分中的答案说明)，必须先将页同步地复制到尚未包含该页版本的所有现有数据库快照中。随着创建的数据库快照越来越多，要生成的页副本也越来越多，从而导致性能下降。

　　不要创建太多数据库快照的另一个原因是每个数据库快照将包含数据库页更改前的副本。每个副本将随着数据库中更改的内容增多而增大。这可能会导致磁盘空间问题和性能问题。

　　数据库快照不是为了替代频繁日志备份而设计的。您可以在白皮书 Database Snapshot Performance Considerations Under I/O-Intensive Workloads 中阅读关于数据库快照的性能影响的更深入研究。

　　此外，如果您要使用完全恢复模式和事务日志备份，则很明显您对最多能够恢复到灾难点和/或使用时间点还原感兴趣。(有关恢复到灾难点和时间点还原的说明，请分别参阅我于 2009 年 7 月和 2009 年 11 月发布的文章“了解 SQL Server 备份”和“SQL Server：利用备份进行灾难恢复”。)

　　镜像，镜像

　　问：我被要求为数据库设置数据库镜像，但我担心数据库镜像不能帮助解决我们的问题。我们的 SAN 存在一些损坏问题，因此打算通过数据库镜像防止我们受到损坏。损坏不会自动发送到镜像吗?数据库镜像如何帮助我们解决此问题?

　　答：这是一个会引起大量混淆的问题。任何提供冗余数据库副本的技术看起来似乎都容易受到从主体传播到镜像数据库(以使用数据库镜像术语)的损坏的影响，但实际上这种情况不会发生。

　　问题的关键在于理解镜像数据库的维护方式。如果底层同步机制将完整数据库页从主体复制到镜像数据库，则损坏肯定会传播到镜像。然后，主体中损坏的页将被放置在镜像中。

　　但是，数据库镜像专门避免了这种情况，因为它不将一个数据库中的数据库页复制到另一个数据库。数据库镜像过程是将事务日志记录从主体数据库复制到镜像来完成的。事务日志记录说明对数据库页所做的物理更改，它们不包含实际页本身。(有关事务日志记录、日志记录和恢复的完整说明，请参阅我于 2009 年 2 月发布的文章：“了解 SQL Server 中的日志记录和恢复功能。”)

　　即使数据库页被主体数据库的底层 I/O 子系统损坏，该损坏也不可能直接传播到镜像数据库。可能出现的最坏情况是如果 SQL Server 未检测到页面损坏(由于未启用页面校验和)，将使用已损坏的列值来计算存储在数据库中的值。生成的不正确结果将传播到镜像数据库，从而产生二级损坏效果。如前所述，如果启用了页面校验和，则从磁盘中读取页面时，这种损坏仍将检测不到，从而不会出现二级损坏。

　　此行为还说明了为什么对主体数据库运行一致性检查不会生成关于镜像数据库的一致性状态的任何信息，反之亦然。它们是通过传送对数据库而不是实际数据库页的物理更改的说明来保持同步的两个不同数据库。

点击查看更多TechNet精彩文章