SQL Server瞭解使用的事務日誌空間

Question

我是新手SQL服務器用戶，老闆要求我記錄事務日誌增長。我在生產服務器的虛擬數據庫上測試事務日誌行爲，但不明白某些事情。 生產服務器將只有數據庫上的批量插入（每天大約250 - 400批量插入）。測試的方法是

1. 爲每個文件分別批量插入。每個文件的開始/提交/回滾事務。對所有文件
2. 所有單個大容量insert.Single開始下的文件/提交/回滾事務（我不想這樣做，但我的老闆要它做這樣：d）。

的數據庫處於批量日誌模式，因爲所有插入都是批量處理。 日誌文件最初設置爲3 GB，在第一種情況下日誌文件大小保持不變，只有使用的日誌空間增加。

DBCC SQLPERF(Logspace)

雖然當進行批量插入尺寸增加日誌文件以一個百日咳27 GB但所用的空間保持最小0.5％的第二種情況。 我不理解日誌大小的突然增加，而使用的空間仍然很小。 開始/提交/回滾事務對事務日誌有任何影響嗎？ 數據只在當天插入一次，那麼保持簡單恢復模式下的生產數據庫真的很愚蠢？

Answer 1

開始/提交/回滾事務是否對事務日誌有影響？

自最早的活動事務以來的所有日誌數據必須保持活動狀態。現在爲什麼只使用日誌中0.5％的空間？ SQL Server爲活動事務保留日誌空間以支持回滾操作。回滾使用日誌空間。 SQL Server在保留空間時比較保守。在最糟糕的情況下，27GB可能是估計需要多少日誌才能回滾所有的大容量刀片。

您可能會在此處獲得最低限度的日誌大容量插入。這些導致最小的日誌寫入。但是，當您備份日誌時，會出現意外：將所有批量更改的頁面複製到備份中，以便日誌實際上能夠前滾您所做的寫入。

你可以使用簡單的日誌記錄模型嗎？這可能會使這些擔憂消失。簡單的日誌模型本身不會導致數據安全問題。這意味着您不能再進行日誌備份（這可能意味着在服務器爆炸的情況下數據尚未備份的風險更高）。

你是否應該使用單一的交易或多個較小的依賴於：

1. 你所需要的原子性的保證？請注意，大量批量插入的回滾可能非常緩慢。我從來沒有測試過。一定要測試它。
2. 測試，哪個變種更快。有兩個原因可能會更快。嘗試一下。