转眼间，2021年的第一个季度已经到了最后一个月了，由于疫情原因，最近一段时间一直在北京，基本上没有出差，每天上班下班的日子感觉时间过的好快，新的一年继续努力奋斗啊。

    仔细回想一下，自己踏入到sql server的领域也已经三年之久了，从刚开始只会简单的增删该查，到现在2020年自己支持的一百多家客户的日常数据库运维，现在回想一下，还是成长蛮多的（小夸自己一下）

    现在想通过博客记录一下我的日常工作状态，回顾下这几年来在数据库遇到的各种各样的问题，给大家分享一下，欢迎各路大神前来指点。废话不多说，接下来直接步入主题，---------我在sql  server数据库的各种实战问题。

    这个问题我相信大家都遇到过很多次，那就是大家经常谈的tempdb数据库log文件暴增问题，稍不注意，就涨到了几百个G,甚至更大，严重的话还有可能撑爆磁盘，导致业务停止。在日常维护当中，这是个重点关注的问题。

举例：

下面是我在2020国庆前期给客户巡检发现的问题（还好有巡检），tempdb的log文件从9月21日开始增长，截止到9月30日已经从几百兆涨到了500G（想想好可怕），如果国庆前不做这次巡检，怕不是国庆要出大事情哦。

    看到这一现象，第一时间怀疑就是数据库中有未提交的事务，导致tempdb的log文件一直暴增，不释放。这里边就有两种情况了，一种是已经休眠的会话（sleeping）带事务,另外就是有一类大的操作用到临时对象、且做了排序之类的操作。带着这两个方向就开始找问题的原因啦。

    先看看近期有没有休眠的长时间的会话，点开空闲会话之后，就看到有两条长时间未提交事务的会话，点开第二条，再看看事务开始的时间，当时心里就想，80%就是它了，9月21日凌晨3点开始的事务，是一个人为的查询窗口，

    跟客户沟通了之后把这个会话杀掉了，tempdb的log文件立马就掉下来了，通过上面的IP地址找到这台机器，查询窗口还在，确实是有人在里边开启了事务，做的相应的操作，最后也忘记关闭窗，既没有commit也没有roll  back。所以才导致了这次tempdb的log文件的暴增

    这个案例呢，其实也没有涉及到很复杂的技术，造成这个问题的原因主要有两点，第一点是人为管控，在数据库管理上要有相应的规章制度。第二呢，就是信息管理人员没有每天对自己的数据库做巡检，还有就是这类的暴增问题也是可以设置告警的，也不会等到我们重要节日前的巡检，才发现此类问题。

 当然，关于数据库运维中还有遇到很多的真实场景，以后会继续跟大家分享。

--------------博客地址-----------------------------------------------------------------------------

原文地址: https://www.cnblogs.com/xiong-01/