一、 查询日志的使用空间
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 |
正在进行日志扫描（所有恢复模式） |
这是日志截断延迟的常见原因，通常也是主要原因 |