使用 SSIS 批量插入任務的 SIMPLE 恢復模型中的數據庫已滿
我有一個簡單恢復模式的數據庫，有 10GB 可用空間。
我試圖通過 SSIS 批量載入載入的文件是 1GB。
該表是空的（在每次載入之前被截斷），是一個堆並且沒有非聚集索引。它是一個 varchar(255) 欄位表。
執行批量插入任務時，我可以看到數據庫大小從 2GB 增長到 12GB（最大可用空間），其中空間不足並返回以下消息：
$$ Bulk Insert Task $$錯誤：發生錯誤並顯示以下錯誤消息：“無法為數據庫 ‘DBNAME’ 中的對象 ‘dbo.tablename’ 分配空間，因為 ‘PRIMARY’ 文件組已滿。通過刪除不需要的文件、刪除文件組中的對象來創建磁碟空間，向文件組添加其他文件，或為文件組中的現有文件設置自動增長。”。 首先，我認為因為我處於簡單恢復模式，所以不會記錄批量載入。我知道這是當表中有數據和聚集索引時，但這裡也不是這種情況。我假設批量插入任務包含在其中，因為它應該使用 BCP。我錯了嗎？
其次，一個 1GB 的文本文件會在 SQL Server varchar 欄位中產生 10GB 似乎很奇怪。這似乎很奇怪。數據沒有被轉換，它被批量載入到表中。為什麼會長得這麼大？
我可以看到數據庫大小從 2GB 增長到 12GB（最大可用空間），其中空間不足並返回以下消息：
問題是您只是用完了磁碟空間並且物理文件無法增長以完成事務，或者您對 SQL 文件增長設置有限制並且物理文件無法增長更多以完成事務（無論最大空間如何可用的意思是準確的，例如每個設置或磁碟容量）。
我想因為我處於簡單恢復模式，所以沒有記錄批量載入。
根據下面的站點和引用的文本，它確實聲明最小日誌記錄比完整日誌記錄更有效，但它沒有說明在恢復模式下根本不會發生任何****日誌記錄。
SIMPLE在簡單恢復模式或批量日誌恢復模式下，批量導入操作的最小日誌記錄降低了批量導入操作填滿日誌空間的可能性。最小日誌記錄也比完整日誌記錄更有效。
因此，這意味著當數據庫處於恢復模式時仍然會發生 SQL 事務日誌記錄，但
SIMPLE與恢復模式相比，它是最少的日誌記錄FULL。為什麼會長得這麼大？
似乎解釋是您送出的
BULK INSERT操作事務大小是巨大的。只需在 SSIS 中製作邏輯的送出\批量大小參數，或在較小尺寸的包中執行 TSQL。嘗試使用 100、1000、10000、100000 等進行測試，看看什麼可以為您提供最佳結果並防止問題發生。如果事務較小，一旦送出的事務在
SIMPLE恢復模式下送出，則送出的事務的日誌空間可以被後續BULK INSERT（或其他）事務重用。其他資源
（這些文章似乎對 SSIS 包區域中的潛在參數進行了一些引用，以設置較小的事務等。標題或步驟可能是針對不同的最終目標，但這些內容中可能包含您可能需要的適用內容更改您的 SSIS 邏輯以糾正您的問題，因此這些可能值得一讀。）