1，Simple Recovery 模式
Simple Recovery(简单恢复)模式是最容易实现的恢复模式，这种恢复模式本质上与在 SQL Server 7.0 中选择 trunc.log on checkpoint 选项相同。Simple Recovery 模式定期截断事务日志，删除已经被提交的所有事务。因为日志经常被截断，所以不能备份。这就使得备份策略只能采用完全备份和差异备份。如果数据库已经配置为 Simple Recovery 模式，那么在试图执行事务日志备份时将接收到错误：
这种模式极其适合只在夜晚执行备份的那些数据库，或者白天通过差异备份完成备份的那些数据库。通常这种模式可以满足大多数开发数据库。然而使用这个选项意味着不能实现精确到时间点的恢复，而产品可能要求这种恢复。由于事务日志被截断和重用，因此应释放事务日志所占用的空间和管理这些备份的维护开销。
说明：
SQL Server Personal Edition 和 SQL Server Desktop Engine的缺省恢复模式是这种模式。
2， Full Recovery 模式
Full Recovery(完全恢复)模式将丢失数据的可能降至最低，但是增加管理开销和空间开销。在这种模式中，SQL Server 记录所有的操作，其中包括通过类似 bcp 和 BULK INSERT 的批操作写行。若采用 Full Recovery 模式，只要执行正常的事务日志备份就可以恢复到任何时间点。应切记，在快速 OLTP 环境中如果选择该选项，则事务日志和日志备份将快速增长。
说明：
Full Recovery模式是SQL Server Standard Edition和SQL Server Enterprise Edit的缺省恢复模式。
说明：
Full Recovery模式同时记录所有的CREATE INDEX命令。SQL Server 7.0仅记录索引被创建的事实，而不记录实际的索引。在SQL Server 2000中，记录实际索引，这意味着通过事务日志备份恢复数据库之后不必重建索引。
3， Bulk Recovery 模式
Bulk-Logged Recovery 模式被设计为 Full Recovery 模式的折衷。与 Full Recovery模式相比，这种模式提供较好的性能和空间的利用率。这是因为当启用此恢复模式的数据库出现批操作时，SQL Server 仅仅记录该批操作发生的事实及其发生的范围。由于批操作的记录不完全，因此事务日志将比 Full Recovery 模式的事务日志小很多。 因为记录发生批操作的范围，所以如果定期执行事务日志备份，则可以将数据库恢复到给定时间点。折衷的方案是在备份事务日志时，除事务日志以外还必须备份数据改变的范围。这意味着事务日志备份将变得很大，并且花费的时间更长。
说明：
在 Bulk-Logged Recovery 模式事务日志的恢复与 Full 模式一致。在这种模式中恢复事务日志时，无须重新执行搜寻改变范围的过程。
4， 恢复选项
如果需要恢复设置为 Simple Recovery 模式的数据库，只需恢复数据库最近一次的全备份。如果需要恢复一设置为 Full 或 Bulk 模式的数据库，则不但需要恢复数据库最近一次的全备份，还要运用最后一次的差异备份以及最终的事务日志备份。使用最终的事务日志备份可以指定一个精确的时间点恢复。
提示：
如果关心数据库是否能恢复到指定时间点，则开发数据库采用 Full 或 Bulk-Logged Recovery 模式。在极少数非这种情形的实例中，可以使用完全备份。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。