首先說說,這個sql server的日誌,就是*log.ldf結尾的日誌檔案,他的日誌體系結構其實挺嚴謹,原意是---如果你不做日誌備份,就不給你刪日誌,然後也有指令碼給你**日誌空間,算是挺安全也方便實用了.
看起來是挺合理的,但是碰到缺心眼的開發或使用者,日誌一天天的脹大,而又忘記**的話,那就悲催了,這個時候你就不可能備份了,然後就清空不了log.ldf日誌,因為硬碟空間不夠用啊,不能備份也就不能刪日誌,就成了個死迴圈了.
我這邊就遇到這種事,日誌被撐到170g了,硬碟總共才200g空間,怎麼搞好呢?
我們平常用的方法是直接收縮:
–sql server收縮方法
最直接就是在sql server控制介面操作:
右鍵資料庫→任務→收縮資料庫→確定；
如果還是不理想,又或者試試這樣:
1、右鍵資料庫→屬性→選項→故障還原模型→設為簡單→確定；
2、右鍵資料庫→任務→收縮資料庫→確定；
3、右鍵資料庫→屬性→選項→故障還原模型→設為大容量日誌記錄→確定。
再不行,就要用下面的方法了:
首先我們看看日誌當前的狀態,
1
dbcc loginfo(test9572)
可以看到status=0的日誌，代表已經備份到磁碟的日誌檔案；而status=2的日誌還沒有備份。當收縮日誌檔案時，收縮掉的空間其實就是 status=0的空間，如果日誌物理檔案無法減小，這裡一定能看到非常多status=2的記錄。
然後我們看看日誌截斷延遲原因,
1
select [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] from [sys].[databases];
各種原因及解釋如下：
log_reuse_wait_desc 值
nothing 當前有乙個或多個可重複使用的虛擬日誌檔案。
checkpoint 自上次日誌截斷之後，尚未出現檢查點，或者日誌頭部尚未跨乙個虛擬日誌檔案移動（所有恢復模式）。
這是日誌截斷延遲的常見原因。
log_backup 需要日誌備份，以將日誌的頭部前移（僅適用於完整恢復模式或大容量日誌恢復模式）。
注意：日誌備份不會妨礙截斷。
完成日誌備份後，日誌的頭部將前移，一些日誌空間可能變為可重複使用。
active_backup_or_restore 資料備份或還原正在進行（所有恢復模式）。資料備份與活動事務的執行方式相同。資料備份在執行時，將阻止截斷。
active_transaction 事務處於活動狀態（所有恢復模式）。乙個長時間執行的事務可能存在於日誌備份的開頭。在這種情況下，可能需要進行另乙個日誌備份才能釋放空間。
看完了狀態,我的問題也是這個log_backup,日誌沒備份導致,也就是開頭說的死迴圈,因為硬碟空間不夠用啊,不能備份也就不能刪日誌,就成了個死迴圈了
總有解決辦法,辦法的原理是在簡單模式下進行，等清除動作完畢再調回到完全模式,下面來看:
首先,我們要確認日誌的檔名,因為硬碟上的檔名不一定是資料字典裡面的檔名,所以要確認下
1
2
3
4
use test9572
go
select file_id,name from sys.database_files;
go
然後就可以準備刪了:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
use [test9572]
go
alter database test9572 set recovery ****** with no_wait
go
--簡單模式
alter database test9572 set recovery ******
go
use test9572
go
dbcc shrinkfile (n'test9572_log', 11, truncateonly)
go
use [test9572]
go
alter database test9572 set recovery full with no_wait
go
--還原為完全模式
alter database test9572 set recovery full
go
刪完可以看看硬碟空間,一切都變好了,
關於sqlserver 事務日誌的研究
因專案要做sqlserver資料實時同步到mysql，於是想到了解析下 sqlserver的日誌 1個16進製制數對應4個二進位制數字，2個16進製制數字對應8個二進位制數字，及1個位元組。sqlserver版本 2008 建立了一張表table 2 改動id列其餘列不變 比較上圖發現 不同處實在這...
SQL Server日誌過大，清理日誌
直接執行下面的 use master go alter database 資料庫 set recovery with no wait goalter database 資料庫 set recovery 簡單模式 gouse 資料庫 godbcc shrinkfile n 邏輯名 2000,trunc...
SQL Server入庫日誌
exec sp gamelog import getdate 2010 03 01 exec sp gamelog import 2010 03 01 10 00 2010 03 01 9 00 補9點1個小時資料 select from mtunes elog order by sendtime ...