您好:
1.請問 C# TransactionScope, 他若做 大量資料刪除 與寫入
那是否也會有LOG 增加問題?
2.一般資料庫LOG 若變大很多,OR原來 COPY DB 時的LOG 就很大 17G
是否可以參考
https://dotblogs.com.tw/chou/2011/01/09/20693
DBCC SHRINKFILE
來把LOG 減少?
還是有其他方式可以處理呢?
是否可以也當作排程定期處理?
謝謝
以提到的情況,先進行 log backup 把 log 從 ldf 內備份出來,之後再進行 DBCC ShrinkFile 壓縮 ldf 檔案至適合大小
ldf 通常都會先抓 mdf 的 10 - 20% 左右,之後再去觀察看看該大小是否適合,另外有正常排程進行 log backup 的話,是不用一直進行 DBCC ShrinkFile 才是,DBCC ShrinkFile 不該是日常維護動作
您好:
1.
目前,應該要於維護計畫中,
先做刪除檔案
-->備份資料庫工作(完整備份)
--> 備份資料庫工作(交易紀錄備份)
只是不知道 備份資料庫工作(交易紀錄備份) 是否會會做
ALTER DATABASE TestDB SET RECOVERY SIMPLE
讓他交易截斷
2.DBCC ShrinkFile 只是這次手動處理
但容量 您是說 MDF=10G好了, 20%=2G
設定好後,他應該還是可以自動增減吧
不會被固定死? 或者固定了,它會自動刪掉就LOG
謝謝
把 DB 直接切至 simple 去截斷 log,大多是緊急情況時使用,不需要當成日常維護動作
假如你可以每天把 DB 切回 simple,可以思考是否就沒有必要使用 full,直接用 simple 讓 SQL Server 自行管理 log 就好
mdf 和 ldf 預設是會自動成長,除非你去關閉它
只是不知道 備份資料庫工作(交易紀錄備份) 是否會會做
ALTER DATABASE TestDB SET RECOVERY SIMPLE
讓他交易截斷
不會,log backup 進行時不會主動把復原模式改為 simple
log backup 是把 log 從 ldf 內備份至指定位置
simple 是讓 SQL Server 自行管理 log,管理方式就是你提到的截斷交易,白話點就是交易完成後就放棄 log
看你選擇的方式~
我是每天備份資料庫.
復原模式:簡單
因為沒紀錄交易紀錄Log檔只有幾MB
https://learn.microsoft.com/zh-tw/sql/relational-databases/backup-restore/view-or-change-the-recovery-model-of-a-database-sql-server?view=sql-server-ver16
我還原資料庫也是從備份資料庫來的
(但我司要求沒那麼嚴格~上秒打資料不見,要把上秒的資料復原回來~)
2.這應該是作為一種臨時解決方案頻繁地縮減日誌檔案可能會導致效能問題,因為 SQL Server 需要重新分配磁碟空間。此外,如果你的資料庫在執行大量的寫入操作,那麼日誌檔案可能會迅速再次增長到原來的大小。
定期備份資料庫日誌可以幫助管理日誌檔案的大小。這是因為備份日誌檔案會釋放可用於重新使用的日誌空間。你可以將日誌備份作為你的常規維護計畫的一部分。