SQL Server事务日志管理的阶段，1级：事务日志概述

SQL Server事务日志管理的阶段，1级：事务日志概述

作者：Tony Davis，2013年10月30日（第一版：2011/06/17）

该系列

本文是SQL Server中“Stairway系列：事务日志管理的阶梯”的一部分

当一切都很顺利,没有需要特别意识到什么事务日志或它是如何工作的。 你只需要相信,每个数据库都有正确的备份机制。 当事情出错时,事务日志的理解是非常重要的采取纠正行动,特别是在一个时间点恢复的数据库是必需的,紧急! 托尼·戴维斯给正确的细节层次,每一个DBA应该知道。

1级:事务日志的概述

SQL Server的事务日志是一个文件存储的记录所有的事务和数据修改的数据库上执行日志文件相关联。 在发生灾难,导致SQL Server意外关闭,如一个实例或硬件故障,使用事务日志恢复数据库,数据完整性已婚。 数据库重新启动后,进入恢复过程事务日志的阅读,以确保所有有效,提交的数据写入数据文件(向前滚)和影响任何部分,未提交的事务是撤销(回滚)。 简而言之,事务日志是SQL Server的基本手段确保数据库的完整性和事务的ACID属性,特别是耐久性。

一些最重要的职责的DBA对管理事务日志如下:

• 选择正确的恢复模型- SQL Server提供了三个数据库恢复模型:全部(默认),简单和批量记录。 DBA必须选择合适的模型数据库,根据业务需求,然后建立维护程序适当的模式。
• 执行事务日志备份——除非在简单的模式,它是至关重要的的DBA执行常规备份事务日志。 一旦捕捉到一个备份文件,可以随后用于日志记录为了执行完整数据库备份数据库恢复,所以重新创建数据库,因为它存在在先前的时候,例如在一个失败。
• 监控和管理日志增长- - - - - -在一个繁忙的数据库事务日志可以在规模快速增长。 如果不定期备份,或者不适当地大小,或分配不正确的生长特性,事务日志文件可以填满,导致臭名昭著“9002”(事务日志已满)错误,这让SQL Server变成“只读”模式(或进入“资源等待”模式,如果它发生在复苏期间)。
• 优化日志的吞吐量和可用性——除了基本的维护,如备份,DBA必须采取措施确保事务日志的足够的性能。 这包括硬件方面的考虑,以及避免日志分散等情况,从而影响事务的性能

     在这个楼梯系列,我们将考虑这些核心维护任务的细节。 在这里,在第一个层面上,我们将首先从一个SQL服务器如何使用事务日志的概述,和两个最重要的方式影响DBA的生活,即数据库恢复和恢复、磁盘空间管理。

SQL Server如何使用事务日志

　　在SQL Server中,事务日志是一个物理文件,发现传统,虽然不是强制,由法律辩护基金扩展。 在创建一个数据库,自动创建主数据文件,一般确定的MDF扩展,尽管可以使用任何扩展,存储数据库对象和数据本身。 事务日志,通常实现为一个单一的物理文件,也可以作为一组文件实现。 然而,即使在后一种情况下,它仍然是被SQL Server作为一个顺序文件,因此,SQL Server不能并行,不写多个日志文件,所以没有性能优势实现事务日志的多个文件。 这是更详细地讨论7级——规模和增长的事务日志。

　　当t - sql代码更改一个数据库对象(DDL),或者它所包含的数据,不仅是数据或对象中更新数据文件,但也改变记录的细节日志记录事务日志。 每个日志记录包含有关执行的事务ID的细节变化,事务开始和结束时,哪些页面被改变,数据变化,等等。

　　注意:事务日志不是一个审计跟踪。 它没有提供一个审计跟踪更改的数据库; 它不记录对数据库执行的命令,是多么的数据改变了结果。

　　数据修改时,相关的数据页,希望从数据缓存读取,或者从磁盘检索如果他们不是已经在缓存中。 数据被修改的数据缓存和日志记录来描述的影响事务日志缓存中创建。 在事务提交时,日志记录写入事务日志,在磁盘上。 然而,实际的更改的数据可能不是写入磁盘,直到以后当一个数据库检查点发生。 任何页面的缓存被从磁盘读取,这样以来被修改缓存中的数据值是不同的磁盘上被称为一个肮脏的页面。 这些脏页可能同时包含:

• 数据提交和“硬”事务日志文件但没有数据文件
• 数据修改公开交易即那些尚未提交或回滚

　　定期数据库检查点进程扫描数据缓存和所有脏页刷新到磁盘,此时的修改反映在物理数据文件和日志文件。 这种情况甚至在一个事务的情况下仍然开放; 在一个检查站,脏页刷新到磁盘开放相关事务,与SQL服务器总是确保日志记录与这些开放交易从日志缓存刷新前,事务日志文件脏页面刷新到数据文件。

　　注意:扫描数据缓存的另一个进程,LazyWriter,也可以写脏数据页写到磁盘,以外的一个检查点,如果被迫通过内存压力。

　　需要注意的重要的一点是,日志缓冲区管理器总是保证变化描述(日志记录)写入事务日志,在磁盘上,之前数据页面写入到物理数据文件。 这种机制称为写前日志记录。 它本质上是SQL Server的机制确保事务持久性(见ACID属性数据库事务)。

　　总是先写更改日志文件,SQL Server的基础机制,可以保证所有已提交的事务的影响最终将反映在数据文件,并修改磁盘上的任何数据,来自不完整的交易,即那些提交和回滚的最终发行不反映在数据文件中。

　　如果数据库崩溃了,例如,在一个特定的事务(T1)提交但在受影响的数据写入数据文件,然后重启后,数据库恢复过程启动它试图协调事务日志文件的内容和数据文件。 它会读取事务日志文件,并确保所有的操作,包括事务T1,记录在日志文件中,是“向前滚”(重做),这样他们反映在数据文件中。

　　同样,数据库崩溃之后,经济复苏过程将“回滚”(撤销)数据库中的任何数据变化与未提交的事务相关联,通过读取日志文件的相关操作,并执行相反的物理操作数据。

　　通过这种方式,SQL Server可以返回数据库处于一致状态,在发生崩溃。 更普遍的是,如果发生回滚(撤销)过程:

• 显式事务的回滚命令发出
• 发生错误和XACT_ABORT打开
• 如果数据库检测到数据库和客户端之间的通信已被打破,煽动事务。

　　在这种情况下,日志记录用于修饰或说明一种中断交易,或发出的回滚命令显式地,读取和更改回滚。 在这些方面,SQL Server确保所有与一个事务相关联的行动成功,作为一个单元,或者他们都失败。 因此,事务日志是SQL Server的一个基本手段确保数据一致性和完整性在正常的日常操作。

　　然而,事务日志中另一个重要的角色,它提供了数据库的机制恢复前一个时间点,在发生灾难。 通过适当的规划和管理,您可以使用这些日志文件的备份恢复所有的数据,它成为损坏或无法使用。

事务日志和数据库恢复

　　正如前面所讨论的,一个事务日志文件存储一系列的日志记录,连续在事务开始时,提供修改的历史记录和数据库事务已经发出。 每个日志记录包含有关执行的事务ID的细节变化,事务开始和结束时,哪些页面被改变,数据变化,等等。 日志记录在事务日志文件被组织成多个部分,称为虚拟日志文件(甚低频)——这些都包含在更多的细节水平2 -事务日志的架构。

　　SQL Server的写前日志记录机制保证修改的描述(如日志记录)将写入甚低频之前修改数据本身被写入数据文件。 因此,日志记录可能包含的细节,一个封闭的(承诺)事务或开放(未提交)事务,并在每种情况下数据修改的事务可能会或可能不会被写入数据文件,根据是否发生了一个检查站。

　　注意:通过定期冲洗脏页缓存到磁盘,数据库检查点过程控制的工作量SQL Server数据库恢复操作期间需要做的。 如果SQL Server滚更改了大量的脏页的已提交的事务,然后复苏过程可能非常冗长。

　　任何日志记录有关的可能需要打开的事务回滚操作,在复苏,将永远是一个部分称为一个活跃的甚低频和将永远留存在日志文件中。 日志记录相关的一个封闭的事务也将积极甚低频的一部分,直到到达这一点没有日志记录在整个甚低频与开放相关联交易,此时甚低频变得不活跃的。

　　这些活动的日志记录甚低频本质上提供了一个“历史”之前完成数据库的事务,并发生这些不活跃的甚低频变化取决于数据库的恢复模型。 我们将详细讨论这些复苏模型级别3 - 6的楼梯,但这里的关键是,如果您使用的是完整的(或批量记录)数据库恢复模型,那么事务日志保留在不活跃的甚低频日志记录,直到一个日志备份(不久)。

　　通过备份事务日志,我们可以捕捉到一个备份文件中的所有日志记录生活日志,包括在这些不活跃的甚低频。 这些日志备份数据库可以用来恢复之前的时间点; 希望时间点非常接近的一些“灾难”发生。 这样的灾难时,日志备份文件可以应用于恢复完全数据库备份文件的副本,和完整备份之后发生的任何交易将“向前滚”,在数据库恢复,恢复数据库和恢复数据到一个给定的时间点上,所以任何数据损失最小化。 当然,这假设您不仅拍摄这些日志备份,而且他们转移到一个安全的位置。 如果您的日志备份文件在相同的驱动生活日志文件,和硬盘坏了,那么你可能会失去你所有的备份。

　　当一个数据库是在简单恢复模式(在水平3和4),日志记录的活跃的甚低频被保留,因为他们可能需要回滚操作。 然而,不活跃的甚低频将截断发生检查站时,这意味着这些甚低频的日志记录可以立即覆盖新的日志记录。 这就是为什么数据库操作简单恢复被称为auto-truncate模式。 在这种模式下,没有“历史”中维护日志,因此它不能被捕获在一个日志备份和恢复过程的一部分。

控制日志文件的大小

　　希望前面的讨论已经明确表示,对于大多数生产数据库操作的全面复苏模式,有必要采取定期备份事务日志文件,以使恢复数据库的一个特定的时间点。

　　然而,还有一个重要的原因把这些日志备份操作时全额(或BULK_LOGGED)模式和控制日志的大小。 记住,日志记录被写入日志文件为每个事务修改数据或SQL Server数据库中的对象。 在一个繁忙的系统中,有许多并发事务,或编写大量的数据,事务日志可以很快变大。

　　在完全(或BULK_LOGGED)模式下工作时,捕获在一个备份文件的副本在不活跃的甚低频日志记录,是唯一的行动,会让那些甚低频资格截断,这意味着占用的空间日志记录可用以便重用。

　　一个简短的笔记上截断事务日志的大小:有一个常见的误解是,删除日志文件意味着删除日志记录和文件的大小减少。 它不; 截断的日志文件仅仅是将空间标记为可以重用。 截断,在每个不同的恢复模型的上下文中,将更详细地讨论在随后的水平。

因此,至关重要的一个原因是执行常规事务日志备份工作时全额(或BULK_LOGGED)模式来控制日志的大小。

一个简单的备份事务日志的例子

　　为了简要说明了我们讨论的一些概念在这第一层,我们将介绍一个非常简单的示例数据库的事务日志备份操作在完整恢复模式。 每个流程的细节和命令将更详细地介绍在随后的水平。

　　在清单1.1中,我们创建一个新的数据库TestDB SQL Server 2008实例,然后立即获取日志文件的大小使用DBCC SQLPERF(LOGSPACE)命令。

清单1.1:新的初始日志文件大小TestDB数据库

　　正如你所看到的,日志文件目前大约1 MB的大小,约30%。

　　注意:初始大小和生长特性的用户数据库上创建一个实例是由模型的属性数据库,是默认恢复模型,每个数据库将使用(满了,在这种情况下)。 我们将讨论这些属性的影响更多的细节7级——规模和增长的事务日志。

确认文件的大小可以通过简单地定位磁盘上的物理文件,如图1.1所示。

 

　　图1.1：TestDB的数据和日志文件

　　现在让我们为TestDB执行数据文件的备份，如清单1.2所示（首先需要创建“Backups”目录）。 请注意，此备份操作可确保数据库真正在FULL恢复模式下运行; 更多关于这个在3级 - 交易日志，备份和恢复。

清单1.2:TestDB最初的完整备份

　　没有数据或日志文件的大小的变化,由于这种备份操作,或者使用的日志空间的百分比,这可能是奇怪没有用户表或数据库中的数据,。 让我们把权利,创建一个名为LogTest这个数据库的表,100万行数据,再检查日志文件的大小,如清单1.3所示。 这个脚本的作者,经常看到在SQLServerCentral.com论坛,是杰夫的现代化,它复制了他的权限。 不要担心的细节代码; 唯一重要的事情是,我们插入行。 这段代码可能需要几秒执行在您的机器上,这并不是因为代码效率低下; 这都是在幕后工作,编写的数据和日志文件。

清单1.3:一百万行插入LogTest表,TestDB

　　注意,日志文件大小已经飙升至近110 MB,日志是91%完整(系统)上的数据可能略有不同。 如果我们要插入更多的数据,它会再次变大,以适应更多的日志记录。 再次,大小增加可以证实的物理文件(数据文件已发展到64 MB)。

我们可以再次备份数据文件在这一点上,通过重新运行清单1.2中,并将日志文件的大小没有影响,或空间中使用的文件的百分比。 然而,现在让我们备份事务日志文件并重新检查值,如清单1.4所示。

清单1.4:备份事务日志TestDB

　　日志文件仍然是相同的物理尺寸,但通过备份文件,SQL Server能够截断日志,使空间日志文件中的“不活跃”甚低频可供重用; 可以添加更多的日志记录文件而不需要身体生长。 当然,我们已经占领了日志记录到一个备份文件,所以可以使用该文件作为数据库恢复过程的一部分,我们应该需要恢复TestDB数据库到先前的状态。

总结

　　在第一个层面上,我们介绍了事务日志,并解释了如何使用SQL Server来维护数据一致性和完整性,通过写前日志记录机制。 我们还描述,并简要说明,DBA可以捕捉事务日志文件的内容到一个备份文件,然后可以重用恢复数据库恢复过程的一部分。 最后,我们强调备份的重要性在控制事务日志的大小。

在下一个级别,我们会仔细查看事务日志的架构。