SQL Server 事务日志架构


SQL Server 事务日志架构

SQL Server 数据库的事务日志文件对于维护数据库完整性至关重要。在本文中,Greg Larsen 解释了 SQL Server 事务日志体系结构。

事务日志是每个 SQL Server 数据库都有的文件。它可以被认为是数据库发生的更新活动的日志。事务日志用于维护数据库的完整性。如果由于某种原因未成功提交或发生系统故障,则存储的有关事务的信息可用于回滚它。在本文中,我将介绍事务日志的架构。

ACID原理

事务日志用于维护数据库的完整性。对数据库执行事务时,需要将它们完整准确地写入 SQL Server 数据库的数据文件中。如果它们没有 100% 成功完成,则需要回滚完整的事务以确保数据库中的数据只包含完整的事务。

当事务写入不正确或不完整时,数据库可能包含不正确的数据和/或不完整的信息。在许多不同的情况下,事务可能无法正确写入数据文件。以下是数据库中的数据可能不准确和不完整的一些原因:

  • 输入系统的数据不准确或不符合数据完整性规则。
  • 数据库引擎在所有更新都已提交到 DATA 文件中的磁盘之前的关键时刻崩溃。
  • 磁盘系统出现故障,导致事务的部分信息仅写入磁盘。

SQL Server 遵循所谓的 ACID 原则来维护数据库的完整性。术语 ACID 只是代表atomicity 、Consistency、isolation性和durability 的首字母缩写词。这四个属性共同维护关系数据库的Consistency和完整性。

Atomicity

atomicity 是指将一个完整的事务写入磁盘,或者不写入任何事务。这是“全有或全无”的方法。atomicity 如何工作的一个简单例子是银行在处理书面支票时如何处理转账。兑现支票的过程需要借方和贷方交易。借方交易从与支票关联的支票账户中移除资金。信用交易将资金存入支票所在的账户。为了保持atomicity ,贷方和借方交易都需要成功完成。如果贷方或借方交易由于某种原因失败,则atomicity 属性可确保不会处理任何交易。当只执行部分交易时,

Consistency

Consistency属性确保在事务中写入数据库的所有数据都强制执行所有约束、触发器和其他数据库或应用程序规则。如果事务的任何部分没有成功更新数据库,那么数据库中的数据将不遵循Consistency规则,并且需要中止和回滚事务以确保数据库中数据的Consistency。

支票兑现过程需要发生借方和贷方交易才能成功。如果只发生支票兑现过程中的“借方”过程,则只能完成 50% 的交易。如果没有处理信用交易,检查流程的所有规则都不会成功完成,“借方”交易将需要撤消,以确保数据库中的数据不包含不完整的信息。Consistency属性将确保事务的所有部分都成功完成,如果没有,部分完成的事务将被回滚。

Isolation

isolation属性与isolation一个事务中未提交的数据修改被另一个事务读取或更新有关。isolation属性确保新事务不会从尚未提交的事务中读取或更新数据。

在支票兑现处理示例中,isolation原则确保在交易成功完成之前,第二笔银行交易不会在支票兑现交易中间尝试访问帐户。想象一下,如果与支票兑现过程相关的资金可以在成功完成支票兑现过程之前提取,会产生什么样的财务影响。如果回滚支票兑现过程,这可能会导致透支情况。

SQL Server 有几个不同的isolation级别,有些允许或多或少的isolation。要了解有关不同 SQL Server isolation级别的更多信息,您可以阅读Microsoft 文档。

Durability

durability 属性意味着在提交事务后,数据更改将永久对数据库进行。具有durability 意味着如果事务成功提交后系统崩溃,更改不会消失。通过具有durability ,SQL Server 确保一旦支票兑现示例的“借方”和“贷方”交易完成并提交,即使数据库引擎崩溃,更改也会保留下来。没有durability ,如果系统崩溃,更改可能会消失,这不是一件好事。通过使用 ACID 原则和存储在事务日志中的信息,数据库引擎能够维护 SQL Server 数据库中信息的完整性。

事务日志架构

事务日志是一个顺序文件,用于保存正在处理的事务。事务日志的架构既有逻辑架构,也有物理架构。逻辑架构从逻辑的角度描述了事务如何工作。物理架构显示了事务日志是如何由数据库引擎物理实现和管理的。

逻辑架构

从逻辑上讲,事务日志可以被认为是一个包含一系列日志记录的顺序文件,这些日志记录记录了对数据库执行的不同类型的修改。每次更改数据库时,都会将一个或多个日志记录写入事务日志的逻辑端。写入的记录要么描述所执行的逻辑操作,要么包含实际数据更改前后的图像。之前的图像是数据库中数据更改之前的副本。后图是数据库修改后的数据图像。逻辑操作和前后映像不仅用于更新数据库,还用于在系统崩溃时撤销事务和/或恢复数据库。

写入的每条日志记录都由日志序列号 (LSN) 标识。LSN 标识日志记录写入日志的顺序。这意味着 LSN 值为 1 的日志记录会在 LSN 值为 2 的日志记录之前写入日志。

每个与事务相关联的 LSN 可以是活动的或非活动的。活动的 LSN 与尚未提交的事务相关联,而非活动的 LSN 与已提交的事务相关联。活动的最旧 LSN(最低 LSN 编号)称为最小恢复日志序列号或 MinLSN。图 1 是事务日志的逻辑表示,其中黄色的 LSN 是活动的 LSN。

SQL Server 事务日志文件体系结构

图 1:逻辑架构

物理架构

物理上,事务日志由一个或多个事务日志文件组成。日志文件被分成称为虚拟日志文件 (VLF's) 的块。事务日志可能有几个或多个 VLF,具体取决于事务日志的大小及其随时间的增长。每次事务日志需要增长时,都会创建额外的 VLF 并将其添加到 VLF 链中。为每个增长事件添加到事务日志的磁盘空间量将决定创建的新 VLF 的数量。

事务日志可以被认为是一个循环文件,由一个 VLF 到下一个 VLF 链接在一起组成。事务日志记录是从头写到尾,然后回绕,从头开始写。图 2 中的图表显示了具有 4 个不同 VLF 文件的事务日志,这些文件在逻辑上以循环方式链接在一起。红色虚线表示事务日志记录如何从第一个 VLF 写入到最后一个,然后循环返回并再次从第一个 VLF 开始写入。

SQL Server 事务日志文件行为“循环”

图 2:循环日志文件

循环日志文件的开头可以是事务日志中的任何一个 VLF。当 SQL Server 在写事务日志记录时碰到顺序日志文件的末尾,它会绕着顺序日志文件的开头开始写日志记录,只要日志文件的末尾永远不会到达逻辑日志文件的开头,如图3所示图2:循环日志文件。

如果日志文件的末尾到达日志文件的开头,则 SQL Server 将停止写入数据库,直到通过Log truncation或扩展物理文件来删除某些事务日志文件记录。如果当日志的结尾遇到开头时所有 VLF 都处于活动状态,则将扩展事务日志文件,并创建更多的 VLF。如果一些 VLF 在日志末尾遇到开头时处于非活动状态,那么数据库引擎将Log truncation以清空非活动 VLF,从而释放更多空间用于写入事务日志记录。当数据库处于简单恢复模式时,会自动清空不活动的 VLF,但当数据库处于完整或大容量日志恢复模式时,需要返回事务日志。

部分填充的事务日志显示日志文件的结尾和开头

图3;部分填充的事务日志

Log truncation

必须定期Log truncation文件以防止其填满。日志截断过程会清空仅包含已提交日志记录的 VLF 文件。这个清空过程从日志文件开头的 VLF 开始,直到它到达包含最小恢复日志序列号 (MinLSN) 的 VLF。MinLSN 是成功回滚最旧的未提交事务所需的最旧日志记录。在Log truncation之前,需要执行一个检查点命令。图 4 显示了在截断过程中如何清空已满的 VLF,并在清除 VLF 时重置日志的开头。图 4 显示日志文件从 VLF3 开始,并且 MinLSN 在日志截断之前包含在 VLF4 中。当截断过程发生时,它清空仅保存日志文件开头和包含 MinLSN 的 VLF 之间已提交日志记录的 VLF。在我的示例中,VLF3 被清空,日志文件的开头重新定位在 VLF4 的开头。

截断前后的图像

图 4:截断事务日志


原文链接:https://codingdict.com/