性能问题应该从系统设计时期开始考虑，并延续到系统的生命期终止之时。
具有可伸缩性的系统是指当系统的负载增加一倍，系统需要的资源也同样增加一倍。说起来简单，但在现实环境中确难以做到。由于管理并发用户的开销的增长、锁事务的增长、一致性读负载的增加、操作系统负载的增加、低效的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.发现最先出现的瓶颈。
