為臨時數據庫推薦的 SQL Server 事務日誌設置？
我正在尋找有關如何為開發團隊使用的數據庫設置事務日誌的建議。這些數據庫是短暫的，因為我們從不關心硬體/軟體故障時的數據恢復。相反，每次開發人員開始一項任務時，他們都會創建一個新數據庫並從頭開始填充數據，因此他們也會這樣做以防硬體故障。另一個案例是自動化測試，每次測試執行都會創建一個新數據庫。
目前，由於開發人員的使用模式（測試不同類型的查詢，頻繁的數據批量載入），日誌增長很多，更多的是障礙而不是幫助。我們已經看到在開發人員工作僅一個小時後日誌開始佔用 0.5 TB 的情況，迫使他們手動截斷日誌。由於我們不想在自動化測試期間手動截斷日誌，我們需要為它們分配更大的機器。我懷疑需要更多的 I/O，從而減慢操作速度。
我可以在 SQL Server 文件和其他材料中找到的任何建議都是針對生產伺服器的，並且專注於數據恢復，這與我正在尋找的完全相反。
當數據恢復無關緊要時，關於配置 SQL Server 事務日誌的一些好的做法，而不是易於操作、資源使用和原始速度是一個更大的問題？
簡單恢復模型並不意味著不使用事務日誌。
這只是意味著 SQL Server 可以清空日誌（也就是“截斷”日誌），而不必自己安排定期事務日誌備份。即，日誌需要最大/最早打開的事務的空間，因為日誌不能被截斷超過最舊的事務 - 無論恢復模型。
然而，簡單確實意味著可以以最少記錄的形式執行某些操作。這包括創建/更改/刪除索引、SELECT INTO、批量載入數據以及如果星星正確對齊，還可以插入 … SELECT。
因此，如果 simple 不能為您解決空間使用問題，那麼您必須研究操作是如何完成的 - 即，如我上面提到的，教育開發人員有關最小日誌記錄的知識。
至於速度，最低限度的日誌記錄也會有所幫助，因為您的 I/O 更少。較大的事務（出於某種原因）意味著對 LDF 文件的同步 I/O 較少。從純粹的配置方面來看，我想 ldf 文件的一些 RAM 磁碟選項可能會有所幫助 - 但如果您需要大型 ldf 文件，這可能不可行。
問題： “當數據恢復無關緊要時，關於配置 SQL Server 的事務日誌有哪些好的做法，而不是易於操作、資源使用和原始速度是更大的問題？”
恕我直言：
ALTER DATABASE ... SET DELAYED_DURABILITY = FORCED如何控制事務的持久性
數據庫級控制
作為 DBA，您可以使用以下語句控制使用者是否可以在數據庫上使用延遲事務持久性。您必須使用 ALTER DATABASE 設置延遲的持久性設置。
ALTER DATABASE ... SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }已禁用
$$ default $$使用此設置，在數據庫上送出的所有事務都是完全持久的，無論送出級別設置如何 (DELAYED_DURABILITY=$$ ON | OFF $$）。無需更改儲存過程和重新編譯。這使您可以確保任何數據都不會因持久性延遲而面臨風險。 ALLOWED 使用此設置，每個事務的持久性都在事務級別確定 - DELAYED_DURABILITY = { OFF | 在 }。有關詳細資訊，請參閱原子塊級控制 - 本機編譯的儲存過程和 COMMIT 級控制 -Transact-SQL。
FORCED 使用此設置，在數據庫上送出的每個事務都是延遲持久的。無論事務指定完全持久（DELAYED_DURABILITY = OFF）還是不指定，事務都是延遲持久的。當延遲事務持久性對數據庫有用並且您不想更改任何應用程式碼時，此設置很有用。