事务日志备份有以下3种类型
(1)纯日志备份:仅包含相隔一段时间的事务日志记录,而不包含任何大容量更改
(2)大容量操作日志备份.包括由大容量操作更改的日志和数据页,不支持时间点恢复
(3)尾日志备份:从可能已破坏的数据库创建,用于捕获尚未备份的日志记录。在失败后创建尾日志备份可以防止工作损失，
并且，尾日志备份可以包含纯日志或大容量日志数据
必须至少有一个完整备份或一个等效文件备份集，才能进行任何日志备份。通常DBA定期（如每周）创建数据库完整备份，
以更短的间隔（如每天）创建差异备份，并会频繁（如每10分钟）创建事务日志备份。
最恰当的备份间隔取决于一系列因素，如数据的重要性、数据库的大小和服务器的工作负荷
如果事务日志损坏，则将丢失自最新的日志备份后所执行的工作。
为此，建议经常对关键数据进行日志备份，并注意将日志文件存储在容错存储设备中
事务日志备份顺序独立于完整备份。可以生成一个事务日志备份顺序，然后定期生成用于开始还原操作的完整备份
------------------------------------------------华丽的分割线-----------------------------------------------------
最佳实践
每15~30分钟：事务日志备份
每天：差异备份
每周：完整备份
备份日志尾部失败后执行尾日志备份，以防止丢失所做工作，在失败之后并且在开始还原数据库之前，或者在故障转移到辅助数据库时，
备份活动日志（尾日志备份）。选择此选项等效于在TSQL 中backup log 语句中指定norecovery选项
1 BACKUP LOG [GPOSDB] To disk='D:\GPOSDB_logbackup_201207160152.bak'
2 GO事务日志备份有时会比数据库备份大。例如，数据库的事务处理很多，从而导致事务日志迅速增大。
在这种情况下，应该经常地创建日志备份并清理事务日志
----------------------------------------------华丽的分割线----------------------------------------------------------------
清理事务日志
如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。
为了减少逻辑日志的大小，应定期截断事务日志。在SQLSERVER的最早版本中，截断事务日志意味着将进行数据库恢复或还原不再需要的日志记录物理删除。
但是，在最近的版本中，截断过程只是做标记，以便重新使用旧日志记录使用过的空间。此空间中的日志记录将最终被新的日志记录覆盖。
在事务日志已满的情况下，满的情况根据你的磁盘的容量大小，用户不能更新数据。backup log语句有双重的目的，
不仅可以备份事务日志，并且在事务日志满的时候，用户还可以利用他清理事务日志，移去事务日志中不活动的部分
截断并不减少物理日志文件大小，而是减少逻辑日志文件的大小并释放磁盘空间以供重新使用。
减少物理日志文件大小需要收缩事务日志文件
DBCC SHRINKFILE适用于当前数据库中的文件。要收缩的数据库不必在单用户模式下，收缩文件时，其他用户也可使用该数据库
1 --例如：截断AdventureWorks数据库的事务日志，然后将日志文件收缩到10MB
2 USE [AdventureWorks]
3 GO
4 BACKUP LOG [AdventureWorks] WITH no_log
5 GO
6 EXEC [sys].[sp_helpdb] @dbname = 'AdventureWorks' -- sysname
7 GO
8
9 DBCC SHRINKFILE(AdventureWorks_Log,10)
10 GO注意:清理事务日志的时候,不产生日志备份副本.考虑到数据库的恢复工作可能需要使用日志备份,应该先做日志备份,再清理事务日志！！
最后附上配图
