查詢有關 SQL 備份、日誌文件和日誌傳送
我得到了一個 MS-SQL 伺服器備份 .bak 文件來在我的機器上恢復，它的大小約為 25mb，但需要 10Gb 的可用磁碟空間，因為日誌文件就是那個大小，這表明他們的日誌文件沒有被退出也沒有截斷。（請注意，10Gb 日誌文件必須大部分為空，否則 .bak 文件會比 25mb 大很多）
這個數據庫是一個很少使用（可能不是很重要）的數據庫，同一個站點有另一個更重要和更大的數據庫，（大小在 5 Gb 區域的某個地方）它有一個更小的日誌文件，所以我是假設該數據庫的日誌文件正在被修剪。
有人告訴我，該站點使用日誌傳送將他們的主數據庫備份到第二台伺服器，但我不確定是否也在備份較小的數據庫。
所以，我猜他們要麼只對主數據庫使用日誌傳送，要麼只備份主數據庫。
這提出了幾個問題
- 現場的使用者/管理員是否可以執行任何類型的備份來干擾或中斷日誌傳送？
- 如果您使用日誌傳送，這足以確保日誌不會持續增長，還是您仍然需要備份日誌（例如使用維護計劃）？
- 這個不是很重要，但是如果我得到的備份需要比可用空間更多的日誌文件空間，是否有任何方法可以在沒有日誌文件或不從源頭修復問題並獲取新的問題的情況下恢復它備份。
SQL 在日誌備份後實際上並沒有調整日誌的大小 - 相反，它只是更改內部元數據以標記可以重複使用的日誌部分（稱為虛擬日誌文件或 VLF）。這個過程稱為日誌截斷。因此，如果沒有可用的 VLF，您的日誌文件將會增長，但它永遠不會縮小，除非您手動告訴 SQL Server 這樣做。
由於數據庫的日誌大小為 10Gb，因此無論實際使用的數量如何，恢復備份也會創建一個 10Gb 的日誌文件。這同樣適用於任何數據文件。
您可以使用“ DBCC SHRINKFILE ”命令縮小日誌文件- 儘管除非您確定日誌不會再次增長到 10Gb，否則我建議不要這樣做（增長文件會影響性能）。長時間執行的事務或數據庫維護活動可能會佔用大量事務日誌，因此值得在縮小之前找出日誌為 10Gb 的原因。
回答你的3個問題：
現場的使用者/管理員是否可以執行任何類型的備份來干擾或中斷日誌傳送？
是的 - 如果您通過將日誌備份到日誌傳送配置之外的目標來中斷備份鏈，導致備份未應用於輔助伺服器。在這種情況下，您應該使用COPY_ONLY備份，因為它們不會破壞日誌鏈。這僅適用於日誌備份，因為完整備份不會截斷日誌。
如果您使用日誌傳送，這足以確保日誌不會持續增長，還是您仍然需要備份日誌（例如使用維護計劃）？
這應該沒問題，除非有其他東西阻止日誌被截斷，例如數據庫鏡像、長時間執行的事務、複製甚至數據庫快照創建。找出日誌未被截斷的原因的方法是查看sys.databases中的 log_reuse_wait_desc 列。
日誌傳送的備份作業也有可能（但不太可能）正在使用 COPY_ONLY/NO_TRUNCATE 進行備份，這意味著日誌文件將在滿後繼續增長。
這個不是很重要，但是如果我得到的備份需要比可用空間更多的日誌文件空間，是否有任何方法可以在沒有日誌文件或不從源頭修復問題並獲取新的問題的情況下恢復它備份。
如果縮小日誌文件然後進行完整備份，當您恢復它時，SQL Server 將使用較小的日誌文件創建數據庫。
如果您無法縮小但要恢復到開發/測試伺服器，那麼您可以掛載一些臨時儲存並在 RESTORE 語句中使用“WITH MOVE”將日誌文件移動到該驅動器，然後縮小日誌並移動日誌歸檔臨時儲存（關於是否應該縮小日誌的警告仍然適用！）。