性能问题应该从系统设计时期开始考虑，并延续到系统的生命期终止之时。

具有可伸缩性的系统是指当系统的负载增加一倍，系统需要的资源也同样增加一倍。说起来简单，但在现实环境中确难以做到。由于管理并发用户的开销的增长、锁事务的增长、一致性读负载的增加、操作系统负载的增加、低效的SQL或索引设计导致的过高的I/O等等因素，会导致系统资源的消耗的增长远大于一倍。

破坏可伸缩性的因素：

1.低效的应用程序设计、实施和配置

2.硬件部分的规模不合适

3.软件部分的限制

4.硬件部分的限制  

系统的结构可分为硬件和软件两部分：

硬件部分包括：CPU、内存、I/O子系统和网络模块。

软件部分包括：管理用户接口、实现商业逻辑、管理用户请求和资源分配、管理数据和事务。  

在设计系统时，应该考虑以下几个问题：

系统将支持多少用户？

用户的交互方式是什么？

用户所处的位置？

网络的速度怎样？

用户将访问多少数据？有多少数据是只读访问？

用户对响应时间的要求？

用户是否需要24小时服务？

是否所有的修改需要实时完成？  

应用程序设计原则：

设计简单性原则：

1.如果表的设计复杂到没有人能够完全的理解，那么表的设计可能是比较差的。

2.如果SQL语句过长以致于优化程序无法优化该语句，那么SQL语句的设计、事务和表的设计一定存在问题。

3.如果表的相同列上被重复索引，那么索引的设计可能是有问题的。

4.如果提交的查询没有限定，以致无法迅速的将结果返回给在线用户，那么用户接口或事务的设计是有问题的。

5.如果数据库的调用被许多层软件从应用逻辑中抽象出来，那么，软件开发的方法可能存在问题。

数据建模：应当注意，不要在非核心数据单元上花费过多的时间。

表和索引的设计：选择合适的列进行索引、选择索引类型、注意索引的代价、关注索引中列的顺序。

一个表上如果有3个索引，那么当进行INSERT/UPDATE/DELETE操作时，会比不带索引的表慢大约10倍。

组合索引中，选择性高的列在前查询时需要的I/O更少。选择性低的列在前，有助于代排序操作的查询。

SQL执行效率：

数据库连接管理：应避免没有必要的过多连接。

数据库游标管理：使用cursor和绑定变量，尽量避免硬分析，较少软分析。

硬分析：sql语句第一次提交，并在共享池中无法找到。

软分析：sql语句第一次提交，但是可以在共享池中找到相同的语句。  

实施新的应用程序：

切换方式包括两种：Big Bang Approach（所有用户一次性转移到新的系统上）和Trickle Approach（用户分多次转移到新的系统上）。

性能清单列表：

1.设置MAXINSTANCES, MAXDATAFILES，MAXLOGFILES，MAXLOGMEMBERS和 MAXLOGHISTORY的值高于预期值。避免系统的增长导致必须重建控制文件。

2.设置BLOCK SIZE和优化模式与开发环境中相同。如果测试环境中的所有SQL语句的执行计划都是正确的，可以测试环境中的统计信息导入到正式库中。

3.尽量少修改初始化参数。除了SGA的组成部分和归档目录的设置，其他初始化参数尽量保持默认值，可以为以后性能优化留下一定的余地。

4.通过设置数据库对象的存储参数来管理BLOCK的争用。

5.所有的sql语句应该被优化。

6.验证中间层软件和程序采用高效的方式连接数据库。

7.验证sql语句有效的利用游标。

8.确认所有方案的对象从开发环境移植到了产品数据库中。

9.一旦完成系统的切换，建立数据库和操作系统统计信息的基线。

10.发现最先出现的瓶颈。