百万个冷知识百万个冷知识

百万个冷知识
一起学习百万个冷知识

一场生产交通事故紧急处置,瞅瞅彼时我是不是应付的聊聊聊SQLServerDBA

有些人历经这个操作方式过程可能将较为短,但绝大多数人历经的单厢较为长。一般资料库方法论知识的累积可能将会较为快,但或者说要从方法论联络到前述组织工作,再从前述组织工作中Wasselonne方法论,还真是两个很艰难的操作方式过程。

任何人资料库不达到一定的规模,很多难题就不会发生,那你也就难有良机去处置这些难题。两个DBA历经了大规模、大用户数量资料库的磨炼,处置了圣戈当斯区极为繁杂的难题后,就可以或者说得到方法论和课堂教学的并重,进而脱胎换骨成一位符合要求而杰出的DBA。

何须至千里,何须至千里;不积小流,何须成连城。

瞧瞧我们从日常生活网络管理组织工作,开始渐渐介绍SQLServer资料库。

圣戈当斯区机械故障

对于两个初学者DBA而言,资料库在恒定运转下,可能将每晚的主要各项任务是搞好存储,继续执行SQL,强化SQL等日常生活操作方式。但如果突发性了资料库的圣戈当斯区机械故障,看似最可怕的。

生前在刚成为SQLServer DBA的时候并没有人带,完全是靠他们一点一点走回来的。

先就两个圣戈当斯区机械故障的事例,来单纯说说怎样处置圣戈当斯区难题。

已经没和彼时他们是怎样处置第一场圣戈当斯区机械故障的,就拿平常组织工作中较为常用的圣戈当斯区机械故障事例来做分析。

一场中午销售业务监视系统,出访非常卡。

登入适当的资料库伺服器,缓存和IO恒定,资料库没互斥,没堵塞。CPU暴满。

从实战经验推论,引发CPU暴满的绝大多数原因,应该是SQL引致的。

•1.全表扫描器的SQL。

•2.数据倾斜引致的SQL的继续执行计划走偏。

•3.无法通过索引来强化的繁杂SQL。

解决难题

根据实战经验推论,是SQL引致的难题。

我们开始解决难题:

开启SQL Profiler监控。

主要抓消耗CPU资源的SQL语句。一般对销售业务较为繁忙的资料库系统CPU参数取值,大于4000。

经过监控发现一条SQL语句继续执行的非常频繁,而且消耗的CPU资源也很多。

我们再来看看这个SQL语句的继续执行计划:

大家可以发现,这个SQL语句在继续执行的时候 扫描器表消耗了大量的逻辑读,所以消耗CPU是很厉害的,证明一定没有走条件索引。

我们对条件字段加上索引。

发现这个SQL的逻辑读大幅度下降。SQL继续执行效率也得到了大幅提升。

CPU消耗恢复恒定,销售业务也恢复恒定了。

剖析难题的核心关键点

大家可能将会说,这个难题解决起来不是很单纯吗?

对于两个资深DBA而言或许并不难,但对于两个初学者而言,尤其是第一场遇到这类难题的初学者DBA而言,想要迅速定位和解决难题,其实并不容易。

因为圣戈当斯区机械故障发生很突然,而且销售业务和领导单厢催促,你是在很大的压力之下来处置圣戈当斯区难题的,所以这个操作方式过程是需要有过硬的基本功和心理素质的。稍有不慎,一旦处置不当,可能将会引发更大的生产交通事故,那是灾难了。

以前遇到过两个DBA在添加windows cluster节点的时候,错误地勾选了将所有符合条件的存储添加到群集。

这引致了整个windows群集报错无法使用,引发了严重的生产交通事故。

这个错误我以前也犯过,还好彼时是在半夜,而且不是重要的销售业务资料库,彼时立即解决了。这位DBA彼时很慌张,并且是销售业务时间,所以并没有第一时间想到办法去解决,最后虽然解决了,但却影响了销售业务较长时间的使用。这位DBA也算是较为资深的DBA了,但在面对突发性的生产交通事故时,同样会慌不择路。

所以我想告诉各位DBA的同学们,无论你是初学者还是资深,对于我们所管理的资料库系统都要有敬畏之心。尤其对于生产环境的操作方式,一定要小心小心再小心,因为任何人两个生产操作方式,都可能将会引致巨大的灾难。轻则影响销售业务使用,重则引致数据丢失。

对于任何人不是很确定的操作方式,一定要在测试环境进行测试,而对于生产环境的操作方式,一定要有对可能将会产生的难题的预判,并搞好回退的准备。

而当生产交通事故一旦发生,我们要做的,无非是冷静冷静再冷静。

1.一旦发生了生产交通事故,我们所要做的第一点,是根据目前所有的监控,去推论此交通事故的严重性。

2.交通事故很严重,严重到影响销售业务使用,那第一要务是尽快恢复销售业务。

•CPU暴满先从强化SQL着手。

•CPU恒定但磁盘出访很慢,多半是IO难题,可以考虑进行主备切换。

•一般硬件难题可以进行主备切换,非硬件难题多半和SQL相关,进行SQL强化。后期再进行销售业务拆分和读写分离。并对可以归档的历史数据进行归档。

3.交通事故不是很严重,没有严重影响销售业务使用,那么可以先处置优先级高的难题,后面再处置这些难题。

写在最后

本文主要分享了我曾遇到的一场生产交通事故,应该怎样来应付和处置,但如果我们每次都是充当救火队员的角色,那对于成为一位称职和杰出的DBA而言,还是远远不够的。

其实对于SQLServer的日常生活网络管理而言,首先要做的,我觉得应该是防患于未然

1.搞好资料库监控,可以使用zabbix监控CPU、缓存和磁盘IO等指标,使用Prometheus + Grafana,实现可视化界面和SQLServer精细化指标监控和展示。

2.根据SQLServer不同的销售业务系统,进行资料库监控指标的监视系统和通知。

3.对于新上的和老的销售业务表,都要搞好归档策略;对于无法归档的销售业务表,要尽早进行销售业务拆分、分库分表和读写分离。对于不能拆分和分库分表的销售业务大表,要尽早进行限制字段的增加。并对开发和销售业务方提出设计要求,严禁销售业务大表的不断增长。

4.良好的资料库设计才是最重要的。对于新上线的资料库表都要进行规范要求,不合理的设计一定要禁止上线。我们这里的资料库表上线,都必须有创建时间和更新时间字段,方便销售业务后期排查。对于大表的主键字段,都建议使用bigint。上线时候最好对索引也有预见,开发可以提出并建立合理的索引。

我觉得,一套完整的资料库监控系统,加上一份良好的资料库上线规范和资料库设计,其实就能把圣戈当斯区难题降低和防范一大半了。然后我们他们再深挖资料库方法论,以及进行资料库强化,那完全可以避免绝大部分圣戈当斯区难题的发生(除去硬件机械故障)。

其实要说的还很多,但限于篇幅,暂且就先说到这里。

搞好SQLServer的日常生活网络管理只是第一步,要想在SQLServer上有所建树,我觉得还是需要深挖SQLServer的原理,毕竟原理通透才是我们DBA的立身之本,然后是大量实战实战经验的累积了。相信这样深耕下去,你终会成为一位杰出的SQLServer DBA。

未经允许不得转载:百万个冷知识 » 一场生产交通事故紧急处置,瞅瞅彼时我是不是应付的聊聊聊SQLServerDBA
分享到: 更多 (0)

百万个冷知识 带给你想要内容

联系我们