如服务器上有创建MS SQL Replication，则会自动创建distribution数据库，有时distribution数据库日志文件过大
解决方案：
1.第一种方案：
查看日志大小， dbcc sqlperf(logspace)，查看哪个数据库日志文件过大，如果有数据库日志文件非常大，就需要通过检查日志的VLF使用情况来进行诊断，日志文件是通过重用VLF文件来实现事务日志按照lsn顺序写入到日志文件的，如果当前VLF的状态都是已使用（2使用0未用），那么收缩文件是无法收缩这些文件的。
查看日志无法收缩的具体原因： SELECT name,log_reuse_wait_desc FROM sys.databases where name='数据库名称'
log_reuse_wait_desc，包含哪几种：
NOTHING
当前有一个或多个可重复使用的虚拟日志文件。
CHECKPOINT
自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。这是日志截断延迟的常见原因。
LOG_BACKUP
需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。
注意：日志备份不会妨碍截断。
完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。
ACTIVE_BACKUP_OR_RESTORE
数据备份或还原正在进行（所有恢复模式）。
数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。
ACTIVE_TRANSACTION
事务处于活动状态（所有恢复模式）。一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份才能释放空间。
事务被延迟（仅适用于 SQL Server 2005 Enterprise Edition及更高版本）。“延迟的事务” 是有效的活动事务，因为某些资源不可用，其回滚受阻。
DATABASE_MIRRORING
数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。
REPLICATION
在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。
DATABASE_SNAPSHOT_CREATION
正在创建数据库快照（所有恢复模式）。
这是日志截断延迟的常见原因，通常也是主要原因。
LOG_SCAN
正在进行日志扫描（所有恢复模式）。
这是日志截断延迟的常见原因，通常也是主要原因。
针对延迟日志截断原因的部分解决方案，
执行下面T-SQL语句，收缩数据库日志大小，
USE [数据库名称]
GO
ALTER DATABASE 数据库名称 SET RECOVERY SIMPLE WITH NO_WAIT
GO
DBCC SHRINKFILE (N'数据库名称_log' , 400, TRUNCATEONLY)
GO
DBCC SHRINKDATABASE(N'数据库名称' )
GO
ALTER DATABASE 数据库名称 SET RECOVERY full WITH NO_WAIT
GO
2.第二种方案：
-- stop agent first
ALTER DATABASE DISTRIBUTION SET OFFLINE
-- 假设原来的文件是 C:\path\to\distribution_data.mdf
-- 移动分发数据库文件
ALTER DATABASE [distribution]
MODIFY FILE
(
NAME = 'distribution',
FILENAME = 'XXX:\distribution.mdf' --新目录存放数据库文件
);
-- 如果有日志文件，也需要相应地移动
ALTER DATABASE [distribution]
MODIFY FILE
(
NAME = 'distribution_log',
FILENAME = 'XXX:\distribution.ldf' --新目录存放数据库文件
);
ALTER DATABASE DISTRIBUTION SET ONLINE
标签：文件,DATABASE,数据库,恢复模式,distribution,磁盘空间,服务器,日志,MSSQL From： https://www.cnblogs.com/dxmdiy/p/18143793