在事务日志中,数据变化被记录在一个连续的日志记录中,且每一个记录都有一个编号,叫做日志序列编号(Log Sequence Number, LSN)。 在事务日志中,每一个日志记录都被存储在一个虚拟日志文件中。事务日志可以有任意多个虚拟日志文件,数量的多少取决于数据库引擎,而且每个虚拟日志文件的大小也不是固定的。 如上图所示,活动区间(active portion)的日志就是包含我们事务的区域。这区间就是完整恢复数据库所需要的。当更多的事务被创建时,活动区间的日志也会随着增长。 那么当CheckPoint被执行时,会发生什么变化呢?答案是:所有有变化的数据写到数据文件中,然后创建一个检查点记录(CheckPoint record)。 现在,由事务1,2,3所导致的变化将会被写到数据文件中。因为事务3没有被提交,所以活动区间日志的范围变成了从LSN50到LSN52之间。如果使用简单恢复模型的话,那么LSN45到LSN49之间区域可以被重用,因为那些记录已经不再需要了。 当SQL Server把虚拟日志文件1和2作为可重用区域时,事务日志也相应被截断(Truncate)。需要注意的是,物理日志大小也会随着变动。如果数据库运行在完整或是批量日志恢复模型下,那么从LSN45到49之间的区域将被删除(delete),而且直到事务日志被备份后,这段区域的空间才会被重用。 那么当更新的事务被创建时,又会发生什么呢?在简单模式下,日志的起始空间将会被重用。 在完整或是批量日志恢复模型下,事务日志的空间则会被扩展。 假如事务日志是一个固定大小的日志,那么在SQL Server2000系统中,你会收到如下错误信息: Server: Msg 9002, Level 17, State 6, Line 1 在SQL Server 2005里面,错误会显示为: Msg 9002, Level 17, State 4, Line 1 注意:并不是说运行在简单恢复模式下的数据库永远都不会遇到9002的错误。如果你有一个很长的、正在运行的、未提交的事务,那么你的事务日志依然会被填满,因为SQL Server不能删除任何一个已经开始运行之后被创建的日志。也就是说,活动区间里面的日志从事务起始时被记录,并且已经没有活动区间可以被删除或是重用了。 所以,要保持你的事务日志基本处理一个可管理的范围:
为了找出数据库中最起始的活动事务,特别是事务起始时间时,就可以使用DBCC OPENTRAN命令,例如: DBCC OPENTRAN 结果为: Transaction information for database 'AdventureWorks'. 为了找出每一个数据库已经使用的日志空间大小,可以使用DBCC SQLPERF命令: DBCC SQLPERF(LOGSPACE) 为了找出事务日志使用了多少虚拟日志数量,可以使用DBCC LOGINFO命令。它显示的细节内容就是你当前所连接数据库的内容,下面就是AdventureWorks数据库的输出: 从上图我们可以得到如下信息:你的事务日志中有四个虚拟日志文件(一行一个),且所有虚拟日志文件包括在一个单一的物理文件中 (FileId=2)。第一,二,三的虚拟日志文件大小是458752比特,最后一个虚拟日志文件的大小是712704比特。1~3虚拟文件从来没有被使用或是重用过(Status=0), 第四个虚拟日志文件正在被使用(Status=2)。虚拟日志文件在物理上的布局具有连接的编号(FSeqNo是递增的), 实际情况可能与此有所不同。
|
一个小例子揭示事务日志的工作原理
最新推荐文章于 2024-04-19 16:12:43 发布
2012-03-13 11:02