DBA在系统设计、开发中的重要性

    系统架构的问题
    DBA不是系统架构师，但数据库是一个应用系统核心的部分，同时，由于数据库服务器不像应用服务器那样便于扩展，因此往往也是整个系统性能的瓶颈所在，所以架构师在设计系统架构时，应该充分考虑DBA的意见，要考虑到DBA对数据库中的SQL进行性能调整的便利性甚至是可行性！

    否则就可能导致DBA及开发团队对系统的性能问题反应过慢甚至束手无策！我曾经见过一个架构，它无法实现oracle最普通的分页SQL！绑定变量就根本不在考虑中！再就是有些第三方组件或架构，能够帮助我们的系统生成SQL，这当然很省事，能够加快开发速度，可是在这样的系统中，DBA如果想要优化一条SQL可能很难，因为开发人员要修改的东西相对较多，修改的工作量大、耗时长，并且工作量多肯定就更容易带来新的错误!Oracle大师Tom Kytes也曾在经典著作Export one on one中反对使用这种自动产生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，从不同方面全面保障系统的稳定和高效，值得借鉴！

上一页  [1] [2] 

【责编:Peng】