SQL Server数据库事务日志存储序列
原文
原文:http://blog.csdn.net/tjvictor/article/details/5251351
如果你的数据库运行在完整或是批量日志恢复模式下,那么你就需要使用作业(job)来定期备份事务日志,保持你的事务文件大小处在一个可管理的范围。当你需要还原事务日志时,你就需要按照创建事务日志的顺序来恢复它们。你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序,使用FirstLSN和LastLSN列的值作参考。当你备份时,这些备份信息就会存在backupset表中
只要序列处于维护状态下,你就可以使用对应的日志把数据恢复到任意恢复点上。不幸的是,有些实例的序列已经被损坏了。下面两种情况普通是引起损坏的原因:
- 数据库的恢复模型被切换到了简单(SIMPLE)后,再次被切换回完整或是批量日志。
- Backup log命令运行时,附带了TRUNCATE_ONLY/NO_LOG选项。
当上面两种情况发生时,你需要即可做一个数据库的完整备份,作为事务日志恢复的新的恢复点。那么你如何判断序列已经被破坏了呢?
在SQL Server 2000中,这确实有点麻烦。假如数据库恢复模型已经被更改了,或是备份时日志已经被截断了,那么当更改后,你第一次备份事务日志时,SQL Server 2000会显示如下输出:
There is no current database backup. This log backup cannot be used to roll forward a preceding database backup.
Processed 1 pages for database 'logtest', file 'logtest_log' on file 1.
BACKUP LOG successfully processed 1 pages in 0.078 seconds (0.019 MB/sec).
注意这仅仅是个消息。虽然备份依然会成功完成,但却不可用。因为这是个计划作业,所以你什么都看不到,不过当事务日志被截断时,在Windows事件日志中是相关警告日志的。。
注意:如果你正在使用SQL Server 2000,那么日志事务对于数据库是非常重要的,所以要在Windows事件日志中不间断的监控日志事务事件。
假如你既没有关注警告消息,也没有监控Windows事件日志,那么基本上你就是有一批不可恢复的事务日志备份。SQL Server不应该警告我们吗?不应该停止无效的备份吗?假如你正在使用SQL Server 2005,那么答案肯定是应该的,而且它也是这么做的。下面就是当日志备份序列被毁坏时显示的消息:
Server: Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
是不是好多了。总之,如果你正在使用SQL Server 2000,你需要关注上面提到两个警告事件,这两个事件会毁坏你的日志备份序列,使你的备份失效。
下面是一些通用操作来保证日志序列不被破坏:
- 数据库恢复模型可以从完整到批量日志,反过来也一样
- 执行数据库完整备份,差异备份可是文件/文件组备份
假如你有如下一个备份序列(F代表完整数据备份,T代表事务日志)
F1,T1,T2,T3,T4,T5,T6
现在假设你要恢复到T6时间点,如下的恢复序列会帮你达到目的:
F1,T1,T2,T3,T4,T5,T6
F2,T3,T4,T5,T6
F3,T5,T6
本文翻译自sqlbackuprestore,更多精彩内容请浏览http://www.sqlbackuprestore.com