（3.5）存储引擎--日志

Posted 2020-12-04 gered

一. 日志结构

1.1、物理日志

（0）物理日志即数据库的.ldf文件，当然后缀名是可以自定义的，默认是.ldf；

 

（1）一个SQL SERVER数据库，可以定义多个物理日志文件，SQL SERVER逻辑上把它们当成一个整体，顺序写入日志纪录，用完第一个再用下一个：即第一个日志文件的当前空间，如果没有可分配的VLF时，就会使用下一个日志文件的VLF，直到最后一个日志文件也没有可分配的VLF时，会重新回到第一个日志开始增长；VLF的使用如下图：

（2）物理日志文件初始大小至少为512KB；

 

（3）日志文件不可以放在文件组内；

 

1.2、虚拟日志

（0）日志文件除了文件头页外，其他VLF部分都不是以数据页的方式来存储的，物理日志以虚拟日志（VLF）为最小单位进行增长、收缩和使用，通常VLF大小至少为256KB，但第一个VLF的大小最小为256K-8K，因为第一个页面8K为日志文件头页面；

 

（1）虚拟日志是由SQL SERVER来维护的，大小不一，数量不定，不可以人工干预，但可以事先分配较大的物理日志，或者设置较大的物理日志增量，以减少虚拟日志的生成，从而减少数据库维护虚拟日志的成本、以及提高数据库启动及备份还原的速度；

 

   注意：如果设置日志文件的增量过小，则会产生过多的VLFS,也就是日志文件碎片，过多的日志文件碎片会拖累SQL Server性能.

    SQL Server创建数据库时，根据日志文件(ldf)的大小，生成VLF的数量公式如下:

   

ldf文件的大小	VLF的数量
1M到64M	4
64M到1GB	8
大于1GB	16

1.3、逻辑日志

（0）数据库逻辑操作的记录，每个事务可能会有多条日志纪录，每条日志记录由唯一的顺序增长的LSN来标记；通过DBCC LOG()来查看日志文件如下图：

（1）SQL SERVER数据库是不可能不记录日志的，它要用日志来保证事务的基本属性、及数据库恢复。同时也没有类似ORACLE的NOLOGGING开关（并非真正无日志），最相似的应该就是BULK_LOGGED恢复模式；

 

（2）前面说到过，SQL SERVER数据库遵循预写日志（WAL）的原则；

 

1.4、活动日志

（0）从MinLSN起往后的日志部分即为活动日志；如下图，以最早活动事务起点的LSN142作为MinLSN，从142起往后的日志部分为活动日志：

 

（1）检查点LSN、最早活动事务起点的LSN、尚未传递给分发数据库的最早的复制事务起点的 LSN，当中的最小值将作为MinLSN；

 

二. 日志管理

2.1、截断

（0）SQL SERVER可以通过截断日志以实现物理日志的回绕，截断操作仅是将被截断的日志部分标记为可重用，根据数据库恢复模式的设置：SIMPLE/BULK_LOGGED/FULL，在SIMPLE模式下，SQL SERVER会自动截断日志，类似于ORACLE中的非归档模式；

 

（1）SIMPLE模式下，CHECKPOINT会自动截断日志的非活动部分，FULL和BULK_LOGGED模式下，备份日志的TRUNCATE_ONLY/NO_LOG选项在2008的版本中已不再支持，只有通过日志备份来截断日志；

 

（2）SQL SERVER 截断日志后，并不会主动释放日志文件占用的磁盘空间，需要手动去收缩日志文件才会释放，但通常不建议这样做，毕竟当日志文件再次增大时又需要去重新申请磁盘空间；

 

（3）日志文件的截断以VLF为单位，从不活动的日志纪录所在的第一个VLF起，到MinLSN所在的VLF的前一个VLF，如下图：

（4）只可以截断非活动的日志部分；

 

（5）当运行一个长事务且一直未结束时，此时会影响MinLSN的推进，进而影响日志文件的截断，从而会出现，即便是在SIMPLE模式下，日志文件也会变得很大，甚至出现吃掉磁盘所有空间，出现事务日志已满的9002错误。

 

2.2、备份

（0）SQL SERVER没有ORACLE中的ARCH进程，无法像ORACLE一样自动归档日志，需要去手动备份，而且在有多个物理日志文件时，也无法对单个日志文件进行备份；

 

（1）当数据库故障恢复时，在线的日志需要手动通过NO_TRUNCATE选项去备份，即尾日志备份，然后再利用尾日志备份结合之前的备份进行故障恢复。

 

2.3、还原

还原在两种情况下发生，一是数据库重启时，以下简称重启恢复；一是手动通过备份集恢复时，以下简称介质恢复。

 

（0）还原的过程，是把数据和日志放在内存中，模拟用户读写操作以进行的。还原时只需要重做或撤消最后一个检查点之后的日志部分，这也是检查点机制提高恢复效率的原因所在；

 

（1）如果事务日志已结束（提交或回滚），而且数据页尚未被刷新，则重做（REDO）；如果事务日志未结束，但数据脏页已被刷新到磁盘，则回滚（UNDO）；

 

（2）日志记录中包含数据页被修改前及当前修改的两个LSN，如果目前数据页头的LSN等于修改前的LSN，则日志操作被重做，如果数据页头的LSN等于或大于当前修改的LSN，则跳过日志操作，不重做；

 

（3）重启恢复不需要人工干预，介质恢复需要手工干预，因为需要逐个应用日志备份，可以利用日志备份，将数据库恢复到某个具体的时间点/日志点。

 

这里描述的较为概念化，具体可以参考宋大侠的几篇文章（Careyson）

SQL日志

浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架

浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色

浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色

浅谈SQL Server中的事务日志(五)----日志在高可用和灾难恢复中的作用

SQL Server中In-Flight日志究竟是多少

再谈SQL Server中日志的的作用

 

本文转自：http://blog.51cto.com/qianzhang/1217394

参考：careySon的：浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架