TempDB暴涨问题排查
2017-09-08 11:04
691 查看
前言
tempdb日志文件暴增 ,造成磁盘空间不足,甚至影响业务运行。如何找到产生问题的元凶,加以解决避免以后再次发生。
正文
如图,tempdb log文件从7.40开始突然暴涨,因为 tempdb 0 M到 40Gtempdb 所在磁盘是C 盘
C盘的可用空间正好也为40G
在下午16.22左右的时候tempdb 文件暴涨已经影响到业务使用.临时解决是备份收缩日志。下面通过监控信息查找造成问题的原因:
查看7.40 之后这段时间 的运行语句,发下有个会话1085一直在运行
这个会话分配了内部对象(就是使用了tempdb的对象)
而言会话从7.46开始,一直持续到下午16.20 从时间上也非常吻合。所以他就是我们要找的元凶。
原因
对应普通的 简单模式的数据库无法重用日志的主要原因是没有做checkpoint,和存在没有提交的事务。但对于TEMPDB 来讲 他不需要预写日志。因为Tempdb 不支持重做(Redo)但需支持回滚(rollback).这也是tempdb日志存在的原因.如果一个事务还没有提交,那它可以在任何时候回滚。SQL Server必须做好这种准备,以便能够从日志记录中找回修改前的数据内容,完成回滚。在SQL Server里面,所有的日志记录都有严格顺序,中间不可以有任何跳跃。所以如果某个数据库有没有提交的事务,SQL Server会标记所有从这个事务开始的日志记录(不管和这个事务有没有关系)为活动事务日志
。这些日志记录都有可能“需要”被用来做回滚。
解决
找到语句后,从之前的截图的等待信息可以看出,这个语句一直持续运行的原因是,等待ASYNC_NETWORK_IO这说明,客户端和数据库服务器网络传输存在问题或者程序中未接收数据库传输的数据。更多的是后者。问题就提交给开发,检查代码,对程序进行优化。
补充
查看日志空间使用的方法:DBCC LOGinfo() 查看vlf的状态
DBCC SQLPERF(LOGSPACE) 建议用,查看日志空间的使用 ,更准。
从UI 或者查
都是不准的
相关文章推荐
- 数据库实战案例—————记一次TempDB暴增的问题排查
- 一次 load average 飙升问题排查的 RCA, luikimfai
- 分布式DB锁问题排查方法 - 阿里云HybridDB for PostgreSQL最佳实践
- 排查在 Azure 中创建新 Linux 虚拟机时遇到的 Resource Manager 部署问题
- 记一次APP和DB间流量异常问题的排查
- 一周第二次课(3月20日)1.6/1.7 配置IP 1.8 网络问题排查
- solr es调优化和问题排查
- Linux系统及应用问题分析排查工具
- 一起话单业务量下降问题的排查过程
- Java问题排查(运维篇)
- 【C++初级】static用法总结、问题探讨及常见错误排查
- zabbix action 未被触发问题的排查
- tomcat环境下服务器文件句柄耗尽(Too Many Open Files)的问题排查
- 一次订单业务问题的排查
- C/C++段错误问题排查和解决方法
- 配置IP及网络问题排查
- 一次FULL GC问题的排查
- 使用druid连接池的超时回收机制排查连接泄露问题
- phoenix-hbase 服务频繁挂掉问题排查
- 【分享】文件句柄数递增问题排查--引申出SOCKET泄露