数据库 'tempdb' 的事务日志已满。若要查明无法重用日志中的空间的原因
2017-08-07 15:01
375 查看
最常的做法:
比较保险的做法:
1. 将tempdb移至D盘或者其它非系统分区;
2. tempdb增加文件大小(最大值至少5G,初始值可大一点)并重启SqlServer服务.
参考文章:
1. 微软官方优化数据库:点击打开链接
2. 点击打开链接
注:微软的优化里有:
将 tempdb 的恢复模式设置为 SIMPLE。 此模式自动回收日志空间以保持较小的空间要求。
其实是无效的,因为tempdb无法设置为simple恢复模式。
---------------------------------------
--查看会话
--中止会话
Kill session_id
--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 | 此值当前未使用。 |
相关文章推荐
- 数据库 'xxx 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- 今天打开网站,突然发现sql 2005出现错误:数据库 'mybase_db' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- sql 2005出现错误:数据库 'Twitter' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- 数据库 'tempdb' 的事务日志已满。若要查明无法重用日志中的空间的原因
- 数据库 'DB 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.d
- SQL SERVER2005 数据库 的事务日志已满 查明无法重用日志中的空间的原因
- SQLSERVER数据库 'XX' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参......
- 数据库 'MessageManage' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- 数据库 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- 数据库的事务日志已满。若要查明无法重用日志中的空间的原因
- 数据库的事务日志已满。若要查明无法重用日志中的空间的原因
- 数据库的事务日志已满 若要查明无法重用日志中的空间的原因,请参阅sys.databases
- 今天打开网站,突然发现sql 2005出现错误:数据库 'mybase_db' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- "数据库 'xxx' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- 数据库 的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅 sys.databas解决方法
- 错误"数据库的事务日志已满。若要查明无法重用日志中的空间的原因"的解决方法
- 数据库 的事务日志已满。若要查明无法重用日志中的空间的原因 请参阅 sys.databases 中的 log_reuse_wait_desc 列。
- SQLSERVER数据库 'XX' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参......
- SQLSERVER数据库 'XX' 的事务日志已满。若要查明无法重用日志中的空间的原因,请参......
- Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: 数据库 'BHIoTV1.1' 的事务日志已满。若要查明无法重用日志中的空间的原