数据库 'tempdb' 的事务日志已满。若要查明无法重用日志中的空间的原因

最常的做法：

--1.清空日志
DUMP TRANSACTION tempdb WITH NO_LOG
--2.截断事务日志：
BACKUP LOG tempdb WITH NO_LOG
--3.收缩数据库文件
DBCC SHRINKDATABASE(tempdb)

比较保险的做法：

1. 将tempdb移至D盘或者其它非系统分区;

2. tempdb增加文件大小(最大值至少5G，初始值可大一点)并重启SqlServer服务.

参考文章：

1. 微软官方优化数据库：点击打开链接

2. 点击打开链接

注：微软的优化里有：

将 tempdb 的恢复模式设置为  SIMPLE。 此模式自动回收日志空间以保持较小的空间要求。

USE [master]
GO
ALTER DATABASE tempdb SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE tempdb SET RECOVERY SIMPLE   --简单模式
GO

其实是无效的，因为tempdb无法设置为simple恢复模式。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

--查看会话

SELECT * 
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 
ORDER BY t1.session_id

--查看日志状态
SELECT NAME,log_reuse_wait_desc FROM sys.databases

--中止会话

Kill session_id

微软文档：导致日志截断延迟的因素　 点击打开链接

下表介绍了 sys.database 目录视图的 log_reuse_wait 列和 log_reuse_wait_desc 列的值。

 

log_reuse_wait 值	log_reuse_wait_desc 值	说明
0	NOTHING	当前有一个或多个可重用的虚拟日志文件。
1	CHECKPOINT	自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。 这是日志截断延迟的常见原因。 有关详细信息，请参阅检查点和日志的活动部分。
2	LOG_BACKUP	要求日志备份将日志标头前移（仅适用于完整恢复模式或大容量日志恢复模式）。   日志备份不会阻止截断。 注意：   日志备份完成后，日志标头将前移，并且一些日志空间可能会变为可重新使用。
3	ACTIVE_BACKUP_OR_RESTORE	数据备份或还原正在进行（所有恢复模式）。 数据备份与活动事务的工作原理相同；数据备份运行时，将阻止截断。 有关详细信息，请参阅本主题后面的“数据备份操作与还原操作”部分。
4	ACTIVE_TRANSACTION	事务处于活动状态（所有恢复模式）。 在日志备份开始时，可能存在长时间运行的事务。 在这种情况下，释放空间可能需要进行其他日志备份。 有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。 事务将延迟（仅适用于 SQL Server 2005 Enterprise Edition 及更高版本）。 “延迟的事务”实际上是其回滚由于某些资源不可用而受阻的活动事务。 有关导致事务延迟的原因以及如何使它们摆脱被延迟状态的信息，请参阅延迟的事务.
5	DATABASE_MIRRORING	数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。 有关详细信息，请参阅本主题后面的“数据库镜像与事务日志”部分。
6	REPLICATION	在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。 有关详细信息，请参阅本主题后面的“事务复制与事务日志”部分。
7	DATABASE_SNAPSHOT_CREATION	正在创建数据库快照（所有恢复模式）。 这是日志截断延迟的常见原因，通常也是主要原因。
8	LOG_SCAN	正在进行日志扫描（所有恢复模式）。 这是日志截断延迟的常见原因，通常也是主要原因。
9	OTHER_TRANSIENT	此值当前未使用。