SQL Server 完整模式下的事务日志
1.在完整恢复模式下，日志作为恢复数据的重要组成部分，日志的管理和对日志空间使用的管理则需要重视
2.在完整恢复模式下，CheckPoint不会截断日志。只有对日志的备份才会将MinLSN向后推并截断日志
3.从日志恢复数据的原理是Redo,也就是将日志中记载的事务再重做一遍。这个开销和从完整或差异备份中恢复相比，要大很多。因此尽可能的减少利用日志的恢复量。
而使用完整或者差异备份来恢复更多的数据
SQL Server 大容量模式下的事务日志
1.微软推荐的最佳实践是在进行大量数据操作时(比如索引的创建和rebuilt,select into操作等)
暂时由完整恢复模式切换到大容量恢复模式来节省日志，这个转换并不会破坏日志链！
两种情况会破坏你的日志链
1.数据库的恢复模型被切换到了简单(SIMPLE)后，再次被切换回完整或是批量日志。
2.Backup log命令运行时，附带了TRUNCATE_ONLY/NO_LOG选项。
实例：
一个完整备份 DB.BAK
两个事务日志备份 DB1.TRN DB2.TRN
还原时，先还原完整备份DB.BAK，然后依次还原DB1.TRN DB2.TRN，具体的t-sql 操作 可以看我另外一篇文章（sqlserver 备份还原）
这里指的注意的是：如果在中途将完整模式切换成简单模式，又切换成完整模式~~那么你完蛋了，你无法恢复备份了！
尾部日志备份：
在DB_1处做了完整备份，并且接下来两次分别做了两次日志备份(Log_1和Log_2),在Log_2备份完不久服务器由于数据所在磁盘损坏。这时如果日志文件完好，则可以通过备份
尾部日志(Tail of log)后，从DB_1开始恢复，依次恢复Log_1,Log_2,尾部日志来将数据库恢复到灾难发生时的时间点。理论上可以使数据的损失为0。
如理利用尾部日志恢复数据库呢？你可以看我的这篇文章
参考文献：
http://www.cnblogs.com/CareySon/archive/2012/02/13/2349751.html