许多应用系统的性能或稳定性并不理想，这在系统上线后不久就逐渐变为棘手的问题，造成这些问题的原因，往往体现了一点：开发设计这些系统的人，对数据库本身不是很了解!而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都认为，级联更新的代价是非常高的，因此冗余应当避免发生级联更新的情况，对于关系型数据库设计中冗余的使用，绝不是门很容易掌握的技巧。