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

核心提示： 谁说DBA只会花钱?如果一个服务器I/O负载达到极限，大多数人只能选择扩容，DBA在系统设计、开发中的重要性(3)，最多重构部分功能来作些优化，而从statspack往往可以看出，但有经验的DBA能够教你如何获取最佳方案，当然，系统的I/O资源多数是被一些并不该如此频繁执行的SQL给占用了

谁说DBA只会花钱?如果一个服务器I/O负载达到极限，大多数人只能选择扩容，最多重构部分功能来作些优化，而从statspack往往可以看出，系统的I/O资源多数是被一些并不该如此频繁执行的SQL给占用了，它们单次执行并不慢，但占用系统资源比例却异常高，这些问题，细化在每一个业务中，对这些问题的检查和数据流优化，就是对系统资源的最大节省，就是省钱!这个工作，或许只有DBA才能称职。

并发问题

谁都知道系统有并发存在，可是我们在设计系统的时候，又往往是按照单一业务的思维模式来设计、编码，很少考虑同一业务、不同业务之间并发运作可能产生的问题。通常，系统无规律地出现一些“奇怪的”、“不可能的”错误，极有可能就是并发惹的祸，而背后的问题，往往体现了设计人员不了解数据库的锁机制，无法和业务很好地结合。设计的人不了解数据库，而DBA又不了解业务，这就导致了很多本来可以避免的问题产生。

最经典的就是Tom Kytes举的酒店预定的例子，当两个服务员同时按下查找预定房间的按钮，结果是两个人都预订到了同一间客房，这个问题很经典，在目前看来也很容易解决，不就是加上锁么?但是，这只是一个例子，在你实际应用的系统中，你这样贸然地加上for update，又可能导致别的问题!比如：死锁。在一个复杂的业务系统中，死锁不难见到，这个是设计者的设计漏洞，需要设计者全面衡量业务关系，然后对表的锁定制定规则来尽量避免的。学会使用锁来保证数据的完整性还是不够的，还要灵活应用锁，适当采用乐观锁定。

如果对于重要的业务，一律免谈，直接悲观锁定也是不可取的，会给系统的维护带来一些问题，某些业务这样做甚至会带来数据的大面积锁定时，在OLTP上的代价很高，严重影响系统并发能力。我曾经碰到一个错误数据的问题，分析后，确定是两个不同的业务间并发，同时缺少必要的锁定，而造成的错误数据。但基于该业务的特殊性，加锁的代价是昂贵的，在DBA的仔细追究下，确认了可以通过乐观锁定也即提交时检验的方式来达到两全其美的目的。从这里可以看出，数据的健康和完整性，与系统的并发能力有时是矛盾的，但有经验的DBA能够教你如何获取最佳方案，当然，前提是DBA参与设计并熟悉业务。