你目前正处于脱机状态,正在等待 Internet 重新连接

日志记录和数据扩展数据的可靠性,在 SQL Server 中的存储算法的描述

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

重要说明:本文是由 Microsoft 机器翻译软件进行的翻译并可能由 Microsoft 社区通过社区翻译机构(CTF)技术进行后期编辑,或可能是由人工进行的翻译。Microsoft 同时向您提供机器翻译、人工翻译及社区后期编辑的文章,以便对我们知识库中的所有文章以多种语言提供访问。翻译的文章可能存在词汇、句法和/或语法方面的错误。Microsoft 对由于内容的误译或客户对内容的使用所导致的任何不准确、错误或损失不承担责任。

点击这里察看该文章的英文版: 230785
概要
本文讨论了 Microsoft SQL Server 日志记录和数据算法扩展数据的可靠性和完整性的方式。

有关引擎的基础概念和 ARIES (用于恢复和隔离利用语义算法) 的详细信息,请参阅数据库系统文档 (在"卷 17 号为 1,3 月 1992年) ACM 以下交易记录:

本文档的潜在顾客编写器 C.Mohan。该文档介绍 SQL Server 技术来扩展数据的可靠性和完整性,为相关的故障。

我们建议您阅读以下有关缓存详细信息中 Microsoft 知识库文章和其他故障模式的论述:
86903 在 SQL Server 中的磁盘控制器缓存的说明
234656 使用的每个数据库管理员应该知道的 SQL Server 的磁盘驱动器缓存信息
更多信息
我们开始深入讨论之前,有些整篇文章中使用的术语在下表中定义。
术语定义
电池备份单独和本地化的电池备份实用程序直接可用并由缓存机制以防止数据丢失。
注意:这不是一个不间断电源 (UPS)。UPS 并不保证任何写入活动,可以从缓存设备断开连接。
高速缓存中间存储机制,用来优化物理 I/O 操作,并提高性能。
脏页包含尚未刷新到稳定存储器中的数据修改的页。有关缓冲区写出脏页的详细信息,请参阅"将页写入"在 SQL Server 联机丛书中的主题。
注意:内容也适用于 Microsoft SQL Server 2012年及更高版本。
失败任何可能会导致 SQL Server 进程的意外的中断。示例包括: 电源中断、 计算机重置、 内存错误、 其他硬件问题、 坏扇区、 驱动器故障、 系统故障等。
刷新高速缓存缓冲区的强制到稳定存储器。
闩锁用于保护物理一致性的一个资源的同步对象。
非易失性存储任何媒体,仍可在多个系统故障。
固定的页面网页中的保留在数据高速缓存和无法刷新到稳定存储器中,直到所有相关联的日志记录固定在一个稳定的存储位置。
稳定存储非易失性存储相同。
易失性存储任何介质,将不会保持不变在多个故障。

预写日志记录 (WAL) 协议

术语协议是极好的方法来描述 WAL。它是特定和组定义的实现步骤确保这些数据所需存储和交换正确和到一个已知状态出现故障时可以恢复。就像网络包含定义的协议,以便以一致的和受保护的方式,交换数据太 WAL 描述了协议,以保护数据。

ARIES 文档定义 WAL,如下所示:
WAL 协议断言表示对某些数据更改的日志记录必须已处于稳定存储器允许替换以前版本的非易失性存储中的数据发生更改的数据之前。也就是说,系统不允许将更新过的页面写入非易失性存储版本的页面,直到至少描述页面更新的日志记录的撤消部分已写入到稳定存储器。
有关预写日志记录的详细信息,请参阅 提前写入事务日志 在 SQL Server 联机丛书中的主题。

SQL Server 和 WAL

SQL Server 使用 WAL 协议。若要确保未正确提交的事务,必须稳定存储中保护与交易记录相关联的所有日志记录。

为了阐明这种情况下,请考虑下面的特定示例。

注意:对于此示例,假定没有索引和受影响的页是 150 页。
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
接下来,分解成简单的日志记录步骤的活动,如下表中所述。
语句执行的操作
事务处理开始写入日志缓存区域。但是,不需要刷新到稳定存储器,因为 SQL Server 不具任何实际的更改。
插入到 tblTest
  1. 数据页 150 检索到 SQL Server 数据缓存中,如果已不可用。
  2. 该页面 已锁定, 固定标记为已更新并可获得相应的锁。
  3. 插入日志记录生成和添加到日志高速缓存。
  4. 一个新行添加到页上的数据。
  5. 释放闩锁。
  6. 与交易记录相关联的日志记录或页上没有要此时刷新,因为所有的更改保留在易失性存储。
提交事务
  1. 形成的提交日志记录,必须写入与该事务关联的日志记录到稳定存储器。该交易记录不被视为提交之前的日志记录正确分配到稳定存储器。
  2. 数据页 150 保持 SQL Server 数据缓存中,并且没有立即刷新到稳定存储器。当正确的日志记录安全的时恢复可以恢复操作,如有必要。
  3. 事务锁被释放。
请不要不能混淆的术语"锁定"和"日志记录"。虽然重要,但锁定和日志记录是独立的问题时应对 WAL。在前面的示例中,SQL Server 通常包含闩锁在页上 150 次没有交易记录的整个时间在页上,执行物理插入更改所需。建立适当的锁类型来保护行、 范围、 页面或根据需要的表。请参阅 SQL Server 联机丛书的锁定部分锁定类型有关的更多详细信息。

查看更多详细信息的示例,您可能会问的惰性写入器或检查点进程运行时,会发生什么情况。SQL Server 7 发出所有相应刷新到稳定存储器的事务性日志记录的与脏和锁定页。这将确保 WAL 协议数据页可以永远不会写到稳定存储器,直到关联的事务日志记录都已刷新。

SQL Server 和稳定存储

SQL Server 包括磁盘扇区大小 (通常为 4096 或 512 字节) 的知识,从而增强了日志和数据页操作。

为了维护事务的 ACID 属性,SQL Server 必须考虑故障点。在故障期间许多磁盘驱动器规格只保证了有限的数量的扇区的写入操作。发生故障时,大多数规范保证完成单一扇区写入。

SQL Server 使用 8 KB 数据页和日志 (如果刷新) 上的扇区大小的倍数。(大多数磁盘驱动器使用 512 字节作为默认的扇区大小。在出现故障时,SQL Server 可以解释写入操作一个扇区大于通过采用日志奇偶校验和断的写技术。

残缺的页检测

此选项允许 SQL Server 来检测电源故障或其他系统停机引起的未完成 I/O 操作。为 true 时,它会导致每当写入页面翻转为 8 千字节 (KB) 的数据库页的每个 512 字节扇区有一位到磁盘。如果有点状态错误的页面更高版本时读取 SQL Server,然后该页面被错误写入 ;检测到一个残缺的页。残缺的页是通常恢复期间检测到由于编写不正确的任何页可能通过恢复来读取。

虽然 SQL Server 数据库页大小为 8 KB,则磁盘执行 I/O 操作使用 512 字节扇区。因此,每个数据库页写入 16 个扇区。残缺的页可以 8 KB I/O 操作的完成时,操作系统将写入到磁盘的第一个 512 字节扇区之间出现如果系统失败 (例如,由于断电)。如果在故障发生之前成功地写入数据库页的第一个扇区,磁盘上的数据库页会更新,虽然它可能不成功。

通过使用电池供电的磁盘控制器缓存,您可以确保数据已成功写入到磁盘或不写在所有。在此情况下,因为这是不必要不要设置为"true"残缺的页检测。

注意:默认情况下,在 SQL Server 中未启用残缺的页检测。有关详细信息,请参阅下面的 MSDN 网站:

日志奇偶校验

日志奇偶校验检查是非常类似于残缺的页检测。每个 512 字节扇区包含奇偶校验位。这些奇偶校验位始终是编写的日志记录和检索的日志记录时,将计算。通过强制日志写入在 512 字节的边界上,SQL Server 可以确保规定操作完全写入物理磁盘扇区。

早于 7.0 的 SQL Server 版本

以前版本的 SQL Server 7.0 比未提供日志奇偶校验或残缺的位检测设施。事实上,这些版本可以编写相同的日志页多次直到日志记录填充 2 KB 日志页面。这会暴露已成功提交的事务。日志页在重写在故障期间,如果一个扇区,与已提交的事务可能不获得重写正确。

性能影响

所有版本的 SQL Server 通过使用 Win32CreateFile函数都打开的日志和数据文件。在打开的 SQL Server 时, dwFlagsAndAttributes成员包括FILE_FLAG_WRITE_THROUGH选项。
FILE_FLAG_WRITE_THROUGH
指示系统通过任何中间缓存写入并直接转到磁盘。系统仍然可以缓存写入操作,但无法惰性刷新它们。

FILE_FLAG_WRITE_THROUGH 选项可以确保当一个写操作返回成功完成时,正确地存储数据稳定存储器中。此选项与 WAL 协议,以确保数据。
许多磁盘驱动器 (SCSI 和 IDE) 包含 512 KB,1 mb 或更大的板载缓存。但是,驱动器缓存通常依赖于电容器,而不是电池供电的解决方案。这些缓存机制无法保证写入在电源重启或类似故障点。它们只能保证扇区的写入操作的完成。这特别是为什么断的写和日志奇偶校验检测已内置于 SQL Server 7.0 和更高版本。随着驱动器大小的增长,缓存会变得更大,并且它们可以在故障期间公开更多的数据。

许多硬件供应商提供电池备份磁盘控制器解决方案。这些控制器缓存可以几天内维护缓存中的数据,并甚至允许缓存的硬件,放置在另一台计算机。正确恢复电源后,未写入的数据被完全刷新之前允许更多的数据访问。其中许多是与写缓存以获得最佳性能建立允许读取的百分比。某些包含较大的内存存储区。事实上,非常具体的市场段,某些硬件供应商提供电池支持的高端磁盘缓存控制器系统具有 6 GB 的缓存。这些可以显著提高数据库的性能。

高级缓存实现将句柄FILE_FLAG_WRITE_THROUGH请求通过不禁用控制器缓存,因为它们可以提供真重写发生时,系统重置、 电源故障或其他故障点的功能。

不使用高速缓存的 I/O 传输可能会由于移动驱动器磁头、 旋转速率、 以及其他限制因素所需的机械时间非常长。

扇区的顺序

一种用于提高 I/O 性能的常用技术是事业部门订购。为了避免机械磁头的移动读/写请求进行排序,允许检索或存储数据的头部运动更一致。

高速缓存可以容纳多个日志和数据在同一时间写入请求。WAL 协议和 SQL Server WAL 协议的实现需要刷新的日志写入到稳定存储器,然后才能发出页写。但是,使用缓存可能会返回成功从日志写入请求 (即写入到稳定存储器) 的实际驱动器写入数据的情况下。这可能会导致 SQL Server 数据页写入请求。

写缓存参与,仍然认为数据是易失性存储。但是,从写文件的 Win32 API 调用,是如何 SQL Server 可以看到该活动,成功的返回代码获得。Onlythat 数据已正确地获得稳定存储器,可以确定 SQL Server 或使用写文件API 调用的任何进程。

出于讨论的目的,假定所有扇区的数据页进行排序来编写之前的匹配的日志记录的扇区。立即,这违反了 WAL 协议。高速缓存写前日志记录的数据页。除非完全备有电池的缓存,可能会导致灾难性的结果。

在评估数据库服务器的最佳性能因素时,有许多因素需要考虑。其中最重要的是,"我的系统允许有效的 FILE_FLAG_WRITE_THROUGH 功能吗?"

注意:Usingmust 是完全任何缓存支持一个电池供电的解决方案。所有其他缓存机制是可疑数据损坏和数据丢失。SQL Server 将尽一切力量来确保 WAL 通过启用 FILE_FLAG_WRITE_THROUGH。

测试表明可能包含多个磁盘驱动器配置没有适当的电池备份写缓存。SCSI 和 IDE,EIDE 驱动器可以完全利用的写缓存。有关 SQL Server 和 SSDs 的工作原理的详细信息,seethe 以下 CSS SQL Server 工程师博客文章:


在许多配置中,正确禁用 IDE 或 EIDE 驱动器的写入缓存的唯一方法是通过使用一个特定的制造商实用程序或使用位于驱动器上的跳线。若要确保写缓存被禁用的驱动器本身,与驱动器制造商联系。

SCSI 驱动器还可以写缓存。但是,这些缓存,通常由操作系统被禁用。如果有任何问题,请与驱动器制造商联系相应的程序。

写缓存堆叠

写缓存堆叠是类似于部门订购。下面的定义是直接取自领先的 IDE 驱动器制造商的网站:
通常情况下,这种模式处于活动状态。写缓存模式可接受主机数据写入入缓冲区中,直到缓冲区已满,或者主机传送已经完成。

磁盘写入任务开始主机将数据存储到磁盘。主机写入命令继续接受和数据传输到缓冲区,直到写命令堆栈已满或数据缓冲区已满。该驱动器可能重新排序写入命令,以优化驱动器吞吐量。

自动写入重新分配 (AWR)

用于保护数据的另一个常用技术是在数据操作期间检测到坏扇区。以下说明来自领先的 IDE 驱动器制造商的网站:
此功能是写缓存的一部分,并在延迟的写操作的过程中减少数据丢失的风险。如果在磁盘写入过程中发生了磁盘错误,磁盘任务停止和可疑的扇区进行了重新分配到备用的扇区位于末尾的驱动器池。之后在重新分配磁盘写入任务继续,直到完成。
如果为缓存提供了备用电池,这可能非常强大的功能。这提供了适当的修改,重新启动时。我们最好还是来检测此磁盘错误,但 WAL 协议的数据安全性再次需要此进行实时和不延迟的方式。WAL 参数中内, AWR 技术无法解决由于扇区错误的日志写入失败,但驱动器已满的情况。数据库引擎必须立即知道有关失败以便可以正确地中止该事务,管理员将收到通知,并纠正确保数据的安全,并纠正介质故障的情况下所采取的步骤。

数据的安全

有几个数据库管理员联系以确保数据的安全而应采取的预防措施。
  • 它始终是一个好主意,以确保您的备份策略足以从灾难性故障恢复。非现场存储和其他预防措施是适当的。
  • 测试辅助数据库还原操作或在经常的基础上的测试数据库。
  • 请确保缓存的任何设备都可以处理所有出现故障的情况下 (停电、 坏扇区、 坏驱动器、 系统崩溃、 锁定、 电源峰值,等等)。
  • 请确保您的缓存设备:
    • 具有集成的电池备份
    • 接通电源时可以重新发起编写
    • 如有必要可以完全禁用
    • 处理实时重新映射的坏扇区
  • 启用数据页检测被破坏。(这有性能几乎没有影响。
  • 如果可能,请配置 RAID 驱动器允许一个损坏的磁盘驱动器,热插拔。
  • 使用较新的缓存控制器,使您可以添加更多磁盘空间,而不必重新启动操作系统。这可能是一个理想的解决方案。

测试驱动器

要全面保护数据,您应该确保正确处理所有数据缓存。在许多情况下,您必须禁用写缓存的磁盘驱动器。

注意:请确保高速缓存机制的一种替代方法可以正确地处理多种类型的故障。

Microsoft 已使用SQLIOSim实用程序来测试在多个 SCSI 和 IDE 驱动器上执行了。此实用程序模拟了繁重的异步读/写活动到模拟的数据设备和日志设备。测试性能统计显示每秒 50 和 70 之间具有禁用的写入缓存的驱动器和 5200 和 7200 RPM 之间的平均写入操作。

有关SQLIOSim实用程序的详细信息,请参阅以下文章 Microsoft 知识库中相应的文章:
231619 如何使用 SQLIOSim 实用程序来模拟在磁盘子系统上的 SQL Server 活动
许多计算机制造商订购通过使写缓存被禁用的驱动器。但是,测试显示这可能不总是如此。因此,一定要测试完全。

数据设备

在所有,但未记录的情况下,SQL Server 将要求仅日志记录被刷新。在执行无日志记录操作,数据页必须也刷新到稳定存储器 ;没有单独的日志记录来重新生成在出现故障时的操作。

数据页可以保留在缓存中,直到惰性写入器或检查点进程将其刷新到稳定存储器。使用 WAL 协议,以确保日志记录可正确存储可确保恢复可以恢复到已知的状态数据页。

这并不意味着它最好放置在缓存驱动器上的数据文件。当 SQL Server 将刷新的数据页到稳定存储器时,可以从事务日志被截断的日志记录。如果数据页都存储在易失性缓存,很可能会截断日志记录将用于恢复发生故障的一页。请确保您的数据和日志设备正确适应稳定存储器。

提高性能

出现的第一个问题是:"我的已缓存的 IDE 驱动器。但是当我禁用它,我的性能变得明显不如预期。为什么?"

许多 microsoft 测试 IDE 驱动器 5200,RPM 速度运行,并在的 7200 RPM 驱动器 SCSI。当您禁用写 IDE 驱动器的缓存机械的性能可以成为一个因素。

没有非常明确的区域解决的性能差异:"地址的事务率。"

有很多的联机事务处理 (OLTP) 系统需要高事务处理率。对于这些系统,请考虑使用缓存控制器可以正确支持写缓存并提供性能大大提高,同时确保数据的完整性。

明显会遇到与 SQL Server 缓存驱动器的性能变化,通过使用较小的事务增加事务处理率。

测试表明,高写入的缓冲区小于 512 KB 或大于 2MB 的活动可能会导致性能降低。
请考虑下面的示例:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
对于 SQL Server 的实例测试结果如下:
SCSI(7200 RPM) 84 秒
SCSI(7200 RPM) 15 秒钟 (缓存控制器)

IDE(5200 RPM) 14 秒 (驱动器高速缓存已启用)
IDE(5200 RPM) 160 秒

在单个事务中包装插入操作的整个一系列将在大约 4 秒内所有配置中运行。

原因是所需的日志刷新的数目。如果没有该事务,每次插入事务本身,并且每次必须刷新该交易记录的日志记录。每个刷新是 512 字节的大小,需要大量的机械驱动器干预。

使用一个事务时,事务的日志记录可以被捆绑在一起,可用于刷新收集的日志记录写入的单个的、 更大。机械的干预大大降低了。

警告我们建议您不会增加您的事务作用域。长时间运行的事务可能会导致过多,不想要阻止,以及更多的开销。使用 SQL Server 性能计数器SQL Server: 数据库中查看交易记录的基于日志的计数器。具体来说,平齐的日志字节数/秒可以指出许多较小的事务,从而导致较高的机械磁盘活动。

查看与日志刷新关联的语句并确定是否可以减少日志刷新的数量。在前面的示例中,被实现单个事务。但是,在许多情况下,这可能导致不希望发生的锁定行为。检查在设计的交易记录。可以使用类似于以下内容的代码执行批,以减少频繁和小型日志刷新活动:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server 要求系统支持"有保证的交付到稳定的媒体,"中所述 SQL Server I/O 可靠性程序评审要求 下载文档。 有关 SQL Server 数据库引擎的输入和输出要求的详细信息,请单击下面的文章编号,以转到 Microsoft 知识库中相应的文章:
967576 Microsoft SQL Server 数据库引擎输入/输出的要求

Warning: This article has been translated automatically

属性

文章 ID:230785 - 上次审阅时间:05/17/2015 10:53:00 - 修订版本: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL 2005 Server Enterprise, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL 2005 Server Workgroup, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 标准版, Microsoft SQL Server 7.0 标准版, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtzh
反馈