这些是我目前的设置：
恢复模式：简单日志文件初始大小：10 mb日志文件自动增长：无数据库自动缩小：关
日志文件自动增长设置为无，因为我不希望日志文件增长。 我的目标是保持日志文件一直很小，因为我不需要它来恢复目的。
这两个设置好吗？
另外，如果我有一个涉及大量插入和删除的大事务（超过10MB的更改）会发生什么情况。 由于日志文件空间不足，操作是否会完成？
在成功的恢复模式中。 每次提交没有打开的事务时，日志内容都会被丢弃。 这种情况经常发生。
如果日志重载，db不能提交。 更改将被回滚。 请注意，在简单的模型，这将是稀有的，但它可能在理论上是可能的。 不过，我会称之为理论上的。
同时，您不能使用日志备份来进行时间点恢复。
只是为了清除事情：
在简单恢复模式中，日志文件截断与提交没有直接关系。 日志文件被截断使得虚拟日志文件仅在发生检查点时才可用于其他事务。 检查点的执行频率与SQL认为有必要将脏页写入磁盘时相同。 同样在检查点，日志文件的不活动部分 （未被任何事务使用）被截断，使得事务日志可以重新用于其他事务。 日志截断后，日志文件可以缩小，以便在需要时减小物理大小。
因此，如果在提交之后没有在事务中明确指定它，则提交不会生成检查点。 另一方面，如果日志包含关于未提交事务的信息，则实际上会生成日志截断的检查点不会产生任何影响。
回答你的问题：
这里更多关于日志文件pipe理： http ： //technet.microsoft.com/en-us/library/ms189085.aspx
是的，如果由于较大的事务而导致日志填满，并且日志文件设置为NO autogrow，则事务将失败并回滚。
这可能不像你想象的那么难得。 索引重build是使用大量日志空间的常见维护活动。
你没有提到你的数据文件的大小，或者数据库处理的活动types，所以我无法知道10MB是否足够大。
我永远不会留下autogrow禁用的日志文件。 这只是要求麻烦。 当然，你希望在成长的时候得到通知，而且你可以制造一个这样的显示器。 你只是不想在半夜的页面，因为一些用户跑了一个大报告什么的。
如果这是您的生产数据库，那么拥有简单恢复模型并不是一个好主意。 自动增长应该帮助你，除非你的磁盘空间不足。