SQL Server 恢复和批量恢复模式混淆
我对 SQL Server 恢复和批量恢复模式有两个困惑。
恢复过程本身是否会生成事务日志（这里我的意思是恢复过程生成的日志——如果有的话，而不是正常数据库DML/DDL操作生成的日志）？ 为什么？
- 下，对A或B的理解是否正确（如果都不正确，请帮忙指正，这是我的两种不同的理解，导致我很困惑）
A.对产品数据库的正常DML/DLL批量操作（不是恢复操作 ） ）将生成最少量的日志，由于日志很少，利用日志的恢复过程无法恢复批量操作中间的任何点； B、对产品数据库正常的DML/DLL批量操作仍会产生正常的大量日志（与非批量日志恢复模式相同），但恢复过程会将事务日志中的批量操作作为一个单元进行恢复，从而产生恢复过程本身的最小日志；
问候， 乔治
I have 2 confusions about SQL Server recovery and bulk recovery mode.
whether recovery process itself will generate transaction log (here what I mean the logs are the logs generated by recovery process -- if any, and not generated by normal database DML/DDL operations)? Why?
in the bulk recovery mode, whether the understanding of A or B is correct (if neither is corect, please help to correct me, here are my 2 different understandings which causes me confused)
A. the normal DML/DLL bulk operation on product database (not the recovery operation) will generate minimal amount of logs, since logs are minimal, the recovery process which utilizes log, can not recover any point in the middle of bulk operations;
B. the normal DML/DLL bulk operation on product database will still generate normal large amount of logs (the same as non-bulk log recovery mode), but recovery process will treat bulk operation in transaction log as a unit to recover, which generates minimal logs for recovery process itself;
regards,
George
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请阅读以下两篇文章：
http://technet.microsoft.com /en-us/magazine/2009.02.logging.aspx
http://www.simple-talk.com/sql/backup-and-recovery/simple-talk-sql-server-backup-crib-sheet/
恢复过程不会创建日志。 日志是执行时间点恢复过程所需的内容（以及完整数据库备份，可能还有差异备份）。
Please read the following two articles:
http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
http://www.simple-talk.com/sql/backup-and-recovery/simple-talk-sql-server-backup-crib-sheet/
A Recovery Process does NOT create Logs. Logs are what are required in order to perform a point in time recovery process (along with a full database backup, and possibly differential backups).