解释一下SQLSERVER事务日志记录

时间 2019-11-16

原文原文链接

解释一下SQLSERVER事务日志记录

你们知道在完整恢复模式下，SQLSERVER会记录每一个事务所作的操做，这些记录会存储在事务日志里，有些软件会利用事务日志来读取html

操做记录恢复数据，例如：log explorerweb

那么事务日志记录怎麽查看，里面都记录了些什么？数据库

打开能够利用下面SQL语句来查看所在数据库的事务日志记录ide

1 USE [GPOSDB] --要查看事务日志记录的数据库
2 GO
3 SELECT * FROM [sys].[fn_dblog](NULL,NULL)

事务日志记录里不少东西能够看的，里面记录了很是详细的数据库活动信息测试

我这里只介绍一些重要的须要知道的字段，其余字段因为本人能力有限并且以为其余字段不是很重要就不介绍了spa

CurrentLSN：当前LSN号，事务日志中的每一个记录都由一个惟一的日志序列号 (LSN) 标识。LSN 是这样排序的：若是 LSN2 大于 LSN1，3d

则 LSN2 所标识的日志记录描述的更改发生在日志记录 LSN1 描述的更改以后日志

MSDN解释：http://msdn.microsoft.com/zh-cn/library/ms190411(v=SQL.90).aspxcode

Operation：当前LSN所作的操做orm

Context：操做的上下文

TransactoinID：事务ID号

Log Record Fixed Length：LSN记录的所占虚拟日志文件的固定长度

Previous LSN：前一个LSN号

--------------------------------------------------------------------------------------------------------------

AllocUnitID：修改的那条数据所属分配单元ID

AllocUnitName：修改了数据的表名

Page ID：0001:00000121 转换成十进制：289 因此查看pageid为289页 DBCC PAGE([pratice],1,289,3)

Slot ID：数据所在数据页面的第几条记录

PartitionID：数据所在数据页面的所在分区ID

如上图，修改数据的表名是Insert_Test，Page ID是0001:00000121 转换为十进制为289 Slot ID是6（即数据页的第6条记录）

经过下面SQL语句就能够查看页面所在数据

1 USE [pratice]
2 GO
3 DBCC TRACEON(3604,-1)
4 GO
5 
6 DBCC PAGE([pratice],1,289,3)  
7 GO

 1 Slot 6 Offset 0x552 Length 211
 2 
 3 Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP     
 4 Memory Dump @0x0A2AC552
 5 
 6 00000000:   1000d000 3f080000 61616120 20202020 †....?...aaa              
 7 00000010:   20202020 20202020 20202020 20202020 †                         
 8 00000020:   20202020 20202020 20202020 20202020 †                         
 9 00000030:   20202020 20202020 20202020 20202020 †                         
10 00000040:   20202020 20202020 20202020 20202020 †                         
11 00000050:   20202020 20202020 20202020 20202020 †                         
12 00000060:   20202020 20202020 20202020 20202020 †                         
13 00000070:   20202020 20202020 20202020 20202020 †                         
14 00000080:   20202020 20202020 20202020 20202020 †                         
15 00000090:   20202020 20202020 20202020 20202020 †                         
16 000000A0:   20202020 20202020 20202020 20202020 †                         
17 000000B0:   20202020 20202020 20202020 20202020 †                         
18 000000C0:   20202020 20202020 20202020 20202020 †                         
19 000000D0:   0200fc†††††††††††††††††††††††††††††††...                      
20 
21 Slot 6 Column 0 Offset 0x4 Length 4
22 
23 id = 2111                            
24 
25 Slot 6 Column 1 Offset 0x8 Length 200
26 
27 name = aaa

这个表只有两个字段，咱们看一下表数据

--------------------------------------------------------------------------------------------------------

Checkpoint Begin：Checkpoint开始时间

Checkpoint Begin DB Version：当前数据库版本 SQL2005是611 SQL2012是706

Checkpoint End：checkpoint的结束时间，这个时间确定在Checkpoint Begin的下一条事务日志记录的位置

Minimum LSN: 这个第一个日志记录的日志序列号 (LSN)，称为最小恢复 LSN (MinLSN)

Dirty Pages：脏的数据页

Oldest Replicated Begin LSN：若是数据库配置复制的话，那么最老的复制起始LSN

Next Replicated End LSN:下一个复制结尾LSN

Last Distributed End LSN：最新的分发结尾LSN

SPID:执行当前操做的进程ID

Beginlog Status:开始记录事务日志的状态，这个状态表示现时可以正常记录事务日志

Begin Time：事务开始时间

Transaction Name：事务名称

End Time：事务结束时间

Transaction Begin：记录这个事务的begin transaction的时候的cureent LSN

Master DBID:显示当前master数据库的DBID

Preplog Begin LSN:启动数据库前的前一个事务日志LSN

Prepare Time:准备启动数据库的时间

New Split Page：哪一个数据页产生了页拆分

Rows Deleted：数据页有多少行被删除了

Description：描述这个事务是干什么的，有时候事务名称不必定就是他所作的操做名称，

好比这里碰巧事务名和描述都是CREATE TABLE 若是你为这个事务命名的话，那么只能看Description列看这个事务是作什么的

-------------------------------------------------华丽的分割线-------------------------------------------------------------------

如今解释一下一些常见operation和context，一些不常见的我也不知道，呵呵o(∩_∩)o

Operation：当前LSN所作的操做

Context：操做的上下文

DCM页的资料：http://www.cnblogs.com/lyhabc/archive/2013/01/21/2870392.html

Operation	Context	解释
LOP_SET_BITS	LCX_DIFF_MAP	设置位图，资料：差别(Differential)备份:只备份上次完整备份后，作修改的部分。备份单位是区(Extent)。意味着某个区内即便只有一页作了变更，则在差别备份里会被体现.差别备份依靠一个BitMap进行维护，一个Bit对应一个区，自上次完整备份后，被修改的区会被置为1，而BitMap中被置为1对应的区会被差别备份所备份。而到下一次完整备份后，BitMap中全部的Bit都会被重置为0 而这个BitMap在数据库第7页： DCM页差别变动(Differential Changed Map，DCM)页面他跟踪一个文件中的哪个区在最新一次完整数据库备份以后被修改过。SQLSERVER用在增量备份时只对已发生数据变动的分区进行增量备份便可
LOP_BEGIN_XACT		事务开始
LOP_MODIFY_ROW	LCX_HEAP	修改堆表中的某一行记录
LOP_PREP_XACT		准备启动数据库
LOP_COMMIT_XACT		提交事务
LOP_MODIFY_ROW	LCX_BOOT_PAGE	修改数据库启动页
LOP_MODIFY_HEADER	LCX_PFS	修改PFS页的页头部信息
LOP_INSERT_ROWS	LCX_CLUSTERED	插入数据到汇集索引的索引页
LOP_INSERT_ROWS	LCX_INDEX_LEAF	插入数据到索引的叶子节点即数据页
LOP_FORMAT_PAGE	LCX_CLUSTERED	从新组织汇集索引
LOP_DELETE_SPLIT	LCX_CLUSTERED	删除汇集索引表的一行记录引发页拆分
LOP_MODIFY_HEADER	LCX_HEAP	修改堆表的某页的页头信息
LOP_BEGIN_CKPT	LCX_NULL	检查点开始
LOP_END_CKPT	LCX_NULL	检查点结束
LOP_SET_FREE_SPACE	LCX_PFS	修改PFS页设置那个数据页是空闲的
LOP_ROOT_CHANGE	LCX_CLUSTERED	汇集索引的根节点改变
LOP_INSERT_ROWS	LCX_HEAP	插入数据到堆表

LOP_FORMAT_PAGE

LCX_HEAP

格式化堆里的数据页

Operation	Lock Information	解释
LOP_LOCK_XACT	HoBt 0:ACQUIRE_LOCK_SCH_M METADATA: database_id = 14 STATS(object_id = 7, stats_id = 11)	在事务里获取锁

-------------------------------------------------------华丽的分割线---------------------------------------------------

在大容量日志恢复模式下，在事务日志记录里你会看不到对数据页的操做，当你使用bcp ，bulk inert， select into大容量操做语句的时候

像下图的那样修改数据和插入数据的记录你在事务日志记录里找不到的

因此大容量日志恢复模式时，ldf文件才这麽小，插入速度才这麽快

下面引用MSDN:

http://msdn.microsoft.com/zh-cn/library/ms190925.aspx
能够尽可能减小日志量的操做
“最小日志记录”是指只记录在不支持时间点恢复的状况下恢复事务所需的信息。本主题介绍在大容量日志恢复模式下（以及简单恢复模式下）按最小方式记录、但在运行备份时例外的操做。
注意
在完整恢复模式下，全部大容量操做都将被完整地记录下来。可是，能够经过将数据库暂时切换到用于大容量操做的大容量日志恢复模式，最小化一组大容量操做的日志记录。最小日志记录比完整日志记录更为有效，并在大容量事务期间，下降了大规模大容量操做填满可用的事务日志空间的可能性。不过，若是在最小日志记录生效时数据库损坏或丢失，则没法将数据库恢复到故障点。
下列操做在完整恢复模式下执行完整日志记录，而在简单和大容量日志恢复模式下按最小方式记录：
大容量导入操做（bcp、BULK INSERT 和 INSERT...SELECT）。有关在什么时候对大容量导入表按最小方式进行记录的详细信息，请参阅在大容量导入中按最小方式记录日志的前提条件。
注意
启用事务复制时，将彻底记录 BULK INSERT 操做，即便处于大容量日志恢复模式下。
SELECT INTO 操做。
注意
启用事务复制时，将彻底记录 SELECT INTO 操做，即便处于大容量日志恢复模式下。
插入或追加新数据时，使用 UPDATE 语句中的 .WRITE 子句部分更新到大型值数据类型。注意，在更新现有值时没有使用最小日志记录。有关大型值数据类型的详细信息，请参阅数据类型 (Transact-SQL)。
在 text、ntext 和 image 数据类型列中插入或追加新数据时的 WRITETEXT 和 UPDATETEXT 语句。注意，在更新现有值时没有使用最小日志记录。
注意
不推荐使用 WRITETEXT 语句和 UPDATETEXT 语句，所以应该避免在新的应用程序中使用这些语句。
若是数据库设置为简单或大容量日志恢复模式，则不管是脱机仍是联机执行操做，都会按最小方式记录一些索引 DDL 操做。按最小方式记录的索引操做以下：
CREATE INDEX 操做（包括索引视图）。
ALTER INDEX REBUILD 或 DBCC DBREINDEX 操做。
注意
不推荐使用 DBCC DBREINDEX 语句，所以应该避免在新的应用程序中使用该语句。
DROP INDEX 新堆从新生成（若是适用）。
注意
DROP INDEX 操做期间将始终完整记录索引页的释放操做。

还能够看一下这篇帖子，关于大容量日志恢复模式

http://social.msdn.microsoft.com/Forums/zh-CN/958febc2-5eaf-46e4-b658-4bea087c0b0f

 1 0
 2 投票
 3 另外，作了下测试。
 4 
 5 在Bulk logged模式下，日志中仅记录对Page（好比IAM，PFS和GAM）的操做，没有记录数据。。
 6 
 7 Operation                          Context                   AllocUnitName
 8 LOP_MODIFY_ROW        LCX_PFS        dbo.SomeTable
 9 LOP_SET_BITS               LCX_IAM        dbo.SomeTable
10 LOP_SET_BITS               LCX_GAM        dbo.SomeTable
11 LOP_MODIFY_ROW        LCX_PFS        dbo.SomeTable
12 LOP_SET_BITS                LCX_IAM        dbo.SomeTable
13 LOP_SET_BITS                LCX_GAM        dbo.SomeTable
14 LOP_MODIFY_ROW        LCX_PFS        dbo.SomeTable
15 LOP_SET_BITS                LCX_IAM        dbo.SomeTable
16 可是对于处于Full模式下的DB，除了包含这部分数据，还有记录Data的部分。
17 
18 那处于Bulk Logged模式下，所作的事务日志备份，是怎么抓取到数据变化的呢？
19 
20 我作了实验，处于Bulk logged模式下，执行了事务备份，以后仍是能够经过该备份文件来恢复到select * into 操做以后。
21 
22 select * into ../....from ......这个应该是能够最小化日志的操做吧。

帖子里面说到，不记录事务日志，那么怎麽进行数据库还原呢？实际上经过数据库的系统页BCM页来记录数据页的变动的

参考资料：SQL Server 2008 存储结构之DCM、BCM

BCM页面结构

 1 DBCC 执行完毕。若是 DBCC 输出了错误信息，请与系统管理员联系。
 2 
 3 PAGE: (1:7)
 4 
 5 
 6 BUFFER:
 7 
 8 
 9 BUF @0x03EDB9F4
10 
11 bpage = 0x170E4000                   bhash = 0x00000000                   bpageno = (1:7)
12 bdbid = 5                            breferences = 1                      bUse1 = 14098
13 bstat = 0xc00009                     blog = 0x32159                       bnext = 0x00000000
14 
15 PAGE HEADER:
16 
17 
18 Page @0x170E4000
19 
20 m_pageId = (1:7)                     m_headerVersion = 1                  m_type = 17
21 m_typeFlagBits = 0x0                 m_level = 0                          m_flagBits = 0x0
22 m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
23 Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
24 m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 90
25 m_slotCnt = 2                        m_freeCnt = 6                        m_freeData = 8182
26 m_reservedCnt = 0                    m_lsn = (0:0:1)                      m_xactReserved = 0
27 m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = 0
28 
29 Allocation Status
30 
31 GAM (1:2) = ALLOCATED                SGAM (1:3) = NOT ALLOCATED           PFS (1:1) = 0x44 ALLOCATED 100_PCT_FULL
32 DIFF (1:6) = CHANGED                 ML (1:7) = NOT MIN_LOGGED            
33 
34 ML_MAP: Header @0x09C2C064 Slot 0, Offset 96
35 
36 status = 0x0                         
37 
38 ML_MAP: Extent Alloc Status @0x09C2C0C2
39 
40 (1:0)        - (1:43256)    = NOT MIN_LOGGED                              
41 
42 
43 DBCC 执行完毕。若是 DBCC 输出了错误信息，请与系统管理员联系。

View Code

----------------------------------------------------华丽的分割线-------------------------------------------------

你们有兴趣能够看一下我写的这篇文章，更加了解事务日志

对SQLSERVER数据库事务日志的疑问

http://www.cnblogs.com/lyhabc/archive/2013/06/10/3130856.html

根据上面事务日志中的这几个字段，LOG EXPLORER软件为什麽能恢复数据生成insert脚本，估计是读取事务日志中删除了数据的数据页id

而后到数据页里先保存下数据，可是若是使用大容量日志恢复模式或者使用truncate table语句估计LOG EXPLORER软件也救不了你

由于delete语句不管是where 删除某条记录仍是全表delete应该都会每条记录生成一个事务日志记录,即生成一个LSN

可是大容量日志恢复模式或者使用truncate table语句是不记录每行数据的LSN的，可能只记录删除动做

AllocUnitID：修改的那条数据所属分配单元ID

AllocUnitName：修改了数据的表名

Page ID：数据页ID

Slot ID：数据所在数据页面的第几条记录

PartitionID：数据所在数据页面的所在分区ID

--------------------------------------------------华丽的分割线-------------------------------------------------------

当你备份事务日志并截断日志以后，而后你没有对数据库作任何操做，可是依然会看到有事务日记记录生成

至于缘由，因为篇幅关系，你们能够到个人另外一篇博文的最下面那个问题，里面有答案

为什麽完整备份以后日志记录会增长，有时候备份完以后会增长，有时候备份完以后会减小？？？

由于数据库启动的时候必定修改一些系统数据库页因此确定会有一些事务日志记录生成

文章地址：对SQLSERVER数据库事务日志的疑问

------------------------------------------------------------------------------------------------------

文章有什么不对的地方，你们必定要拍砖哦o(∩_∩)o