阅读目录(Content)

• 1 基本介绍
• 2 对数据库启动的影响
• 3 日志文件添加方式
• 4 物理结构
• 5 延迟日志截断原因
• 6 管理事务日志

 

---

---

    本系列上一篇博文链接：SQL SERVER大话存储结构（4）_复合索引与包含索引

---

---

回到顶部(go to top)

1 基本介绍

    每个数据库都具有事务日志，用于记录所有事物以及每个事物对数据库所作的操作。

    日志的记录形式需要根据数据库的恢复模式来确定，数据库恢复模式有三种：

• 完整模式，完全记录事物日志，需要定期进行日志备份。
• 大容量日志模式，适用于批量操作的数据库，可以以更压缩的方式处理日志，需要定期进行日志备份。
• 简单模式，也有日志文件，只是该模式下可以通过checkpoint自动重用virtual log file，所以日志文件会处于一直重复使用的过程，保持一定大小，但是，如果有一个事务启动，很久没有commit，那么从这个事务开始到最后commit的时间段内的事务日志存储空间都无法checpoint自动重用，这时，你很可能看到一个很大的日志文件；注意，简单模式下是无法进行日志备份。

    数据库里边，任何对数据库的读写都是在内存页中找到对应的数据也，再做修改，如果内存页中不存在数据页，则从磁盘加载如内存中。当一个修改操作发生时，修改的将是内存页中对应的数据页面，同时也会实时记录到日后文件ldf中。那么，什么时候数据会被同步到mdf文件呢，只有以下三种情况：

• 做checkpoint时，后续会专门整理checkpoint的相应文章；
• Lazy write运行时，即内存出现压力，需要把内存中的数据页写入到磁盘，腾出内存空间；
• eager write时，即发生bulk insert和select into操作时。

    DB中的事务日志记录，可以给我们带来很多好处，它可以支持以下操作：

• 恢复个别的事务。
• 在 SQL Server 启动时恢复所有未完成的事务。
• 将还原的数据库、文件、文件组或页前滚至故障点。
• 支持事务复制。
• 支持高可用性和灾难恢复解决方案：AlwaysOn 可用性组、数据库镜像和日志传送。

回到顶部(go to top)

2 对数据库启动的影响

    当数据库重启或者还原到最后的时候，数据库都会进入 recovery状态，正常情况下，这个状态持续时间在几十秒间，但是特殊情况下，它会花费非常长的时间，甚至几个小时，如果这个步骤失败，数据库则进入到挂起 suspect状态，无法正常提供使用。     那么，当数据库进入 recovery 的时候，它在操作些什么呢？     SQL SERVER日志会记录所有修改记录（数据的修改情况，不包含SQL语句），包括Begin Transaction和Commit / Rollback Transaction 操作。由于对事务日志的修改，要比数据文件的修改要快，所有会出现，数据修改更新到了日志文件，但是还没有落盘到数据文件，那么这个时候数据库就处于recovery状态，同时对事务日志最近的一个checkpoint点以后的所有数据修改记录做以下检查：     所有检查结束后，则会对数据库做一个checkpoint的表示，并写入事务日志中，表明日志文件跟数据文件已经同步结束，完成了recovery过程，数据库可正常提供使用。这里需要注意一点，如果你数据库最近一次checkpoint到现在的修改操作足够多，那么将会耗费相对较长时间来检查，同时也能够在 error log中看到百分比标识的recovery完成进展，避免漫无目的的等待。 Error Log的检查，可以通过图形界面（见下图）查看当前日志，也可以运行xp_readerrorlog 查询。

 1 /*
 2 xp_readerrorlog参数说明
 3 1. 存档编号
 4 2. 日志类型(1为SQL Server日志,2为SQL Agent日志)
 5 3. 查询包含的字符串
 6 4. 查询包含的字符串
 7 5. LogDate开始时间
 8 6. LogDate结束时间
 9 7. 结果排序,按LogDate排序(可以为降序"Desc" Or 升序"Asc")，默认升序
10 */
11  
12 Exec xp_readerrorlog 0,1,Null,Null,‘2017-02-16 10:53:32.300‘,‘2017-02-16 12:53:32.300‘

 

     假设出现这种情况，由于上线的重要程度远远重要过 数据丢失的情况，并且你跟所有部门沟通确认 可以承担 data file跟log file之间的差异数据的丢失，那么你可以按以下步骤操作，严重建议不要这么操作，因为会带来不可预估的数据丢失情况，如果你命悬一线，真打算放弃这部分数据，那么，可以按照以下操作：

 1 #设置数据库单用户
 2 alter database backupdb set single_user with rollback immediate
 3 
 4 #设置数据库紧急状态
 5 alter database backupdb set emergency with rollback immediate
 6 
 7 #获取事务日志的物理名和逻辑名后，重建日志文件
 8 select name,physical_name from sys.master_fiels where database_id=db_id(‘backupdb‘)
 9 alter database backupdb rebuild log on (name=‘事务日志的逻辑名‘,filename=‘事务日志的物理名词‘)
10 
11 #设置数据库online
12 alter database backupdb set online with rollback immediate
13 
14 #设置数据库为多用户
15 alter database backupdb set multi_user with rollback immediate

回到顶部(go to top)

3 日志文件添加方式

    日志记录在 后缀名为 ldf的文件，允许有多个日志文件，但是不会并发分开记录日志，而是使用填充满一个日志文件后，再转向一个日志文件，线性操作日志文件。     可以通过下方来添加 ldf文件，需要注意几个地方：

• 初始大小，建议直接设置为 截断日志的期间内最大值，比如，某DB 恢复模式是完整模式，每隔半个小时做一次事务日志备份且截断日志，那么设置 日志文件大小的时候，取业务高峰期 每半小时的日志增长 最大值是5G，则可设置初始大小为 5G-7G之间；
• 增长大小，无论是 按比例增长还是按照MB增长，都不要设置过小，建议每次增长在100Mb左右，减少使用到自动增长，在最初设置的初始大小就满足其增长需求 ，如果开始设置的 初始大小 偏小，不满足，可以挑一个业务低峰期，修改变大初始大小。每一次文件自动增长期间，都会对写入的日志造成堵塞，虽然时间很短，但是如果增长频繁，则会影响数据库操作；
• 自动增长，建议设置为自动增长，但是前提定期监控日志的增长情况，避免磁盘空间不足，同时，如果恢复模式是 完整模式或者大容量模式，还需定期做日志备份截断日志，避免 事务日志已满的9002错误；
• 路径选择，建议与 mdf 文件放在不同的磁盘上，分散IO，若是磁盘读写瓶颈不大，则可放在一个磁盘上；

添加方式有2种，如下：

 1 USE [master]
 2 GO
 3 ALTER DATABASE [backupdb]
 4 ADD LOG FILE (
 5                NAME = N‘backupdb_log_1‘,
 6                FILENAME = N‘D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\backupdb_log_1.ldf‘ ,
 7                         SIZE = 524288KB ,
 8                         MAXSIZE = 1048576KB ,
 9                         FILEGROWTH = 10240KB
10                       )
11 GO

回到顶部(go to top)

4 物理结构

     数据库的事务日志映射在一个或者多个的物理文件上，从概念上讲，日志文件是一系列的日志记录；从物理上讲，日志记录序列被有效的存储在实现事务日志的物理文件中。     SQL Server 数据库引擎在内部将每一物理日志文件分成多个虚拟日志文件，即VLF（Virtual Log File），虚拟日志文件没有固定大小，且物理日志文件所包含的虚拟日志文件数不固定。数据库引擎在创建或扩展日志文件时动态选择虚拟日志文件的大小。数据库引擎尝试维护少量的虚拟文件。在扩展日志文件后，虚拟文件的大小是现有日志大小和新文件增量大小之和。     只有当日志文件使用较小的 size 和 growth_increment 值定义时，虚拟日志文件才会影响系统性能。如果这些日志文件由于许多微小增量而增长到很大，则它们将具有很多虚拟日志文件。这会降低数据库启动以及日志备份和还原操作的速度。建议您为日志文件分配一个接近于最终所需大小的size值，并且还要分配一个相对较大的 growth_increment 值。     管理员不能配置或设置虚拟日志文件的大小或数量，但是在VLF影响系统性能的情况下，可以尝试缩小，通过收缩日志文件的方式。 dbcc loginfo(dbname) 返回的行数，即为 VLF 文件个数，当status为0时，即该文件没有被使用，还能写入LOG，2表示已被使用，并且无法重用，这个时候，可以通过 backup Log 的形式，备份并截断LOG文件，则可以回收 从最后一个0到最近一个2行的空间。 收缩日志文件或者减少VLF文件的方式如下，需要先备份日志文件，才可以有效进行收缩，在没有备份日志文件的情况下，进行收缩，效果不大。详见以下代码：  

 1 #其行数及为VLF个数，status为0表示文件未用，为2表示已被使用，无法重用
 2 dbcc loginfo 
 3 
 4 #备份日志
 5 BACKUP LOG [backupdb]
 6 TO  DISK = N‘D:\data\20170215_backupdb_log.trn‘ WITH NOFORMAT, NOINIT,  NAME = N‘backupdb-事务日志  备份‘, SKIP, NOREWIND, NOUNLOAD,  STATS = 10
 7 GO
 8 
 9 #收缩日志文件，根据日志文件名来收缩500Mb，建议收缩大小是合理大小，参考上文的 初始大小 判断
10 USE [backupdb]
11 GO
12 SELECT name FROM sys.database_files WHERE type_desc=‘log‘
13 DBCC SHRINKFILE (N‘jiankong_db_log‘ , 500)
14 GO
15 
16 #其行数及为VLF个数，VLF文件减少
17 dbcc loginfo

    事务日志是一种回绕的文件。假设，数据库backupdb只有一个ldf文件，且刚好分成了5个虚拟日志，当我们开始使用数据库的时候，逻辑日志从物理日志的最开始端向末端记录，如下图。

• < 上一篇

  SQL server 2008 安装问题解决 转

• 下一篇 >

  sql执行顺序