数据库运维之路——关于tempdb暴增实战案例

    转眼间，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/

 

若有转载请保留原文地址!