恢复数据变更模式之间的比较

　　理解恢复模式对于开发有效的备份策略是非常关键的。恢复模式决定了SQL Server如何管理事务日志。至于选择哪种模式则需要依赖于数据库指定的备份/还原计划。
　　在完整恢复模式下，事务日志将记录所有的数据变更。并且所有的数据库恢复选项是可用的，该模式实现了最高级别的数据保护，但使用的事务日志空间也最大。这种恢复模式可以与所有的数据库备份操作一起使用，能够实现某个时间点的恢复，并且能够备份事务日志。大多数的OLTP生产系统和需要最小化数据丢失的任务关键应用程序都应该采用这种恢复模式。
　　这种恢复模式不记录在特定数据库操作中发生的每一次变更，相反，会记录区域分配并标记变更的区域。因此，这些操作的执行速度更快，因为这些操作所需的日志变少了，但在恢复时可能存在数据丢失的风险。事务日志备份将复制事务日志中的所有内容，检查发生变化的区域并把这些区域从数据文件复制到日志备份中。此外，在执行大容量日志操作之后，就不允许使用事务日志备份来恢复到某个时间点。
　　如果在该模式下执行大容量操作，就有可能发生数据丢失，除非在大容量操作结束后进行一次日志备份。在这种场景中，通过在大容量数据库操作之间插入一些用于进行事务日志备份能行最小化。为了提高大容量操作的性能，DBA通常需要执行大容量日志操作，此时需要使用该回复模式，然后在大容量日志操作结束时再把数据库切换回完整恢复模式。此外，该模式通常用于OLAP或Reporting数据库，因为这些数据库每天晚上都需要处理大容量数据负载。处理完毕后就会创建数据库备份，接着在这一天之内就不会再修改数据。因此，如果因为故障而造成了数据丢失，那么还可以从备份中还原数据库。
　　与大容量日志恢复模式一样，简单恢复模式也实现了日志最小化，但它只把事务日志记录保留到检查点进程下一次执行时，检查点进程会把变更写入数据文件中，然后截断事务日志。由于无法进行事务日志备份，因此无法进行到某个时间点的恢复。
　　这种恢复模式通常在开发或测试服务器上，在这些服务器上丢失数据是可接受的，并且可以重新加载数据。此外，OLAP和Reporting数据库也可以使用该模式，由于在这些数据库上可能只存在夜间数据加载，因此可以执行完整或差异备份。当采用这种模式时，如果在数据加载过程中数据库发生了故障，就需要从头开始加载数据，除非在数据加载过程期间进行完整或差异备份。此外，如果DBA把数据库从其他恢复模式切换到该模式，就会破坏事务日志的连续性，因为它会截断事务日志。还有，在数据库处于该恢复模式期间，数据库更有可能发生数据丢失。