一、 查詢日誌的使用空間
1. 查詢日誌率及當前大小
DBCC SQLPERF(LOGSPACE);
2. 查詢日誌文件當前大小及最大大小
select db.name as database_name,
db.is_auto_shrink_on,
db.recovery_model_desc,
mf.file_id,
mf.type_desc,
mf.name as logic_file_name,
mf.size*8/1024as size_MB,
mf.physical_name,
iif(mf.max_size=-1,-1,mf.max_size*8/1024) as max_size_MB,
mf.growth,
mf.is_percent_growth,
mf.state_desc
from sys.databases db
inner join sys.master_files mf
on db.database_id=mf.database_id
where mf.type=0
order by size_MB desc;
3. 查看os磁盤剩餘空間
exec sys.xp_fixeddrives
二、 日誌收縮
1. 收縮方法
-- 將目標庫改爲sample模式
USE [master]
GO
ALTER DATABASE testdb SET RECOVERY SIMPLE WITH NO_WAIT --簡單模式
GO
USE testdb
GO
DBCC SHRINKFILE (N'testdb_log',20,TRUNCATEONLY)
GO
-- testdb_log爲日誌文件邏輯名；20(MB)爲收縮的目標size，若不指定則縮小到日誌初始大小
-- TRUNCATEONLY釋放文件末尾所有可用空間給操作系統，但不在文件內部執行頁移動。數據文件只收縮到最後分配的區。如果指定了target_size，則會忽略該參數。TRUNCATEONLY只適用於數據文件。對於日誌文件，不使用該參數也會返回磁盤空間。
--改回full模式（測試環境不必執行）
USE [master]
GO
ALTER DATABASE testdb SET RECOVERY FULL WITH NO_WAIT
GO
2. 查詢日誌無法收縮原因
SELECT name,recovery_model_desc,log_reuse_wait_desc FROM sys.databases WHERE name = '庫名';
可能原因及對應解決方法
|
原因名 |
解釋 |
解決方法 |
|
NOTHING |
當前有一個或多個可重複使用的虛擬日誌文件 |
正常，不需處理 |
|
CHECKPOINT |
自上次日誌截斷之後，尚未出現檢查點，或者日誌頭部尚未跨一個虛擬日誌文件移動（所有恢復模式）。類似oracle的active狀態redolog。 |
這是日誌截斷延遲的常見原因，一般正常，不需處理
|
|
LOG_BACKUP |
需要日誌備份，以將日誌的頭部前移（僅適用於完整恢復模式或大容量日誌恢復模式） |
進行日誌備份後 |
|
ACTIVE_BACKUP_OR_RESTORE |
數據備份或還原正在進行（所有恢復模式）時，將阻止截斷。 |
一般正常，但需要檢查備份日誌時間是否過長，若想直接截斷日誌，需要先kill掉正在進行備份/還原的會話 |
|
ACTIVE_TRANSACTION |
事務處於活動狀態，一個長時間運行或者未提交的事務可能存在於日誌備份的開頭。
事務被延遲。“延遲的事務”是有效的活動事務，因爲某些資源不可用，其回滾受阻 |
檢查最老的活動事務（最久未提交） DBCC OPENTRAN GO select st.text,t2.* from sys.dm_exec_sessions as t2,sys.dm_exec_connections as t1 cross apply sys.dm_exec_sql_text(t1.most_recent_sql_handle) as st where t1.session_id=t2.session_id and t1.session_id>50 |
|
DATABASE_MIRRORING |
數據庫鏡像暫停，或者在高性能模式下，鏡像數據庫明顯滯後於主體數據庫（僅限於完整恢復模式） |
檢查數據同步問題 |
|
REPLICATION |
在事務複製過程中，與發佈相關的事務仍未傳遞到分發數據庫（僅限於完整恢復模式）。 |
給標有replication的數據庫任意一個表創建事務複製，然後刪除，再執行收縮（這是數據庫的一個BUG）。當使用CDC時，也會有該問題。 |
|
DATABASE_SNAPSHOT_CREATION |
正在創建數據庫快照（所有恢復模式） |
這是日誌截斷延遲的常見原因，通常也是主要原因，一般不需處理 |
|
LOG_SCAN |
正在進行日誌掃描（所有恢復模式） |
這是日誌截斷延遲的常見原因，通常也是主要原因 |