事务日志备份
事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录。可以使用事务日志备份将数据库恢复到特定的即时点(如输入多余数据前的那一点)或恢复到故障点。
还原事务日志备份时,Microsoft® SQL Server™ 前滚事务日志中记录的所有更改。当 SQL Server 到达事务日志的最后时,已重新创建了与开始执行备份操作的那一刻完全相同的数据库状态。如果数据库已经恢复,则 SQL Server 将回滚备份操作开始时尚未完成的所有事务。
一般情况下,事务日志备份比数据库备份使用的资源少。因此可以比数据库备份更经常地创建事务日志备份。经常备份将减少丢失数据的危险。
说明 事务日志备份有时比数据库备份大。例如,数据库的事务率很高,从而导致事务日志迅速增大。在这种情况下,应更经常地创建事务日志备份。
事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。有关更多信息,请参见使用恢复模型。
将事务日志备份与数据库备份一起使用
只有具有自上次数据库备份或差异数据库备份后的连续事务日志备份序列时,使用数据库备份和事务日志备份还原数据库才有效。 如果日志备份丢失或损坏,必须创建数据库备份或差异数据库备份并再次开始备份事务日志。如果打算将数据库还原到这些备份内的某个即时点,应保留以前的事务日志备份。
只有当启动事务日志备份序列时,数据库或差异数据库备份才必须与事务日志备份同步。每个事务日志备份序列都必须由数据库或差异数据库备份启动。
通常情况下,只有当第一次备份数据库或发生从简单恢复模型到大容量日志记录恢复模型的改变时才开始新的备份序列。有关更多信息,请参见切换恢复模型。
截断事务日志
SQL Server 在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务,因此在恢复过程中不再使用。相反,事务日志的活动部分包含仍在运行但尚未完成的事务。SQL Server 将重新使用事务日志中这些截断的非活动空间,而不是任由事务日志继续增大并占用更多的空间。
说明 虽然可以手工截断事务日志,但强烈建议最好不要这样做,因为这将断开日志备份链。在创建完整数据库备份前,将无法为数据库提供媒体故障保护。只有在非常特殊的环境中才使用手工日志截断,而且尽可能快地创建完整数据库备份。
事务日志非活动部分的终点(因此就是截断点)是下列事件的最早点:
- 最近的检查点。
- 最早的活动事务的起点,即尚未提交或回滚的事务。
这代表在恢复过程中,SQL Server 必须回滚事务的最早点。
- 最早事务的起点,这些事务包括已发布但尚未复制更改的复制对象。
这代表 SQL Server 仍必须复制的最早点。
备份事务日志的条件
完整数据库备份或差异数据库备份执行期间不能备份事务日志。不过,在运行文件备份的同时可以备份事务日志。
下列情况不要备份事务日志:
- 在由于事务日志包含自上次创建备份后数据库所发生的更改,而创建了数据库或文件备份之前。有关更多信息,请参见使用文件备份。
事务日志已被显式截断。此时如果要备份事务日志,必须在事务日志截断发生后先创建数据库或差异数据库备份。
还原事务日志备份
必须满足以下条件才能应用事务日志备份:
- 先还原事务日志备份之前的数据库备份或差异数据库备份。
- 先应用在备份数据库或差异数据库之前创建的所有事务日志。
如果以前的事务日志备份丢失或损坏,最多只能将事务日志还原到丢失的事务日志之前的最后一次备份。
- 已经恢复了数据库,也已经前滚或回滚了所有未完成的事务。
应用事务日志备份时,必须等应用了最后的事务日志后才能恢复数据库。如果允许在应用其中一个中间事务日志备份时进行恢复,则必须从数据库备份开始重新开始整个还原操作,才能还原过那一点。
创建事务日志备份序列
为创建备份集,通常应定期生成数据库备份(如每天),并以更短的间隔生成事务日志备份(如每隔 10 分钟)。必须至少有一个数据库备份或覆盖的文件备份集,才能有效地进行日志备份。备份之间的间隔因数据的关键性和服务器的工作负荷而异。如果事务日志损坏,则将丢失自最新的日志备份后所执行的工作。为此,建议经常对关键数据进行日志备份,并注意将日志文件放在容错存储上。
事务日志备份序列独立于数据库备份。可以生成一个事务日志备份序列,然后定期生成用于开始还原操作的数据库备份。例如,假设有下列事件序列。
时间 事件
上午 8:00 备份数据库
中午 备份事务日志
晚上 04:00:00 备份事务日志
下午 6:00 备份数据库
晚上 08:00:00 备份事务日志
晚上 10:00 出现故障
晚上 8:00 创建的事务日志备份包含从下午 4:00 到晚上 8:00 的事务日志记录,中间跨越下午 6:00 创建数据库备份的时间。事务日志备份序列从上午 8:00 创建的初始数据库备份到晚上 8:00 创建的最后一次事务日志备份是连续的。可以使用下列过程将数据库还原到晚上 10:00 的状态(故障点):
使用最后一次创建的数据库备份还原数据库。
- 创建当前活动事务日志的备份。
- 还原下午 6:00 的数据库备份,然后应用晚上 8:00 的数据库备份和活动事务日志备份。
还原进程检测到晚上 8:00 的事务日志备份包含自上次还原备份后所发生的事务。因此,还原操作向下扫描事务日志直至下午 6:00 完成数据库备份时对应的即时点,并且只前滚事务日志备份内自该点后所完成的事务。对晚上 10:00 的事务日志备份再执行一次上述操作。
使用以前的数据库备份(早于最后一次创建的数据库备份)还原数据库。
- 创建当前活动事务日志的备份。
- 还原上午 8:00 的数据库备份,然后按顺序还原全部四个事务日志备份。不要还原下午 6:00 的数据库备份。所有完成的事务都将前滚到晚上 10:00。
这个进程所用的时间比还原下午 6:00 的数据库备份要长。
第二种还原数据库的方法注重由事务日志备份链所提供的冗余安全性,使用这个事务日志备份链,即使数据库备丢失份,也可以还原数据库。可以还原以前的数据库备份,然后还原创建该数据库备份后所创建的所有事务日志备份。
说明 不丢失事务日志备份很重要。可考虑生成日志备份集的多个复本。为此,可以将日志备份到磁盘,然后将磁盘文件复制到其它设备,如单独的磁盘或磁带。
恢复和事务日志
当完成还原操作并恢复数据库时,所有未完成的事务将回滚。这对还原数据库的完整性是必需的。
完成该操作后,不能再将其它事务日志备份应用到数据库。例如,一系列事务日志备份包含一个运行时间长的事务。该事务的起点记录在第一个事务日志备份中,终点记录在第二个事务日志备份中。第一个事务日志备份中没有任何关于提交或回滚操作的记录。因此,如果恢复操作在应用第一个事务日志备份时运行,则此运行时间长的事务被视为未完成。记录在事务的第一个事务日志备份中的数据修改将回滚。SQL Server 不允许在运行恢复操作后应用第二个事务日志备份。
因此,还原事务日志备份时,必须等到应用了最后的事务日志后才能恢复数据库。这可以防止部分回滚事务。只有在最后的还原操作结束时才需要回滚未完成的事务。