极客视点
极客时间编辑部
极客时间编辑部
113241 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/04:59
登录|注册

观点:一名忙碌的DBA人员如何减轻工作?

讲述:子阳大小:2.28M时长:04:59
近日,一位名叫 Disqus 的 DBA 在敏捷 SQL 俱乐部上发文,描述了自己日常工作中的忙碌情况以及他的应对方法,以下为重要内容。
我是一名非常忙的 DBA。开发人员常常在不经过我 Review 代码的条件下,直接提交到生产环境。这导致我一次又一次地陷入被动的境地,不断地消耗额外时间来解决性能问题。
想象一下,如果有一群人可以帮你审查代码,如果随着时间的推移你可以让程序员有能力自己检查 SQL 代码,这样就可以减少你花费 1%、10%、50% 甚至 100% 的额外时间。但遗憾的是,我们的开发人员并不精通 SQL。
我们先看看 DBA 在代码评审时应该做哪些事情:
确保格式正确,符合全部的标准。
是否有潜在的 SQL 注入的风险。
考虑修改的风险,比如在一个 10 亿数据的表上面,修改聚集索引所花费的时间,实时性要求比较高的系统是否能接受这种时间上的消耗。
考虑一下对于性能的影响 。
代码是否符合开发人员的预期,merge 语句中的 update 语句是否正确。
想要开发人员足够了解 SQL,并能够独立自查自己的代码,减少线上问题,有许多需要注意的东西。以上列出的只是其中一部分问题。通常来讲,快速看一遍代码很容易做到,但是没什么太大的作用。花费时间去思考修改的内容往往能够找出问题,但是也比较耗时,而且 DBA 往往没有那么多时间。所以这种情况,我常常称它是一种恶性循环。
下面我们来分析一下 DBA 做的每一件事,看看 DBA 能做些什么。

1. 确保格式正确,符合全部的标准

自动化的方式可以直接节省全部的时间。在提交代码时,自己写一些工具来验证代码的格式是否正确,这里可以使用 DacFx 提供的功能,或者购买 Redgate SQL Code Guard,或者采取一些其他的方式。较好的方式是在提交代码的时候,如果不符合你的标准,就自动将格式修改正确。在这种方式下,你基本可以确认,已经提交的代码一定是符合标准的。
需要注意的是,我假设执行时,你的代码在源代码管理中,并且它不会停止所有操作(可能不停止备份)。

2. 是否有潜在的 SQL 注入的风险

将这 100% 自动化,是否使用了 sp_executesql 或 exec 这种“有风险”的存储过程?如果有的话你可以发出警告,或者你可以检查代码来查看是否有传递连接字符串的情况。

3. 考虑修改的风险以及对于性能的影响

这里有两件事需要你来做,第一件事是提供一个好的测试环境,开发人员可以在这里编写性能测试。保证每次提交代码的时侯,运行这些测试,如果需要检查的脚本(包括需要部署的脚本)未在指定时间内完成检查工作,则阻止项目打包。
你可以做的第二件事,是跟开发人员一起工作并对他们进行一些训练,比如在一个小时的午餐时间分享一些信息给他们,就是一个比较好的方式。分享的主题可以包括:“如何查看执行计划”、“SQL Server 以及索引相关的内容”、“如何统计比较感兴趣的信息”等等。
我觉得你脑海中浮现的内容肯定比我想到的更多。我发现,当开发人员和 DBA 都开始书写并分享自己见解的时候,这种方式会更加奏效。尽管内容可能并不是很深入,但是这并不重要,因为开发人员和 DBA 在这个过程中都会学习到一些知识。
好的性能测试需要有人去编写,而且,开发人员可以从中学到一些东西,比如如何查看执行计划。一旦有了这些测试,你的生活就会瞬间变得很惬意。如果培养了一个学习环境,在需要时提供一些指导,那么你就可以逐步将代码 Review 的工作留给开发人员自己,而你从每天繁杂的工作中解脱出来,将精力放在更精彩的数据库工作上。

4. 代码是否符合开发人员的预期

这对我来说是一个非常关键的问题,你可以随意购买许多格式化工具,但是即使是世界上最漂亮的代码也可能有大量的逻辑错误。如果代码是 T-SQL,我们可以使用测试框架 tSQLt,来确保我们编写的代码符合一组既定标准。代码评审可以查看已经编写的测试和需求,并查看测试是否满足条件。
以上就是今天的内容,希望对你有所帮助。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 庞小胖
    工具?
收起评论
大纲
固定大纲
1. 确保格式正确,符合全部的标准
2. 是否有潜在的 SQL 注入的风险
3. 考虑修改的风险以及对于性能的影响
4. 代码是否符合开发人员的预期
显示
设置
留言
1
收藏
41
沉浸
阅读
分享
手机端
快捷键
回顶部