SQL Server了解使用的事务日志空间

Question

我是新手SQL服务器用户，并且老板要求我记录事务日志增长。我正在测试我的生产服务器的虚拟数据库上的事务日志行为，并且不了解某些事情。 生产服务器将只在数据库上进行批量插入（每天大约250 - 400个批量插入）。测试的方法是

1. 每个文件的单独批量插入。每个文件的开始/提交/回滚事务。
2. 单个批量插入下的所有文件。所有文件的单一开始/提交/回滚事务。（我不想做但我的老板希望这样做：D）

数据库处于批量日志模式，因为所有插入都是批量处理的。 日志文件最初设置为3 GB，在第一个方案中，日志文件大小保持不变，只是使用的日志空间增加。

DBCC SQLPERF(Logspace)

在执行批量插入的第二种情况下，日志文件大小增加到27 GB，但使用的空间保持最小0.5％。 我不了解日志大小的突然增加，而使用的空间仍然很小。 Begin / Commit / Rollback事务对事务日志有影响吗？ 数据只在当天插入一次，那么将生产数据库保持在简单恢复模式真的很愚蠢吗？

Answer 1

  

Begin / Commit / Rollback事务是否对事务日志有影响？

自最早的活动事务以来，所有日志数据都必须保持活动状态。现在为什么只使用日志中0.5％的空间？ SQL Server为活动事务保留日志空间以支持回滚操作。回滚使用日志空间。 SQL Server在保留空间时是保守的。 27GB可能是估计在最坏的情况下需要多少日志才能回滚你所做的所有批量插入。

您可能在这里获得了最少量的批量插入。这些导致最小的日志写入。但是，当您备份日志时会出现意外情况：所有批量更改的页面都会被复制到备份中，以便日志实际上能够前滚您所写的内容。

您可以使用简单的日志记录模型吗？这可能会使这些担忧消失。简单的日志模型本身不会导致数据安全问题。这只意味着您不能再进行日志备份（这可能意味着在服务器爆炸的情况下尚未备份数据的风险更高）。

您是应该使用单个事务还是使用多个较小的事务取决于：

1. 你需要原子性保证吗？请注意，大量插件的回滚可能非常慢。我从来没有测试过。一定要测试一下。
2. 测试，哪种变体更快。有两个原因可能更快。试试吧。