一次 BO 报表引发的数据库宕机要点分析

春的味道，终于降临了魔都。

早上 9 点半，一改阴冷寒天人丁奚落的办公室，小伙伴们到的差不多了。气温转暖，大概大伙儿起得也比较早。捧着暖呼呼的包子，配上一杯豆浆，大家回顾着昨晚《王牌对王牌》的精彩段子，一边打开 Visual Studio Code 和 SSMS， 正常的一天又开始了。我喜欢这样的氛围，不搞 996，不只谈论 Code, 有说有笑之间把活干好，把钱挣到，养家糊口。

当然也会有部分同学，不喜欢那独秀馒头的味道，不习惯 KFC 鸡翅的油腻味，我最爱的星巴克热焦玛也被提出过“少喝点”的建议。每次我都是微微一笑，“就这口爱好了，从了吧”。有人会嫌机械键盘声音嘈杂，有人会说上班不要午睡和嗑瓜子。这些小插曲围绕程序员，不禁令人感慨“这生活才真实”。

“数据库怎么连不上了”，惊慌的小 C 打破了平静的早晨。

“我的可以啊”

“我的也不行哎”

紧接着，“噔噔噔” ITSM Ticket 轰炸式的袭击了每个开发的邮箱。

嗯，我知道活儿又来了。但作为团队老人，总不能顺着说句“好像我也不行”吧。怎么也要嘬上一口星巴克，装作一副毫不在意的悠闲模样，要是连老人都急了，小朋友们该惊动大 BOSS 了。

不过该来的还是要来。

“L，我们连接都不稳定，感觉数据库跪了”

“等等吧，可能是 replication 还没完”

虽是这么说，但心里还是止不住的打开 SSMS，“万一真不是 replication 闯的祸呢，再说快 10 点了，replication 早该完了的。” 在大家纷纷好奇和嘘嘘声中，好奇心还是止不住的逼我使上了三板斧的第一板，找到 session waits. 一个查询如果慢的出奇，可以先让它跑着，不去关它，从并发的角度找找，是不是被阻塞了,压根 CPU 没给它排资源？

往往第一板斧就能找到问题所在，而这一次也没有让我失望。满满一整屏的 PAGEIOLATCH_SH, S, IX, IS, 而最终定位都是指向一张 BO 报表，拉了 3 年的数据，且是加锁读。准是 BO 组哪位把数据库指向定位错了，把原本定向 Replication 服务器的给定位到 OLTP 来了。

既然找到了，就简单了， Kill ，发邮件。

继续把剩下的星巴克喝完

————  e n d ————

猜你喜欢：

听说你们的数据库并发 2 万就跪了？

如何让你的 SQL 执行的飞起？

动态 SQL 你还敢用？