3. SQLServer存储引擎之日志篇
（3.1）日志结构
（3.1.1）物理日志
（0）物理日志即数据库的.ldf文件, 当然后缀名是可以自定义的，默认是.ldf
（1）一个SqlServer数据库，可以定义多个物理日志文件，SQL Server逻辑上把他们当作一个整体，顺序写入日志记录，用完第一个，再用下一个：即第一个日志文件的当前空间，如果没有可分配的VLF时，就会使用下一个日志文件的VLF，直到最后一个日志文件也没有可分配的VLF时，会重新回到第一个日志开始增长；VLF的使用如下图：
SQLServer把事务日志文件划分为多个VLF（Virtual Log File）,即虚拟日志文件。
（2）物理日志文件初始大小至少为512KB
（3）日志文件不可以放在文件组内
（3.1.2）虚拟日志
（0）日志文件除了文件头页外，其他VLF部分都不是以数据页的方式来存储的，物理日志以虚拟日志（VLF）为最小单位进行增长、收缩和使用，通常VLF大小为256KB，但第一个VLF的大小最小为8K，因为第一个页面8K为日志文件头页面。
（1）虚拟日志是由SQLServer来维护的，大小不一，数量不定，不可以人工干预，但可以事先分配较大的物理日志，或者设置较大的物理日志的增量，以减少虚拟日志的生成，从而减少数据库维护虚拟日志的成本，以及提高数据库启动，备份还原的速度。
（3.1.3）逻辑日志
（0）数据库逻辑操作的记录，每个事务可能会有多条日志记录，每条日志记录由唯一的顺序增长的LSN来标记，通过DBCC LOG()来查看日志文件如下图：
（1）SQL Server用日志记录来保证事务的基本属性，及数据库恢复。
（2）SQLServer数据库遵循预写日志（WAL）的原则。
（3.1.4）活动日志
（0）从MinLSN起往后的日志部分即为活动日志。如下图，以最早活动事务起点LSN142作为MinLSN，从142往后的日志部分为活动日志：
（1）检查点LSN、最早活动事务起点LSN、尚未传递给分发数据库的最早的复制事务起点的LSN，当中的最小值将作为MinLSN;
(3.2)日志管理
（3.2.1）截断
（0）SQL SERVER可以通过截断日志以实现物理日志的回绕，截断操作仅是将被截断的日志部分标记为可重用，根据数据库恢复模式的设置：SIMPLE/BULK_LOGGED/FULL,在SIMPLE模式下，SQL SERVER会自动截断日志，类似于ORACLE的非归档模式。
（1）SIMPLE模式下，CHECKPOINT会自动截断日志的非活动部分，FULL和BULK_LOGGED模式下，只有通过日志备份来截断日志。
（2）SQL SERVER截断日志后，并不会主动释放日志文件占用的磁盘空间，需要手动去收缩日志文件才会释放，但通常不建议这样做，毕竟当日志文件再次增长时又需要去重新申请磁盘空间。
（3）日志文件的截断以VLF为单位，从不活动的日志记录所在的第一个VLF起，到MinLSN所在的VLF的前一个VLF，如下图：
（4）只可以截断非活动日志部分。
（5）当运行一个长事务且一直未结束时，此时会影响MinLSN的推进，进而影响日志文件的截断，从而会出现，即便是SIMPLE模式下，日志文件也会变得很大，甚至出现吃掉磁盘所有空间，出现事务日志已满的9002错误。
（3.2.2）备份
（0）SQL SERVER没有ORACLE中的ARCH进程，无法像ORACLE一样自动归档日志，需要手动去备份，而且在有多个物理日志文件时，也无法对单个日志文件进行备份。
（1）当数据库故障恢复时，在线的日志需要手动通过NO_TRUNCATE选项去备份，即尾日志备份，然后再利用尾日志备份结合之前的备份进行故障恢复。
（3.2.3）还原
还原在两种情况下发生，一是数据库重启时；一是手动通过备份集恢复时；
（0）还原的过程，是把数据和日志放在内存中，模拟用户读写操作以进行的。还原时只需要重做或撤销最后一个检查点之后的日志部分，这也是检查点机制提高恢复效率的原因所在。
（1）REDO和UNDO：
还原时如果事务日志已结束（提交或回滚），而且数据页尚未被刷新，则重做（REDO）；
如果事务日志未结束，但数据脏页已被刷新到磁盘，则回滚（UNDO）。
（2）日志记录中包含数据页被修改前及当次修改的两个LSN，如果目前数据页头的LSN等于修改前的LSN，则日志操作被重做；如果数据页头的LSN等于或大于当次修改的LSN，则跳过日志操作，不重做。
（3）数据库重启不需要人工干预，通过备份集恢复需要人工干预。因为有时需要恢复到某个操作点，并不是完全恢复所有日志记录。
