我们为什麽需要有经验的DBA

我们为什麽需要有经验的DBA

自从我进来园子之后，发觉虽然我们分享了很多质量很好的文章给大家，但是大家不一定能够消化得了这些文章

理解这些文章还是需要有一定环境，有环境你解决了，但是可能还有别的捷径减轻工作量

没有一些新方法或者好的方法，DBA永远只会忙个不停，还有一些我们习以为常的操作有可能会导致系统崩溃、宕机、数据丢失

很多DBA都会经历过误操作，这种误操作绝对是刻骨铭心的，往往一个F5下去，就盘然醒悟，但是很多时候为时已晚。

我们如何应对这些问题呢？

DBA工作要有效率，要尽可能避免误操作，这时候我们更需要有经验的DBA

这几天我在思考这个问题，大家可能会觉得我们的系统问题无非就是创几个索引，调整一下数据库的一些参数就可以了，

或者可以请一个刚毕业的毕业生做DBA，我朋友的朋友的一间手游公司就是这样的，他的公司在广州,

公司比较小，数据库不是很大，请了一个刚毕业不久的毕业生，工作经验大概一年，给他每个月3K~4K的工资

其实如果没有有经验的人（上司）带的话我觉得会比较危险~

---

下面说一下我们DBA平时可能会遇到的一些常见的误操作，并且介绍这些误操作带来的影响，主要针对的是SQLSERVER数据库

（1）业务高峰DDL误操作

在维护生产环境时，尤其是负载极高的核心生产环境，我们需要注意的是，你的每一个操作，都可能导致系统负载波动

甚至产生严重的性能问题

一、业务期间DDL操作

INT自增列爆了（溢出），于是直接写SQL alter table 表名 alter column [logid] bigint

速度可想而知：跑了3个小时，LDF日志已经快300G了，壮观啊......

还没执行完，硬盘快满了。

大约6个小时后，硬盘被撑满。再然后是漫长的回滚。。。

共耗时11个半小时。中间还引起同一个环境的其他测试库IO资源紧张。

上面这个只是某个朋友的测试库，如果换做业务库在业务期间后果不堪设想...

参考建议：

在高峰期禁止在数据库中进行DDL操作，DDL操作会导致一系列的SQL重解析、依赖对象失效等数据库连锁反应

一旦SQL重解析集中出现，系统必然经历负荷峰值，如果系统繁忙，可能就此挂起；

DDL导致的依赖对象消失，甚至无法通过编译，可能长时间影响业务系统正常运行。

所以，在生产环境中应当严格禁止高峰期的DDL操作，避免因操作不当或考虑不周带来的手忙脚乱或数据库灾难

（2）业务高峰加索引

大家遇到性能问题的时候，通常都会考虑添加索引来改善性能问题，例如给某个表添加一个非聚集索引，

让查询能够使用上这个非聚集索引，开发那边反映某一个查询很慢，分析执行计划发现那个查询使用了表中的某两个非聚集索引，

然后使用merge join合并数据，导致查询比较慢，因为这两个非聚集索引都没有完全覆盖到查询的谓词，

所以需要使用这两个非聚集索引查询出一部分数据然后再合并数据。

某DBA给这个查询加了索引提示，强制查询只使用其中一个索引，结果查询很快，但是因为开发是使用Entity Framework技术，

无法使用索引提示，于是DBA就创建了一个非聚集索引

那个查询语句是这样的：

select addon,title,name from biao where addon=xx and title =xx and systemid=xx and classid=xx order by addon

DBA考虑到索引的大小会对创建时间有影响，于是索引是这样定义的

CREATE NONCLUSTERED INDEX xxx ON  biao(addon,systemid,classid)

因为title字段的数据类型比较大，创建索引的时间可能会受到影响，所以并没有包括title字段

在下午4点业务繁忙的时候执行这个创建索引的语句，结果这个索引用了16个小时还没有创建完，表的数据量百万级别，晚上客户反应查询数据很慢

第二天上班，DBA马上终止了这个索引创建

其实开发那边当时说了：这个查询只是针对systemid为xxxx的时候很慢，当查询systemid非xxxx的时候查询是比较快的

最后，DBA在晚上低峰的时候创建了一个过滤索引，问题解决

参考建议：

统计信息更新和索引调整是优化数据库的常用手段，可是切记，业务峰值期间的统计信息更新可能导致的不可预计的执行计划改变，

可能使数据库瞬间停滞；而贸然在峰值添加的索引，或者不恰当的索引也有可能导致其他SQL执行计划的恶化，甚至影响到系统的性能

所以，在生产环境中，统计信息的更新或索引增减，都应当非常慎重，避免因为考虑和测试的不恰当带来额外的麻烦

（3）备份级误操作

我们曾经反复强调：备份重于一切！

可是很多人在执行备份时，依然会遭遇因为备份而导致的误操作故障

某天群里某人告诉我，他们的业务库在昨天误删除了一千多条数据，他想把这一千多条数据找回来，他跟我说他们每天都有日志备份

这一千多条数据都是某一个帐号的数据，如果找不回来这个帐号就。。。

我让他在新建一个数据库，然后在这个数据库上逐个逐个按顺序还原业务库的这些日志备份，

还原到误删除的那天的日志备份的时候回到误删除数据之前的某一个时间点

他跟我说还原不了，我问他有完整备份吗？

先还原完整备份，然后逐个逐个日志备份进行还原

他说刚接手DBA的工作，以前的DBA引咎辞职了，数据库完整备份没有。

现在不敬业的人还是那么多~

还有一次，某工厂半夜停电，因为数据库备份作业设置在每天凌晨2点，导致没有数据库备份

第二天早上，巧好磁盘阵列启动不了，丢了一天的数据。这个错误让我们更加记住了大家常说的：“备份重于一切”

参考建议：

1、执行备份并且进行备份检查

很多企业觉得有了备份就高枕无忧了，可是备份和“有效备份”还是两回事，

我们一定要检查备份成功与否，备份是否有效，这样才能保证危急关头有“备”无患

2、通过文档准备完善操作流程

在执行任务之前，准备文档手册，记录好什么时候做的完整备份，什么时候做的差异备份，什么时候做的日志备份，根据文档就能比较好

的按照备份顺序来还原备份，才不会手忙脚乱。执行时按照文档操作，确保不要节外生枝

俗语说：台上一分钟，台下十年功。只有在台下做好准备，台上的一分钟表演才能完美流畅；而如果台下只花一分钟准备，

那么台上来收尾恐怕就要十年功。所以，多做些准备工作，磨刀不误砍柴工

（4）进程级别的误操作

有很多维护工作涉及进程级别的一些操作，强制终止进程是很多DBA都做过的事情，

不过一旦失误，终止的进程出现问题，则会为数据库带来麻烦。

某DBA要完整备份SQLSERVER实例下的所有数据库，由于备份操作很慢，一个很小的数据库（20GB左右）都用了很长时间

因为实例下挂了很多数据库（有13个数据库），DBA就想通过重启SQL服务，让内存，磁盘I/O的压力降下来可能会让

数据库备份快一些，于是重启SQL服务，发现重启不成功，SQL配置管理器显示“正在挂起更改”

DBA以为数据库启动不起来了，事实上这个时候SQLSERVER还是在正常工作的，客户还能连接上数据库

只是当前SQLSERVER压力比较大

DBA以为SQLSERVER不动了，马上打开任务管理器，找到pid为5252的进程，想也不想就结束当前进程，

结果杯具的事情发生了。。。

某些数据库置疑并且有数据丢失，哎，这个真的要小心！

参考建议：

反复确认后再执行操作

对于终止进程的命令，要反复确认后再执行，并且注意，如果进程正在执行特定的操作，比如索引重建、Truncate 数据表等

意外中断可能导致严重的数据库内部错误。

所以，如果系统反应过慢，可以通过内存转储进行跟踪确认后再执行操作，并且进行强制终止时，要做好应对异常的准备！！

（5）数据文件误操作

数据库加了数据文件（ndf文件），用的raw device（裸设备），数据文件放在裸设备下，有人把raw device格式化了

不幸中更不幸的是恰巧前几天的备份没成功（通过备份作业），没法恢复

系统停了多少天不知道，反正据说是花了好几万RMB请高人做了磁盘恢复才搞定。现在一碰到裸设备就想到这个case，教训深刻！

至于什么是裸设备可以参考一下我这篇文章： 《SQLSERVER使用裸设备》

参考建议：

由于裸设备上的文件在文件系统上不可见，所以在处理裸设备文件时一定要反复确认，确保遵循成功的操作步骤，按文档、规范进行操作。

此外，系统管理员要和数据库管理员加强沟通，明确哪些裸设备在用以及用途

曾经有案例，裸设备被误操作格式化后，发现有数据文件存储于裸设备上

---

当前的情况

实际上，很多传统企业连DBA也没有，他们不像IT企业，有细分的职位，例如：DBA、软件测试工程师、运维工程师、系统工程师

他们可能只有一个开发部，而开发部里的员工一般会负责他们公司的ERP软件的二次开发、系统维护、系统测试等工作

当遇到数据库性能问题的时候，IT部门的人员束手无策的时候一般会找ERP软件提供商，ERP软件提供商搞不定的时候会找谁？？？

一般ERP软件开发商只会熟悉自己的软件，但是对于数据库这块的问题并不一定精通，也不是很专业

---

我们的团队 

我跟另外两位SQLSERVER MVP大牛组成了一个团队，专门为企业解决SQLSERVER方面的数据库问题，提供SQLSERVER方面的相关服务

在我们刚组成这个团队的时候就有好几位客户找到我们，叫我们帮他们优化数据库

其中某一个客户的情况是这样：

客户的公司是香港上市公司，因为是大集团，公司规模比较大

公司规模不断增大，生产线也不断增加,生产线目前有十几条，每天产生的业务数据非常多

当时客户刚购买系统的时候生产线只有两条，应付每天产生的业务数据没有什么问题

但随着生产线的不断增加，数据库性能问题越发突出

当时由SQLSERVER MVP陈畅亮来解决客户这个问题

他通过分析客户数据库的性能情况以及当前客户的业务情况对客户的业务库进行调整和调优

从调优之后一个多月的运行情况来看，客户的数据库性能问题没有再出现了

---

团队介绍

团队成员

陈畅亮

http://mvp.microsoft.com/en-us/mvp/Changliang%20Chen-5000640

林勇桦

http://mvp.microsoft.com/en-us/mvp/yonghua%20lin-5000434

黄钊吉

目前我们团队可以提供以下服务：

数据库咨询调优服务

数据库培训服务

我们的口号是：为客户提供最好的数据库专业服务！