SQL Server事务日志介绍(转)
SQL Server中的数据库都是由一或多个数据文件以及一或多个事务日志文件组成的。
顾名思意，数据文件主要存储数据库的数据，包括数据库内容结构，数据页，索引页等等。那么事务日志到底是干什么的呢？它主要是用来保存数据库修改记录的，如下图：
![32139_1263994134Ou61[2]](http://hi.csdn.net/attachment/201001/20/32139_1263994134Ou61.png "32139_1263994134Ou61[2]")
SQL Server的工作原理为什么这样呢？为什么不把数据立刻写入数据文件呢？原因很简单：为了得到更高的效率和性能。数据文件为了适应新的数据可能会扩展，可能会重新分配页，分配新空间等等。而日志都是连续被记录的，所以记录事务日志要快得多。这也就是为什么我们通过推荐把物理磁盘单独划分一区用来存储事务日志的原因了，这样可以使磁盘在读写上最大程序的保持自然连续。数据文件的读写有很大的随机性。
那么事务日志到底都存些什么呢？看下面这个非常简单的例子：
![32139_1263994139zqPj[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994139zqPj%5B1%5D_2.png "32139_1263994139zqPj[1]")
在事务日志中，数据变化被记录在一个连续的日志记录中，且每一个记录都有一个编号，叫做日志序列编号(Log Sequence Number, LSN)。
![32139_1263994142HDa2[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994142HDa2%5B1%5D_2.png "32139_1263994142HDa2[1]")
在事务日志中，每一个日志记录都被存储在一个虚拟日志文件中。事务日志可以有任意多个虚拟日志文件，数量的多少取决于数据库引擎，而且每个虚拟日志文件的大小也不是固定的。
![32139_1263994150622g[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994150622g%5B1%5D_2.png "32139_1263994150622g[1]")
如上图所示，活动区间(active portion)的日志就是包含我们事务的区域。这区间就是完整恢复数据库所需要的。当更多的事务被创建时，活动区间的日志也会随着增长。
![32139_12639941583LNj[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_12639941583LNj%5B1%5D_2.png "32139_12639941583LNj[1]")
那么当CheckPoint被执行时，会发生什么变化呢？答案是：所有有变化的数据写到数据文件中，然后创建一个检查点记录(CheckPoint record)。
![32139_1263994164WVEp[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994164WVEp%5B1%5D_2.png "32139_1263994164WVEp[1]")
现在。由事务1，2，3所导致的变化将会被写到数据文件中。因为事务3没有被提交，所以活动区间日志的范围变成了从LSN50到LSN52之间。如果使用简单恢复模型的话，那么LSN45到LSN49之间区域可以被重用，因为那些记录已经不再需要了。
![32139_1263994191sD2g[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994191sD2g%5B1%5D_2.png "32139_1263994191sD2g[1]")
当SQL Server把虚拟日志文件1和2作为可重用区域时，事务日志也相应被截断(Truncate)。需要注意的是，物理日志大小也会随着变动。如果数据库运行在完整或是批量日志恢复模型下，那么从LSN45到49之间的区域将被删除(delete)，而且直到事务日志被备份后，这段区域的空间才会被重用。
那么当更新的事务被创建时，又会发生什么呢？在简单模式下，日志的起始空间将会被重用。
![32139_1263994197YUK7[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994197YUK7%5B1%5D_2.png "32139_1263994197YUK7[1]")
在完整或是批量日志恢复模型下，事务日志的空间则会被扩展。
![32139_1263994207cnTN[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994207cnTN%5B1%5D_2.png "32139_1263994207cnTN[1]")
假如事务日志是一个固定大小的日志，那么在SQL Server2000系统中，你会收到如下错误信息：
Server: Msg 9002, Level 17, State 6, Line 1
The log file for database 'AdventureWorks' is full. Back up the transaction log for the database to free up some log space.
在SQL Server 2005里面，错误会显示为：
Msg 9002, Level 17, State 4, Line 1
The transaction log for database 'AdventureWorks' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
注意：并不是说运行在简单恢复模式下的数据库永远都不会遇到9002的错误。如果你有一个很长的、正在运行的、未提交的事务，那么你的事务日志依然会被填满，因为SQL Server不能删除任何一个已经开始运行之后被创建的日志。也就是说，活动区间里面的日志从事务起始时被记录，并且已经没有活动区间可以被删除或是重用了。
所以，要保持你的事务日志基本处理一个可管理的范围：
- 当更改已经被确认或是由于错误导致的回滚已经完成时，要马上提交的你事务。
- 如果数据库运行在完整或是批量日志恢复模型下的话，要定期备份你的事务日志
为了找出数据库中最起始的活动事务，特别是事务起始时间时，就可以使用DBCC OPENTRAN命令，例如：
DBCC OPENTRAN
结果为：
Transaction information for database 'AdventureWorks'.
Oldest active transaction:
SPID (server process ID) : 52
UID (user ID) : 1
Name : user_transaction
LSN : (754:531:1)
Start time : Jul 14 2008 5:43:55:390PM
为了找出每一个数据库已经使用的日志空间大小，可以使用DBCC SQLPERF命令：
DBCC SQLPERF(LOGSPACE)
![32139_1263994207HoEg[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994207HoEg%5B1%5D_2.png "32139_1263994207HoEg[1]")
为了找出事务日志使用了多少虚拟日志数量，可以使用DBCC LOGINFO命令。它显示的细节内容就是你当前所连接数据库的内容，下面就是AdventureWorks数据库的输出：
![32139_1263994130am93[1]](http://p.blog.csdn.net/images/p_blog_csdn_net/tjvictor/547577/o_32139_1263994130am93%5B1%5D_2.jpg "32139_1263994130am93[1]")
从上图我们可以得到如下信息：你的事务日志中有四个虚拟日志文件（一行一个），且所有虚拟日志文件包括在一个单一的物理文件中(FileId=2)。第一，二，三的虚拟日志文件大小是458752比特，最后一个虚拟日志文件的大小是712704比特。1~3虚拟文件从来没有被使用或是重用过(Status=0), 第四个虚拟日志文件正在被使用(Status=2)。虚拟日志文件在物理上的布局具有连接的编号(FSeqNo是递增的), 实际情况可能与此有所不同。
