如何读懂SQL Server的事务日志

简介


本文将介绍SQL
Server的事务日志中记录了哪一些信息,如何来读懂这些事务日志中信息。首先介绍一个微软没有公开的函数fn_dblog,在文章的接下来的部分主要用到这个函数来读取事务日志。

  1. fn_dblog(@StartingLSN,@EndingLSN)

  2. [email protected]:表示起始的LSN号,如果为NULL值则表示从首日志记录开始查询。

  3. [email protected]:表示结束的LSN号,如果为NULL值则表示查询到尾日志记录。

  4. --需要注意的是我们平时所看到的LSN都是十六进制的,而这边的参数需要转化为十进制,如00000021:00000077:0003在作为参数传给fn_dblog时需要转换为33:119:3

正文


  1. --创建测试数据库

  2. USE [master];

  3. GO

  4. CREATEDATABASE
    TestDB;

  5. GO

  6. --
    创建表

  7. USE TestDB;

  8. GO

  9. CREATETABLE
    [Location] (

  10.     [Sr.No]
    INTIDENTITY,

  11.     [Date]
    DATETIMEDEFAULT
    GETDATE (),

  12.     [City] CHAR
    (25) DEFAULT
    ‘xiamen‘);

通过上面的代码创建了一个名为TestDB的数据库,并创建了一个三个字段的表。接下看看事务日志的内容

  1. USE TestDB;

  2. GO

  3. select [Current
    LSN],

  4.        [Operation],

  5.        [Transaction
    Name],

  6.        [Transaction
    ID],

  7.        [Transaction
    SID],

  8.        [SPID],

  9.        [BeginTime]

  10. FROMfn_dblog(null,null)

从上图可以看出总共产生了195行日志记录,我截取了部分的结果,在Operation列中记录了对应的LSN所做的操作,其中LOP_BEGIN_XACT表示一个事务的开始,Transaction
Name显示了创建的数据库的名称,而Trasaction ID则记录了所对应的事务ID。下面列出Operation几种比较常见而重要的值

  • LOP_BEGIN_XACT
    事务的开始

  • LOP_LOCK_XACT
    获取锁

  • LOP_MODIFY_ROW
    修改行(具体修改的对象可以查看AllocUnitName)

  • LOP_COMMIT_XACT
    提交事务

  • LOP_DELETE_ROWS
    删除数据

  • LOP_INSERT_ROWS插入数据
接下来向表中插入100行数据,并查看对应的事务日志,代码如下:


  1. INSERTINTO
    Location DEFAULTVALUES

  2. GO 100

  3. GO

  4.  

  5. SELECT

  6.  [Current
    LSN],

  7.  [Transaction
    ID],

  8.  [Operation],

  9.   [Transaction
    Name],

  10.  [CONTEXT],

  11.  [AllocUnitName],

  12.  [Page ID],

  13.  [Slot ID],

  14.  [BeginTime],

  15.  [EndTime],

  16.  [Number of
    Locks],

  17.  [Lock Information]

  18. FROM sys.fn_dblog(NULL,NULL)

  19. WHERE
    Operation = ‘LOP_INSERT_ROWS‘ AND
    AllocUnitName = ‘dbo.Location‘

得到如上图所示的结果,返回的行数与我们insert的次数一致,接下来取其中的一个Trasaction
ID来看看一次insert在事务日志中记录了哪些动作。

  1. SELECT

  2.  [Current
    LSN], [Transaction
    ID], [Operation], [Transaction
    Name], [CONTEXT], [AllocUnitName], [Page ID], [Slot ID], [BeginTime],
    [EndTime],
    [Number of
    Locks], [Lock Information]

  3. FROM sys.fn_dblog(NULL,NULL)

  4. WHERE [Transaction
    ID] = ‘0000:000002fc‘

从图中可以看出这个Transaction执行步骤的详细信息

  • 在2014/05/25 18:35:39:197事务开始

  • 在堆表dbo.Location的PAGEID为0001:0000004f插入数据

  • 在2014/05/24 18:35:39:200提交事务

下面这一段是我从Lock
Information栏位复制出的内容,来详细的看一下

  1. HoBt 72057594039042048:ACQUIRE_LOCK_IX OBJECT:
    6:245575913:0 ;ACQUIRE_LOCK_IX PAGE: 6:1:79 ;ACQUIRE_LOCK_X RID: 6:1:79:0

通过下面的代码我们来验证一下,这样一条INSERT语句所获得的锁信息

  1. DBCC
    TRACEON(-1,3604)

  2. DBCC TRACEON
    (-1,1200)--查看当前Session的锁信息

  3. BEGINTRAN

  4. INSERTINTO
    Location DEFAULTVALUES

  5. ROLLBACKTRAN

  6. DBCC TRACEOFF
    ( -1,1200)

  7. DBCC TRACEOFF
    ( -1,3604)

  8. /*

  9. Process
    57 acquiring IX lock on OBJECT: 6:245575913:0 (class bit2000000 ref1) result:
    OK

  10. Process
    57 acquiring IX lock on PAGE: 6:1:79 (class bit2000000 ref0) result: OK

  11. Process
    57 acquiring X lock on RID: 6:1:79:90 (class bit2000000 ref0) result: OK

  12. */

可以看到Lock
Information栏位所记录的信息与1200跟踪标记锁输出的信息是一致的。

另外从事务日志中还可以看到SQL Server的一些内部操作,并看到这些操作一些具体信息,如开始的时间,进行的次数,操作的步骤等等。接下来看看页拆分的动作

  1. --查找页拆分动作的Transaction

  2. SELECT

  3.  [Current
    LSN], [Transaction
    ID], [Operation], [Transaction
    Name], [CONTEXT], [AllocUnitName], [Page ID], [Slot ID], [BeginTime],
    [EndTime],
    [Number of
    Locks], [Lock Information]

  4. FROM sys.fn_dblog(NULL,NULL)

  5. WHERE [Transaction
    Name] = ‘SplitPage‘

  6. --查看具体Transaction中的动作

  7. SELECT

  8.  [Current
    LSN], [Transaction
    ID], [Operation], [Transaction
    Name], [CONTEXT], [AllocUnitName], [Page ID], [Slot ID], [BeginTime],
    [EndTime],
    [Number of
    Locks], [Lock Information]

  9. FROM sys.fn_dblog(NULL,NULL)

  10. WHERE [Transaction
    ID] = ‘0000:000002f8‘

结语

通过了解事务日志中所记录的内容,可以更方便我们去了解SQL Server所做的一些操作的执行过程。

时间: 2024-10-11 23:13:06

如何读懂SQL Server的事务日志的相关文章

SQL Server中事务日志管理的步骤,第5级:完全恢复模式管理日志

SQL Server中事务日志管理的步骤,第5级:完全恢复模式管理日志 作者:Tony Davis,2012/01/27 系列 本文是进阶系列的一部分:SQL Server中事务日志管理的步骤 当事情进展顺利时,无需特别注意事务日志的作用或工作方式.您只需要确信每个数据库都有正确的备份机制.当出现问题时,了解事务日志对于采取纠正措施很重要,特别是在需要紧急恢复数据库的时间点时!Tony Davis给出了每个DBA都应该知道的正确的细节级别. 在此级别中,我们将回顾在完全恢复模式下工作时进行日志备

十七周-SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志

SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志 By Tony Davis, 2012/01/27 http://www.sqlservercentral.com/articles/Stairway+Series/73785/ 该系列 文是SQL Server中"Stairway系列:事务日志管理的阶梯"的一部分 当事情进展顺利时,不需要特别意识到事务日志的作用或工作原理.你只需要确信每个数据库都有正确的备份机制.当事情出错时,对事务日志的理解对于采取纠正措施

XenDesktop 5 SQL Server Mirror事务日志比较大的原因分析

在实施XenDesktop5项目过程中,发现XenDesktop5版本的数据库镜像事务日志很大,在XenDesktop4和XenApp版本中不存在该问题:于是我根据该现象探究XenDesktop5及以上版本镜像数据库事务日志为何如此之大以及我们今后实施的过程中该如何来维护这么庞大的数据库事务日志. 在XenDesktop解决方案中,对数据的处理是由专门的数据库来进行数据存储处理的,而对于数据库的高可用,有3种方式: SQL Mirror Virtual Machine HA(VMware FT)

XenDesktop SQL Server Mirror事务日志维护

当使用SQL Server高可用性功能的时候,例如,XenDesktop站点数据库使用完整的事务日志记录模式下运行的数据库镜像. 通过完整的事务日志记录模式下运行的事务日志会增长过大,直到数据库空间被填满或事务日志空间大小被填满.如果事务日志文件不会被监视的,默认情况下,SQL Server的配置日志文件会自动增长.这将导致2个问题: 1.事务日志文件会占用大量的磁盘空间 2.事物日志增长填满数据库空间,导致数据库不可用. 因此Citrix建议定期备份日志文件.这可以通过调度作业或维护计划来完成

SQL Server数据库事务日志序列号(LSN)介绍

原文:http://blog.csdn.net/tjvictor/article/details/5251463 ? ? 日志序列编号(LSN)是事务日志里面每条记录的编号. 当你执行一次备份时,一些LSN值就被同时存储在文件本身及msdb..backupset表中.你可以使用RESTORE HEADERONLY语法来从备份文件中获取LSN值. ? 注意:在SQL Server 2000中,有一列叫做DifferentialBaseLSN.但在SQL Server 2005中,相同的列名称变成了

SQL Server备份事务日志结尾(Tail)

原文:http://blog.csdn.net/tjvictor/article/details/5256906 ? 事务日志结尾经常提交数据库未备份的事务日志内容.基本上,每一次你执行事务日志备份时,你都在执行事务日志结尾的备份. 那为什么会这么设计呢?因为也许由于介质的损坏,当数据库已经不再可用时,麻烦就来了.如果下一个逻辑步骤正好就是要备份当前事务日志的话,可以应用这个备份来使数据库处于等待(Standby)状态.你甚至可以在数据库文件不可用的状态下使用NO_TRUNCATE来备份事务日志

SQL SERVER的事务日志

1 基本介绍 每个数据库都具有事务日志,用于记录所有事物以及每个事物对数据库所作的操作. 日志的记录形式需要根据数据库的恢复模式来确定,数据库恢复模式有三种: 完整模式,完全记录事物日志,需要定期进行日志备份. 大容量日志模式,适用于批量操作的数据库,可以以更压缩的方式处理日志,需要定期进行日志备份. 简单模式,也有日志文件,只是该模式下可以通过checkpoint自动重用virtual log file,所以日志文件会处于一直重复使用的过程,保持一定大小,但是,如果有一个事务启动,很久没有co

为什么SQL Server需要事务日志

为什么我们需要事务日志,可不可以删除或者不添加日志文件?答案是否定的,如果没有事务日志,你的数据库根本无法工作! 事务日志支持以下操作: 事务回滚 如果用户或程序使用了Rollback 语句或者是数据库检测到了失败的操作 . 这些日志文件就会被用来做回滚. 恢复未完成的事务 如果你在数据库发生错误时重新启动数据库服务器(服务),可能发现数据库处于恢复模式(In Recovery),这表明数据库正在回滚服务器(服务)重启之前未完成的事务,或者是继续执行那些已经写入到了日志文件却没有写入数据文件的事

SQL Server数据库事务日志存储序列

原文 原文:http://blog.csdn.net/tjvictor/article/details/5251351 ? 如果你的数据库运行在完整或是批量日志恢复模式下,那么你就需要使用作业(job)来定期备份事务日志,保持你的事务文件大小处在一个可管理的范围.当你需要还原事务日志时,你就需要按照创建事务日志的顺序来恢复它们.你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序,使用FirstLSN和LastLSN列的值作参考.当你备份时,这些备份信息就会存在backup