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

我是一名SQL server新手，老板让我记录事务日志增长。我正在生产服务器的虚拟数据库上测试事务日志行为，不了解某些事情。 生产服务器在数据库上只有批量插入（每天大约250-400次批量插入）。测试的方法是

为每个文件单独进行批量插入。为每个文件执行开始/提交/回滚事务

一次大容量插入下的所有文件。所有文件的一次开始/提交/回滚事务。（我不想做但老板希望这样做：D）

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

DBCC SQLPERF（日志空间）

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

Begin/Commit/Rollback事务对事务日志有任何影响吗

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

您可能会在这里获得最少的日志批量插入。这些会导致日志写入量最小。但是，当您备份日志时，意外的是：所有大容量更改的页面都会复制到备份中，这样日志实际上就能够向前滚动您所做的写入

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

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

你需要原子性保证吗？请注意，大容量插入的回滚可能非常慢。我从来没有测试过。一定要测试它

测试，哪种变体更快。两者都有可能更快的原因。试试看