DBA在系统开发中扮演着什么角色？

很少有人会正确地认识到，DBA在系统开发和设计上扮演的重要角色，在这里是一个关键环节之一，那么开发DBA到底是干什么的呢？所以本期的学习中，是由一个DBA有着丰富经验的人员给我们分享一些观点，希望对大家学习系统设计和开发益处。

一、 许多应用系统的性能或稳定性仍不理想
许多应用的性能是不能令人满意的，或系统数据是难以再现一些奇怪的错误，这些问题（特别是性能问题）有时并不在系统的开始将被反射，但与系统的操作，数据增加逐渐变难以解决的，要在一个很麻烦的系统和用户扩展的后期，这些问题的原因往往反映了一点：开发，这些系统谁不懂数据库的设计！基于Oracle的应用中，例如，一个简单的例子：
1、底层数据结构不合理
由于缺乏专业人士的帮助DBA，很多底层数据库系统设计表结构有问题的。该系统做过的人都知道，底层的数据库结构不合理，大变革带来了几乎等于重建的费用！我见过一个OLTP系统中，核心表高达100场，创下了平均超过8K，8K如果违约的Oracle块，超过半行必须产生行链接！最糟糕的是，设计表结构，使人们仍然认为他们采取冗余的优势，减少表之间的连接，其实人不知道什么是模式，什么是更新异常，按照范式表应该分为两个表，但如果你想改变几乎所有的程序必须改变！虽然范式不是更好，但它绝对是设计的东西必须彻底了解。
我相信大多数DBA同意，更新级联的成本非常高，因此采用冗余，而不是一个门轻松掌握技能应该避免多余的级联更新的发生，对于关系数据库设计。底层数据库设计结构不合理，对系统的性能埋下了沉重的定时**，系统所在的客户不到一年的运行，数据的一点点多了起来，性能，稳定性会直线下降量，和重建在成本高，购买一台新的服务器肯定只是治标不治本。如果基础数据表结构是如何设计的高级DBA的意志？当然，如果你这样做完全让DBA数据库表结构设计，DBA必须是整个系统的操作细节，这在DBA，有没有在人力资源方面有一定困难，毕竟很清晰的认识，保持一个良好的网上服务器的DBA已经占据了大量的资源，和领导平时多注意这一点。少数领导可以识别的DBA在系统发展和设计上线系统的作用，和维持，搬运DB失败相比，稳定性和整个系统的性能，也同样重要！
2、SQL性能问题
系统的开发，通常和DBA是没有什么关系的，但是，如果DBA对系统有足够的了解，这时候也是可以做不少贡献的。比如，检查系统业务的数据流是否正确，这个需要通过一些手段，比如sqltrace、10046等，详细对系统的逻辑实现进行检查，一方面查出系统中过于消耗资源的或编写不规范的SQL及时进行调整优化，另一方面，查出系统中不合理的数据库访问，不要到了线上才发现问题，那时可能已经宕机了。简单举个例子，当一个页面需要多处显示商品的类目列表时，程序往往容易犯一个错误，就是多次以同样的SQL读取出同样的数据，并应用于每一个列表显示上，如果你只读取一次，或者干脆在Web层进行cache（要有适当的刷新策略），就可以大大减少单次访问该页面在DB上的I/O消耗。有时甚至会检查出根本不需要被执行的SQL，也在这些和自己毫不相干的功能中频繁地执行着……同时，对数据流的检查还能够查出一些隐藏得较深的系统Bug，这个更需要基于DBA对业务细节的了解。
谁说DBA只会花钱？如果一个服务器I/O负载达到极限，大多数人只能选择扩容，最多重构部分功能来作些优化，而从statspack往往可以看出，系统的I/O资源多数是被一些并不该如此频繁执行的SQL给占用了，它们单次执行并不慢，但占用系统资源比例却异常高，这些问题，细化在每一个业务中，对这些问题的检查和数据流优化，就是对系统资源的最大节省，就是省钱！这个工作，或许只有DBA才能称职。
3、并发问题
大家都知道，该系统是由存在复杂的，但是当我们设计的系统，但也往往是按照思维单一的业务设计，编码方式，很少考虑同样的业务，同时操作可能出现不同的业务问题。通常情况下，系统不定时出现一些“奇怪”，“不可能”的错误，最有可能是并发惹的祸，但背后的问题，往往反映了锁定机制设计者不了解数据库和企业不能很好地结合起来。人们不理解数据库设计和DBA，不懂业务，这导致了很多问题本来是可以避免的。最经典的是汤姆Kytes援引酒店预订为例，当两个服务员在预订查找按钮被按下时，结果是两个人都订阅了同一个房间，这个问题是非常经典的，在目前看来很容易解决，不就是加锁呢？
然而，这只是一个例子，在你的系统的实际应用中，你赶紧去添加的更新，他们可能会导致其他问题！例如：死锁。在复杂的业务系统，僵局不难看出，这是一个设计缺陷的设计师，设计人员需要锁定表，以避免业务关系和规则的综合衡量。学习使用锁来保证数据的完整性是不够的，还要灵活的应用程序锁，适当使用乐观锁。维护如果对重要业务，所有的讨论，直接悲观锁是不可取的，系统会带来一些问题，甚至有些企业这样做会带来大的OLTP价格数据被锁定在高，严重影响了系统的并发性。有一个问题我也遇到了错误的数据，经过分析，有两种不同的业务并发性，但缺乏必要的锁，从而导致错误的数据。但是，基于业务的特殊性，锁定成本是昂贵的，仔细研究了DBA，确认锁也有可能是作者研究如何实现两全其美的乐观情绪的目的。从这里，完整性和并发系统运行状况和数据有时是矛盾的，但是有经验的DBA可以教你如何获得最佳的解决方案，当然，这是参与设计和DBA熟悉业务。
4、系统架构的问题
DBA不是系统架构师，但数据库的应用系统的核心部分，并且因为该数据库服务器不是可扩展的应用程序服务器，所以往往在整个系统的性能的瓶颈的位置，以便在所述的设计建筑师系统架构时，应充分考虑DBA的意见，DBA应该考虑SQL数据库性能调整和便利性甚至可行性！否则，很可能导致DBA和开发团队对系统性能的问题反应过慢，即使什么也不做！我看到了一个框架，它无法实现最常见的分页SQL的神谕！绑定变量根本就没有考虑这个！然后有一些第三方组件或架构，能够帮助我们的系统来生成SQL，这是非常容易的，当然，能够加快发展，但在这样的系统中，数据库管理员，如果你想优化SQL可困难的，因为开发商要修改一些工作量比较大的变化，费时，肯定更容易让工作带来新的错误！
Oracle大师汤姆Kytes也是经典出口一对一反对使用这些组件或自动生成架构的SQL，而这种事情很可能导致你的系统性能和维护上的问题！这些问题如咨询高级DBA，相信会尽快找到并获得该结构中的修理或调整。通过系统发育的后期，基础设施的问题一直难以进行调整的性质。如果你的系统需要非常高效，并发访问大，建议架构师倾向于尊敬DBA的意见，这对整个系统性能的不断调整将是非常重要的。 DBA的，该系统应具有结构的一些知识，并明确在自己的现有的基础设施所遇到的困难是。
二、 提高应用系统的性能、稳定性 除了DBA原本的DB调优、SQL调优、服务器维护等日常工作以外，扩展DBA的工作范畴，强化DBA在系统开发过程中的控制能力和决定权。 1、 让DBA参与到需求分析中去，并充分理解用户需求，从DB的角度来理解和考虑这些需求实现的成本。 2、 Schema的设计必须由DBA设计确定或者审核确定，这点也要求DBA必须了解业务系统，才能整理出正确的、有良好扩展性的E-R关系。 3、 让DBA更深入的参与系统的设计，尽可能地让DBA了解应用的业务设计细节，这对于DBA审核数据流是起到决定性作用的，如果有条件，业务的数据流应当作为系统的文档之一，以便将来的反复核查。 4、 在系统上线之前，由DBA审核sqltrace中的sql以及数据流逻辑，最好是能给出一些重要业务功能在DB成本（比如I/O）上的评估结果。 5、 系统上线后的性能监控，及时作出调整甚至一定范围内重构优化数据访问逻辑。 如上所述，则DBA的人力资源必然不足，因此，细化DBA的工作，进行分工是正确并且高效的，在一些公司，已经将DBA分为专管线上服务器的产品DBA和专管开发、参与系统设计的开发DBA，从不同方面全面保障系统的稳定和高效，值得借鉴！
三、 现阶段DBA对系统性能及稳定性所做的调整工作 
目前DBA对系统性能的调整工作大致是这么几个方面： 
1、 在硬件层面进行调优，这通常就是直接花钱，买设备、扩容。 
2、 在DB层面进行调优，比如调整初始化参数，调整数据库物理结构。 
3、 对应用的SQL进行优化，比如在数据库分析statspack，调整Top SQL。 
4、 只有非常少数的，通常是对系统稳定要求较高的一些公司的应用，才会在新的应用上线前，让DBA对sql进行充分的审核与评估。 
问题：在应用系统的分析、设计、开发阶段，就目前情况看，很少有DBA参与，而应用系统上线或者开发工作基本结束后，DBA所能做的调优工作其实是很有限的。 
总结：在现实中每个DBA的职业发展过程都有所不同，掌握更多的技术才可以设计开发出令人满意的系统的，有这方面学习需要的朋友可以参考本期的系统开发设计学习的全部内容，相关的视频教程可以登录课课家官网查询更多资料。