Oracle认证：DBA在系统设计、开发中的重要性

会计考友 · 发表于 2012-8-4 13:41:06

　良多应用系统的机能或不变性并不理想，这在系统上线后不久就逐渐变为棘手的问题，造成这些问题的原因，往往浮现了一点：开发设计这些系统的人，对数据库自己不是很体味！而DBA又不体味营业！这就导致了良多原本可以避免的问题发生；另一方面，跟着数据库自我调整、打点的能力不竭增强，而应用又往往是系统机能最大的杀手，所以，DBA的工作规模，从只负责数据库处事器维护，慢慢走向打点应用系统的设计、开发，是必然的趋向！　　一、现阶段DBA对系统机能及不变性所做的调整工作
　　今朝DBA对系统机能的调整工作大致是这么几个方面：
　　1、在硬件层面进行调优，这凡是就是直接花钱，买设备、扩容。
　　2、在DB层面进行调优，好比调整初始化参数，调整数据库物理结构。
　　3、对应用的SQL进行优化，好比在数据库剖析statspack，调整Top SQL。
　　4、只有很是少数的，凡是是对系统不变要求较高的一些公司的应用，才会在新的应用上线前，让DBA对sql进行充实的审核与评估。
　　问题：在应用系统的剖析、设计、开发阶段，就今朝情形看，很少有DBA介入，而应用系统上线或者开发工作根基竣事后，DBA所能做的调优工作其实是很有限的。
　　二、良多应用系统的机能或不变性仍不理想
　　良多应用系统的机能并不理想，或者系统数据会呈现一些难以重现的奇异的错误，这些问题（尤其是机能问题）有时并不是在系统初期就会浮现出来，可是跟着系统的运行、数据的增多而慢慢变得难以解决，给系统后期的功能扩展和用户使用上带来了不少麻烦，造成这些问题的原因，往往浮现了一点：开发、设计这些系统的人不体味数据库！以基于Oracle的应用为例，简要举例声名：
　　底层数据结构不合理
　　因为贫窭专业DBA的协助，良多系统设计出来的底层数据库表结构问题重重。而做过系统的人都知道，底层数据库结构不合理，带来的刷新价钱之大几乎等于一次重构！我见过一个OLTP系统，其焦点表竟有100个字段，平均一标识表记标帜录跨越8K，如不美观按Oracle默认的8K一个Block，一半以上的行必需发生行链接！
　　而最糟糕的是，设计这样表结构的人还认为自己段实操作了冗余来降低表之间的毗连，事实上，其人根柢不晓得什么是范式、什么是更新异常，按照范式，这个表应该拆分为两个表的，但如不美观要改几乎所有的轨范都要改！虽然范式不是越高越好，但绝对是设计的人必需吃透的一个工具。在冗余上，相信大大都DBA都认为，级联更新的价钱长短常高的，是以冗余理当避免发生级联更新的情形，对于关系型数据库设计中冗余的使用，毫不是门很轻易把握的技巧。
　　不合理的底层数据库结构设计，给系统的机能埋下了重磅的按时炸弹，这个系统在客户那儿那里跑不到一年，数据量稍微上去些，机能、不变性就直线下降，而重构的成本又极高，买新处事器必定是只能治标。而假如底层数据表结构是资深DBA设计的又会若何？当然，如不美观完全让DBA去做数据库表结构的设计，DBA就必需很是清嚣张地体味整个系统的营业细节信息，这在DBA来说，人力资本上是有必然坚苦的，事实下场维护好线上处事器就已经占用了DBA良多的资本，而且率领们凡是更垂青这点。
　　很少有率领能熟悉到DBA在系统开发设计中所起到的浸染，和维护线上系统、措置DB故障对比，对折个系统的不变性和机能，是同样主要的！
　　SQL机能问题
　　系统的开发，凡是和DBA是没有什么关系的，可是，如不美观DBA对系统有足够的体味，这时辰也是可以做不少进献的。好比，搜检系统营业的数据流是否正确，这个需要经由过程一些手段，好比sqltrace、10046等，具体对系统的逻辑实现进行搜检，一方面查出系统中过于耗损资本的或编写不规范的SQL实时进行调整优化，另一方面，查出系统中不合理的数据库访谒，不要到了线上才发现问题，那时可能已经宕机了。简单举个例子，当一个页面需要多处显示商品的揽潭拘表时，轨范往往轻易犯一个错误，就是多次以同样的SQL篡夺出同样的数据，并应用于每一个列表显示上，如不美观你只篡夺一次，或者爽性在Web层进行cache（要有恰当的刷新策略），就可以大大削减单次访谒该页面在DB上的I/O耗损。有时甚至会搜检出根柢不需要被执行的SQL，也在这些和自己毫不相关的功能中频仍地执行着……同时，对数据流的搜检还能够查出一些潜匿得较深的系统Bug，这个更需要基于DBA对营业细节的体味。
　　谁说DBA只会花钱？如不美观一个处事器I/O负载达到极限，大大都人只能选择扩容，最多重构部门功能来作些优化，而从statspack往往可以看出，系统的I/O资本大都是被一些并不应如斯频仍执行的SQL给占用了，它们单次执行并不慢，但占用系统资本比例却异常高，这些问题，细化在每一个营业中，对这些问题的搜检和数据流优化，就是对系统资本的最大节约，就是省钱！这个工作，或许只有DBA才能称职。
　　并发问题

　　谁都知道系统有并发存在，可是我们在设计系统的时辰，又往往是按照单一营业的思维模式来设计、编码，很少考虑统一营业、分歧营业之间并发运作可能发生的问题。凡是，系统无纪律地呈现一些“奇异的”、“不成能的”错误，极有可能就是并发惹的祸，而背后的问题，往往浮现了设计人员不体味数据库的锁机制，无法和营业很好地连系。设计的人不体味数据库，而DBA又不体味营业，这就导致了良多原本可以避免的问题发生。

会计考友 · 发表于 2012-8-4 13:41:07

</p>　　最经典的就是Tom Kytes举的酒店预定的例子，当两个处事员同时按下查找预定房间的按钮，结不美观是两小我都预订到了统一间客房，这个问题很经典，在今朝看来也很轻易解决，不就是加上锁么？可是，这只是一个例子，在你现实应用的系统中，你这样贸然地加上for update，又可能导致此外问题！好比：死锁。在一个复杂的营业系统中，死锁不难见到，这个是设计者的设计裂痕，需要设计者周全权衡营业关系，然后对表的锁定拟定例则来尽量避免的。学会使用锁来保证数据的完整性仍是不够的，还要矫捷应用锁，恰当采用乐不美观锁定。
　　如不美观对于主要的营业，一律免谈，直接悲不美观锁定也是不采纳的，会给系统的维护带来一些问题，某些营业这样做甚至会带来数据的大面积锁按时，在OLTP上的价钱很高，严重影响系统并发能力。我曾经碰着一个错误数据的问题，剖析后，确定是两个分歧的营业间并发，同时贫窭需要的锁定，而造成的错误数据。但基于该营业的非凡性，加锁的价钱是昂贵的，在DBA的细心究查下，确认了可以经由过程乐不美观锁定也即提交时磨练的体例来达到兼顾其美的目的。从这里可以看出，数据的健康和完整性，与系统的并发能力有时是矛盾的，但有经验的DBA能够教你若何获取最佳方案，当然，前提是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，从分歧方面周全保障系统的不变和高效，值获救鉴！

		自动登录	找回密码
密码			立即注册

[其他] Oracle认证：DBA在系统设计、开发中的重要性

Oracle认证：DBA在系统设计、开发中的重要性