oracle的性能设计和开发

 

网上原文地址：http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/design.htm

Oracle® Database Performance Tuning Guide

10g Release 1 (10.1)
Part Number B10752-01

系统性能的设计和开发

好的系统性能始于设计，它贯穿于系统的整个生命周期。在系统设计的初始阶段，应该仔细地思考性能执行问题，那么在产品阶段，很容易对系统性能进行调优。

本文内容包含了以下部分

Oracle 方法论

理解投资选项

理解可扩展性

系统体系结构

应用设计原则

工作量测试，建模、执行

部署新的应用

Oracle 方法论

随着计算机系统越来越强大复杂，因特网在商业中的应用越来越广泛，系统的性能开始日益重要。为了适应变化，基于多年的设计和性能经验，oracle创作了性能方法论。这个方法论简明，易懂，可以有效地改善系统的性能。

性能策略随效力不同而改变，用途不同，系统的性能技巧也不同，如操作系统和决策支持系统，两者的性能就有差异。本书详细地探讨了所有数据库设计者、管理者和性能专家都非常重视的性能事项。

系统性能被设计和植入到系统中，并不会立马见效。性能问题通常是资源争用或者是耗尽的结果。当一个系统资源已经耗尽，系统是不可能用高水准的性能来衡量。这些新的性能方法论基于谨慎地计划和数据库设计，能阻止系统资源耗尽，防止宕机。通过消除资源争用，系统可扩展到业务要求的水准。

理解投资选项

伴随着相对便宜又强大的处理器、内存和磁盘驱动的出现，人们企图购买更多的系统资源来提升性能。在很多情形下，新的CPUs、内存、更多的磁盘确实能够立即提升性能，然而通过增加硬件来提升性能，一直被认为只能暂时解决突发问题。假如应用程序查询量和加载速度持续增大时，增加硬件可以立刻减小，但不久你又将面临同样的性能问题。

在其它情形下，增加硬件根本不能提升系统的性能。差的系统设计不管你怎么增加硬件的分配都是徒劳的。增加硬件之前，应该确定应用系统里没有连接的或单一的线程。从长期来看，

在业务事务中增加物理资源量，通常能使你的应用程序的效力增加更加有价值。

理解可扩展性

可扩展性这个词在开发环境的许多上下文中使用。在这一节里，可扩展性解释为应用软件的设计师和性能专家的性能预期目标。

什么是可扩展性

可扩展性是指随着系统资源使用比例的增加，系统处理高工作量的能力。换句话说，在一个可扩展的系统中，假如你成倍地增加工作量，那么系统将两次使用系统资源。显而易见，由于系统内耗，资源使用可能超过两次原始的工作量。

资源争用造成可扩展性差的情况包括以下几点：

应用软件要求当用户数量增加时能满足相当数量的并发的管理。

增加堵塞的行为

增加数据一致性的工作量

增加运行的系统工作量

事务要求增加大量的数据存取

效率低下的SQL和索引设计，导致通过更多次数的逻辑I/O来获取相同数据的行数。

减少可用性，因为数据库对象要用很长的维护时间。

一个不可扩展的应用软件，是指当系统工作量增加，没有更多的吞吐量，系统资源就会耗尽。这样的应用软件会导致系统吞吐量用尽而长时间没有响应。

资源耗尽的样例有以下几点：

硬件耗尽

在超大量的事务中执行表扫描必然导致磁盘I/O不足

过多的网络请求，导致网络和时序瓶颈

内存分配导致内存分页和交换

过多的处理和线程分配导致操作系统沉重

这意味着设计应用软件必须建立共享资源，忽略用户数量和数据体积，在受限制时不再加载系统资源。

系统的可扩展性

通过因特网访问的应用软件，具有更复杂的性能和可行性要求。一些应用软件仅为因特网设计和开发，需要大部分甚至全部的在线数据，典型的后台办公应用软件除外，如总帐应用软件。

因特网时代应用软件特征包括以下几点：

每天24小时、每年365天都可用

不可预知的和不确定的并发用户

容量计划编制难

支持所有查询类型

多层框架

无状态中间件

快速的开发时间表

最小限度的时间测试

应用软件必须在测量出工作量增加的同时增加附加硬件来应对增长的需求。设计错误会导致执行时间达到最高值、附加硬件资源失效甚至重新设计。

应用软件开发很具挑战性，因为它的开发时间短，测试时间和评估时间也都有限。可是，糟糕的设计通常意味着，在将来的某个时间点，系统需要重新构建和重新实现。假如已知构建和实现的应用软件局限于因特网部署上，并且工作量超过预期的要求，那么设计将可能会失败。从商业观点来看，糟糕的性能等同于失去客户。假如网络用户在7 秒以内没有获得响应，那么可能会永远失去用户的关注。

在很多情况下，重新设计的成本加上重新实现引起的停工期的成本，往往都会超过合理设计原始系统所需的成本。由此可以看出，设计理念很简单：要使设计和实现具有可扩展性，就应该从开始做起。

可扩展性的预防因素

当开发应用软件时，设计和构架应该尽可能具有接近完美的可扩展性。这通常被称为线性可扩展性，即系统的吞吐量占CPUs 的比例呈直线上升。

在现实中，线性可扩展性因一些原因不可能在设计师的控件中，可是，应用软件设计和实现却又要尽可能做到可扩展性，以确保当前性能目标和将来性能目标能通过扩展硬件组件和CPU的升级技术来达成。

线性可扩展性的预防因素

1 糟糕的应用软件的设计、执行和配置

应用软件有最大的性能冲击。比如：

糟糕的计划设计能导致昂贵的SQL不可扩展。

糟糕的事务设计能导致死锁和一系列的问题的产生。

糟糕的连接管理能导致糟糕的响应时间和不可靠的系统。

可是，设计并不是唯一的问题，应用软件的物理执行设备会产生微弱的链接。比如：

系统平台糟糕的I/O策略影响软件产品环境

产品环境使用的执行计划比测试生成多。

内存密集型应用软件，分配了大量的内存，并没有考虑在运行时释放内存，导致额外的内存使用。

低效率的内存使用和内存泄漏给操作虚拟内存子系统带来很强的压力，从而影响性能和可行性。

2 错误的硬件组合排列

在相关硬件价格减少时，糟糕的硬件组合容量计划带来的问题会减少。可是，当工作量在系统中增加时，太多的容量会产生可扩展性问题。

3 软件组件的局限性

所有的软件组件都有可扩展性和资源使用的限制，它们在软件服务，数据库服务和操作系统中应用。应用软件设计，不应超越它可以处理的软件的要求。

4 硬件组件的局限性

硬件的升级并不是那么完美。大多数多处理器机器，可以得到接近线性比例的CPUs数量有限，但在某个点之后，每增加一个CPU就能提高整体性能，并不是成比例地提高。有时当增加额外的CPU时并不能增加性能，反而甚至使性能降级。这些行为非常地接近链接工作量和操作系统设置。

注意：这些因素是基于orcale服务器性能组的调整不可扩展系统的经验。

系统体系结构

系统体系结构的主要两部分：

硬件组件和软件组件

为需求配置对的系统结构

硬件组件和软件组件

这部分讨论硬件组件和软件组件

硬件组件

当今，设计师和架构师的责任是为复合环境中每个阵列的硬件制订大小和容量。架构师的责任是达到平衡设计。这类似于桥的设计师，他必须考虑桥的所有的有效载荷和结构要求。每座桥都是由最小的组件叠加而成的坚固桥。因此，一座桥的平衡设计体现在桥的所有组件同时达到其设计限制。

主要的硬件组件如下：

CPU

内存

I/O子系统

网络

CPU

CPU可以有一个或者多个，在简单的手持设备与高性能的服务器中，它们的CPU的处理能力不同。其它硬件组件的分级通常是多CPUs 的系统。参考第 9 章“理解操作系统资源”。

内存

数据库和应用软件服务器需要大量的内存来缓存数据，以避免访问磁盘而耗时。参考第7章“内存配置和使用”。

I/O子系统

I/O子系统是改变介于客户机硬盘和高性能磁盘阵列之间的协作。磁盘阵列每秒能执行I/O上千次，并通过冗余提供多个I/O路径和热插拔镜像磁盘。参考第8章“I/O配置和设计”。

网络

在一个系统中所有的计算机都是通过网络连接的，从调制解调器到高速国内局域网。网络规范主要涉及的是带宽和网速。参考第 11 章“网络调整”。

软件组件

计算机有共同的硬件组件，同样地，软件有共同的功能组件。通过区分软件开发和功能组件，能更好的领会应用软件设计和架构。系统的某些组件可以由现有的软件来加速应用程序的执行，或者避免重新开发通用组件。

软件组件与硬件组件的区别在于，硬件组件只执行一个任务，而一款软件能执行软件组件中的多种角色。例如：一个磁盘驱动器只存储和回收数据，但是一个客户程序能管理用户界面和执行业务逻辑。

大多数应用软件包括下列组件：

管理用户界面

实现业务逻辑

管理用户请求和资源分配

管理数据和事务

管理用户界面

这个组件是应用软件用户可见的，包括下面的功能：

在用户面前描绘屏幕

收集用户数据并把用户数据转换成业务逻辑

验证输入数据的有效性

导航应用软件的等级和状态

实现业务逻辑

这个组件是执行核心业务规则，是应用软件功能的中心。它产生错误时所需的维护成本很高，它是通过声明和过程的混合方案来执行的。一个声明的例子是定义主键和外键。实现折扣策略是一个基于过程的例子。

这个组件的通用功能包括如下：

把数据模型移到关系表结构

定义关系表结构的约束

编写过程逻辑和业务规则

管理用户请求和资源分配

这个组件是任何一款软件都要实现的。可是有一些请求和资源不能被应用软件感应和获取。

在一个多用户应用软件中，大部分资源是通过用户请求，操作数据库服务或者操作系统分配。可是，在一个大的应用软件中，用户的数量和使用方式是未知的或者增长速度特快，系统架构师必须积极主动，确保没有一个单独的软件组件超载和不稳定。

通用功能的组件包括如下：

连接管理数据

有效地执行SQL（游标和SQL共享）

管理客户状态信息

均衡加载用户请求的硬件资源

为硬件或软件设置操作的对象

持久化异步执行任务

管理数据和事务

这个组件是数据库和操作系统的主要的责任

通用功能的组件包括如下：

提供并发存取数据时使用锁和事务语义

提供最优化的存取数据使用索引和内存缓存

保证在发生硬件故障事件时，记录数据的变化

为了数据定义一些强制规则

为你的请求配置正确的系统架构

配置初始化系统架构是一个主要的迭代过程。在预计约束和进度表约束下，架构必须满足系统的要求。假如系统要求交互式用户处理业务并基于数据库的数据作决策，那么用户需求驱动架构。如果系统中只有少量的交互式用户，那么架构是过程驱动。

用户交互应用软件的例子：

会计和帐务类应用软件

订单输入系统

Email 服务

基于 web 的零售应用软件

贸易系统

过程驱动应用软件的例子：

效用账单系统

欺诈检测系统

直邮

在许多方面，由于用户交互界面已被淘汰，过程驱动应用软件比多用户应用软件更容易设计。

可是，因为对象是面向过程，架构通常不是处理大量数据，这样，不同成功的因素会变得混乱。过程驱动应用软件的设计借鉴了用户基本应用软件和数据仓库中使用的技能。因此，本书就交互用户的系统架构展开讨论。

注意：

系统架构的生成是一个不确定性的过程，需要认真考虑业务需求、技术选择、已存在的基础结构和系统、现行的物理资源，比如预算和人力。

下面的问题能激发对架构的思考，尽管它们不是明确的系统架构指南。这些问题表明了业务需求怎样影响架构，便于实施和提高系统的整体性能和可用性。比如：

系统支持多少用户？

大多数应用软件分为以下几种类别：

用户专用型

这类应用软件，通常只有一个用户，设计重点集中在，为单一的用户提供尽可能快的响应时间，使管理需求最少。这类应用软件的用户很少受其它用户的打扰，并具有最小的资源冲突。

公司用户共享型

这类应用软件，用户局限于一个公司内部人员的数量，实际只处理一个公司的业务。因此用户的数量是预知的。可是,交付一个可信赖的服务器是业务关键所在。用户使用共享资源，因此设计的重点是在系统繁忙负载时解决响应时间，为每个会话增加资源和为用户的增长预留空间。

无限因特网用户型

这类应用软件，需要工程师付出额外的努力确保所有的系统组件都不超出设计范围。因为这会导致瓶颈，使系统宕机，变得不稳定。这类应用软件要求复杂的负载匀衡，无状态应用服务，和高效的数据库连接管理。此外，统计类和政府类应用软件要确保用户在系统过载时，仍能得到反馈。

用户交互的方式是什么？

用户选择的界面从简单的Web浏览到自定义客户端程序。

用户查找的地点在哪里？

用户之间的距离，影响应用软件怎样处理网络的等待时间。位置也影响一天之中网络的高峰期，那时尽量不处理批量执行任务和对系统进行维护。

网络的速度是多少？

网速既会影响数据量，又会影响应用软件的用户界面与数据库服务器之间的会话。一个高级别的用户会话界面能与后端服务器沟通，低级别的用户会话界面工作模式是在屏幕上发送和接收。缓慢的网速，是不可能用高级别的用户会话界面获取好的数据输入速度。

用户存取的数据有多少？批量只读数据是多少？

数据量的在线查询影响设计的方方面面，从表和索引的设计到表达层。设计的效果必须确保用户的响应时间不是数据库容量的功能。假如应用软件主要是只读的，复制和分配数据到应用服务器缓存中是一个可行的方案。这也减少了核心服务器的工作量。

用户响应时间的需求是什么？

考虑用户的类型是很重要的。假如用户是一个执行者，他要求正确的信息来做二次决策，用户的响应时间是不是妥协的。其它类型的用户，比如进行数据录入活动的用户，就不需要高级别的性能。

用户是24小时在线吗？

这是用户托管类型的因特网应用软件，可以一天24小时都进行交易。可是整个系统运行在一个单独的时间区域，这需要忍受盘后停工期。这些盘后停工期通常是批量处理或系统管理员执行。在这种情况下，在不是完全可用的系统中是经济的。

所有的改变都必须是实时的吗？

重要的是确定交易在用户的响应时间之内是否需要处理，或者是确定交易是否能异步队列执行。

下面是次要问题，也能影响设计，但是对预算和执行有更大的冲击，如：

数据有多大？

它将影响数据库服务的型号，一个很大的数据库的系统，必须有一个更大的机器来指令工作量。这是因为数据库管理是大容量数据库的主要的功能。当表和索引增长时，它需要有更多合适的 CPU 来支持表的认证和索引的创建，这个工作必须在用户能够接受的时间内完成。

业务交易的吞吐量的需求是什么？

实用性的需求是什么？

存在创建应用软件和管理应用软件的技术问题吗？

被预算限制时，折衷的方案是什么？

应用设计原则

这部分讲述在开发应用软件中的设计原则

简单的应用软件设计

应用软件与其它的设计产品和工程产品没有区别。好的设计结构，机器和工具是可信赖的，使用和维护简单，概念也简单。在大多数普通的条件下，假如设计看起来是正确的，那么它很可能是正确的。在开发应用软件时，这一原则要牢记在心上。

思考一些下面的设计结果：

如果表的设计是很复杂以致于没人能完全理解它，那么表的设计是很糟糕的。

如果SQL语句很长，并且它不可能实时调优，那么它是糟糕的语句，是不好理解的事务，或者是糟糕的表设计。

如果表和相同的列的索引再三地编入索引，那么它是糟糕的索引。

如果请求没有在限制的时间内提交而快速的响应在线用户，那么它是糟糕的用户界面或者是糟糕的事务设计。

如果访问数据库是从软件很多层的应用逻辑中抽象的，那么它是一个糟糕的软件开发方法。

数据模型

数据模型在成功的关系应用设计中是很重要的,它必须用一种方法快速地描述实际业务。关于正确的数据模型有一个激烈争论,最重要的事是努力把最大的模型运用到受到大多数常见业务交易影响的实体中。在模型的语法中，有一个很大的误区就是花费很多的时间构建非核心的数据元素，从而增加了开发时间。使用建模工具能够快速的生成图表定义,在需要快速原型时,使用建模工具也是非常有用的。

表和索引设计

表设计在很大程度上是一个核心交易的灵活性和性能间的妥协。为了保持数据库的灵活,为了能够供给无法预知的工作量，表的设计必须与数据模型很相似，必须至少满足第 3 范式。可是,用户需要的核心事务要求高效的查询性能，这点与范式相矛盾。

这个技术的例子包括表的预先加载，附加的派生列，集合值。Oracle通过聚集和物化功能为存储集合和预先加载的数据提供许多的选项。这些特征允许像一个简单的表设计一样初始化。

索引设计也是一个大量地迭代过程，基于应用软件设计者生成的SQL。可是，在已知的存取模式上执行主键索引约束和建立索引,有可能是一个明智的开始，犹如一个人的名字。随着应用软件的发展和实际数据量测试的执行，某些查询要求改进性能，这时,创建一个更好的索引是一个很好的解决方法。 创建一个新的索引时，应该要考虑下面列表中索引的设计思想。

追加列索引或使用索引组织表

使用不同的索引类型

查找索引的成本

序列内索引

在索引中排序列

追加列索引或使用索引组织表

加快查询的最简单的方法之一是通过除去执行计划中表的访问，来减少逻辑 I/O 的次数,这可以通过为查询所引用的所有列附加索引来实现。这些列是选择列表中的列和任何需要加入或排序的列。这项技术对提升在线应用软件的响应时间特别有效，因为耗时的 I/O 减少了,当第一次测试应用软件的适当的数据量时,这项技术也是最实用的。

最具挑战性技术是建立索引组织表（IOT），可是你必须小心在增加IOT叶子节点的容量时别破坏减少 I/O 地效果。

使用不同的索引类型

这里有几种常用的索引类型，每种索引在特定的场景都有各自的长处。下面的清单是索引的性能介绍。

B-Tree 索引

这是标准的索引类型，它对主键和高选择性的索引的效果最好。用作连接索引，B-Tree索引被用于获取使用索引列排序后的数据。

Bitmap索引

它适用于低基数数据，通过压缩技术，它们能够用最少的I/O生成大量的 rowid 。非查询的列上的组合Btimap列 也能采用这个方法来高效的操作 And 和 Or 关键字。Bitmap索引对count()特别有效，因为这个查询适用于索引的使用场景。

函数索引

这种索引允许通过一个B-tree的基础数据的函数的值存取。函数的索引对 null值是有一定的局限性，它们要求你激活查询最优化。

函数索引对查询一个产生派生结果的复合列是非常有用的。 或者克服以数据的方式存储在数据库中的局限性。典型的例子是：使用UPPER 函数进行忽略大小写查询。

分区索引

分区全局索引允许对一个索引存取进行分区，其结果是减少 I/O 次数。通过定义好的散列分区，快速扫描正确的索引分区能产生非常快的查询时间。

反键索引

这种索引提升了插入应用程序的性能，但是它不能用于索引范围扫描。

查找索引的成本

创建和维护索引结构的代价很高昂，它会消耗资源，比如磁盘空间、CPU和I/O容量。设计者必须确保索引的利要大于维护索引的弊。

使用简单的评估手册来说明索引维护的成本：每个索引通过 insert、delete、update 维护索引关键字等价于实际DML操作表三次所需的资源。假如你在一张有三个索引的表插入一条记录，比没有索引的表大约慢 10 倍。对于DML特别是需要大批量插入的应用程序，索引的设计应该非常谨慎，要作查询与插入的性能平衡。

索引内序列

使用序列或者时间戳生成关键值，它们检索自身都会导致数据库的热点问题，它们影响响应时间和吞吐量。单向增长主键能导致索引一直往右增长。为了避免这个问题，尝试生成整个全范围内的索引。这产生了一个可升级的和有效率的空间的良好平衡索引。你可以通过使用反键索引或使用一个可以循环的序列前辍和序列值来完成。

排序索引列

设计师应该灵活地制定索引的创建规则。依赖你的环境，使用下列两种方法中的一种，来对索引列排序：

1.      把频繁查询的列放在前面。 这个方法， 在大部分时候都适用。 因为它能够使最小的I/O（访问真是的rowid）提供最快的访问速度。这个技术主要用在主键和大量的扫描查询。

2.      通过clustering 和排序，减少I/O。 在大范围的扫描时，通常通过对查询的列排序来减少I/O，或者在管理有顺序的数据时必须重新排序。

使用视图

视图能加速和简单化应用软件设计。一个简单的视图定义能掩饰复杂程序的数据模型，按优化级回收、显示、收集、存储数据。

可是，当视图提供清晰的程序接口时，他们能导致次优，资源密集型的查询。最坏的一种视图是，一个视图引用其它视图做连接查询。在很多情况下，开发者满意直接查询表里的数据，而不是使用视图。通常是因为视图继承了表的属性，视图很难对其调优，生成最优的执行计划。

SQL执行效率

在系统开发的设计和架构阶段，应该确保应用软件开发者能够理解 SQL 的执行效率。为了达成这一目标，开发环境必须支持下面罗列的特征。

好的数据库连接管理

连接数据库是非常昂贵的操作。因此，同时连接数据库的连接应该尽可能的少。一个简单的系统，一个用户连接数据库，在应用软件初始化时是一个好主意。可是，在一个基于Web或者多层的应用软件中，应用服务器很困难为用户提供多元的数据库连接。在这种类型的应用软件中，设计的重点应该确保数据库连接是一个池，且不为每个用户请求创建新的连接。

好的游标的使用和管理

在系统中，维护用户的连接与最小的解析活动是同等重要的。解析是解释一个 SQL 语句和生成SQL的执行计划的过程。这个过程有很多阶段，包括语法检查，安全检查，执行计划生成，在共享池中加载共享结构。有两个阶段的操作：

硬解析：一条 SQL 语句在第一次提交时，在共享池中没有匹配到已解析好的SQL。硬解析是最耗资源和不可扩展的，因为它执行了解析中的所有操作。

软解析：一条 SQL 语句在第一次提交时，在共享池中匹配到已解析好的SQL，那个匹配到的解析可能是别的用户的前一个执行的结果。这个SQL语句共享了，对性能的提高是有益的。可是，软解析并不是一个好的想法，因为它仍然要求做语法和安全的检查，这部分会消耗系统资源。

因为尽可能少的解析SQL语句，应用软件开发者应该设计他们的应用软件只解析一次SQL并能重复执行很多次。要这样做必须通过游标，SQL程序的经验与游标的打开并重复执行的概念相类似。

应用软件开发者必须确保SQL语句能够在共享池中共享。为了做到这点，在执行时，用绑定变量的方法替换可变部分。如果不这样做的话，SQL语句几孚是解析一次就不被其它的用户重用。为了确保SQL语句能够共享，在SQL语句中使用绑定变量的方法代替字符串拼接。例如：

字条串拼接：

SELECT * FROM employees WHERE last_name LIKE ‘KING’;

绑定变更：

SELECT * FROM employees WHERE last_name LIKE :1 ;

下面的例子是在联机事务处理系统（OLTP）应用程序的测试结果：

测试                            用户支持数

没有解析所有SQL语句           270

软解析所有SQL语句             150

硬解析所有SQL语句             60

为每个事务重新连接数据          30

这份测试单是在 4-CPU的机器上执行的，不同之处是在系统中增量了CPU的数量，请看“第12章 SQL调优概述”关于SQL语句优化的信息。

应用软件的实现

开发环境和编程语言的选择很大程度上由指定应用软件开发的开发团队的技能和架构决定的。可是，一些简单的性能管理规则能产生可升级的，高性能的应用软件。

1.       选择合适的软件开发环境，不让开发环境限制你在性能决策上的设计。假如不这样做，你可能会选择错误的语言和环境。

用户界面

编程的模式就在HTML生成和直接调用windows系统界面之间选择，开发的方法应该以用户界面代码的响应时间为焦点。如果HTML或Java是通过网络发送的，则尽量减少网络卷和交互。

业务逻辑

编程语言比如Java和PL/SQL是编写业务逻辑的好语言。他们是完全可移植的，这使得很容易升级业务逻辑。两种语言的语句构成上都很丰富，编写出来的代码可读性强。如果业务逻辑要求复杂的数学功能，那么需要编译成二进制的语言。业务逻辑的代码可能放在客户端和应用服务器端和数据库服务上。可是，业务逻辑的代码通常是放置在应用服务器上。

用户请求和资源分配

大多数用户请求和资源分配对编程语言没有影响，但是工具和第四代生成语言使用低效率的机制来掩饰数据库连接和游标的管理。在评估这些工具和环境时，应检查数据连接模式和游标的使用和绑定变量。

数据管理和事务

大多数数据管理和事务对编程语言没有影响

2． 在实现软件的组件时，要实现它的功能和与其它组件关联关系的功能，在实现与其它组件的功能时，可能导致次优的设计和实现。这适用于所有组件。

3. 别留下功能的缺陷和有软件组件在设计、实现或者测试时研究不足。在很多情况下，缺陷是不容易发现的，直到应用软件推出和现实的数据量中测试时才出现。这通常是差的架构和系统初始化规范的标志。数据存档/清除模式是系统最初的设计、生成、实现的瓶颈。

4．实现程序逻辑常用的语言有C，Java，PL/SQL。实现数据存取或数据改变（DML）通常使用SQL。这些规则说明业务逻辑编码模块中混合了一些数据存取的编写。把程序逻辑放到SQL中存取是一个很大的诱惑。这种趋向导致糟糕的大量占用资源的SQL语句产生。SQL语句用DECODE CASE 语句来优化它。当语句中有很多 OR 或者设置操作时，使用比如UNION和MINUS优化。

5. 缓存经常用于存取很少改变的数据，重复回收这些基础数据是很耗性能的。缓存机制很容易使用，确保比原始的方法存取数据更不耗性能。它适用于所有的把数据值缓存或存储在本地的模块，而不是重复从远程或昂贵数据存储中检索。

大多数普通的本地缓存的例子包括如下：

今天的日期，SELECT SYSDATE FROM DUAL 占数据库工作量的 60% 以上。

当前用户名

重复的程序变量和常量，比如税率，折扣率或本地的信息。

本地缓存数据能够进一步扩展建立应用服务器的中间层缓存本地数据。这将有助于减轻中央数据服务器的压力。可是，要小心在构建本地缓存时不宜太复杂，否则会导致本地缓存出现性能问题。

本地生成序列。

使用缓存应考虑隐藏其中的设计问题。比如，假如一个用户在午夜访问，当前日期是缓存的，那么日期的值将自动失效。

6. 优化组件之间的接口，确保所有的组件都在可扩展的配置中使用。这个规则要求最少的解释和应用于所有的模块和他们的接口。

7. 使用外键引用。通过应用程序强制引用的完整性是很贵的。你可以通过从主表中查询一个子表的值，确保它在子表中存在，使用这种方法维护外键的引用关系。外键约束是oracle提供的，它不是使用SQL实现，是快速的易声明的和不会产生网络流量的方法。

8．考虑创建动作和模块名称在应用程序中使用终端到终端的程序追踪。它在追踪工作量问题时变得更有弹性。请参考“终端到终端的程序追踪”

应用软件的发展趋势

当今应用软件的发展有两个挑战，使用Java语言代替C语言或C++语言，和使用面向对象技术，它们影响Schema的设计。

Java提供更好的可植性和和编程的实用性。可是，有一些性能影响关联着Java。因为Java是解释语言，它执行同样的逻辑比汇编语言比如C要慢。结果，客户端机器资源的使用增加了。这就要求客户端或者中间层有运行更快的CPU，和程序员要加倍小心地编写高效的代码。

因为Java是一门面向对象的语言，它鼓励把不执行业务逻辑的数据访问的类抽取出来。结果是程序员在调用方法时，不用知道数据库存取效率的知识。这种趋向的结果是数据库存取是最少的，使用最简单的，操作数据的接口是最原始的。

采用这种类型的软件设计，需求不用总是包括所有的WHERE查询的效率，行过滤是Java程序执行的。这是非常高效的。对于DML操作语言，特别是INSERT语句，执行一条INSERT语句尽可能使用数据接口。在某些情况下，使用存储过程的效率更高。在移动数据时，操作数据库比现行的数据库调用使用的资源更多。

通常，最佳的数据库存取调用层紧邻业务逻辑层是最好的全面的事务设计。

受面向对象编程思想的影响，在Oracle服务的内部产生了面象对象的数据库。这表现在许多方面，从存储在BLOB的对象结构和只使用有效的数据库索引卡文件到Oracle对象关系特征的使用。

假如你采用面向对象的方案来设计Schema，那么你要确保不丢失关系存储模型的弹性。在许多情况下，面向对象方案来设计Schema 结束了非规范化的数据结构和要求考虑维护和REF指针与对象的关联。通常，这些设计代表了落后一步的层次和网络数据库设计终将被关系型数据库取代。

总结一下，假如你打算把数据长期的存储在数据库中，你期望一定程度的即时查询或者在同一个Schema上开发应用软件，那么你将会发现关系存储的方法会带来最好的性能和弹性。

测试工作量，模型，和实现

这部分讲述工作量的估算，模型，实现和测试。

数据量

你可能有过使用一个简单的例子去估算可变长度的数据的错误经历。同样，随着数据量的增长，你还要考虑主键的长度，改变你的假定的列的长度。

系统难以预知数据库的增长，尤其是索引。表随着时间的过去越来越多，索引受主键生成，插入的样式和删除多行数据的影响。最糟糕的情况是，你使用升序主键插入数据和在左边删除部分数据时，这会留下缺陷和浪费空间。假如你像这样使用索引，就应确保你知道使用在线索引重新生成工具。

大多数优秀的DBA会监视每个对象的空间分配和找出不受控件制的增长的对象。一个好理解的应用软件是能够高亮显示增长过快和非预期增长的对象。这对任何系统的性能和实用性计划是至关紧要的。在实现一个产品数据库时，设计师应该尝试在交互用户使用应用软件时确保最小的空间分配，这适用于所有的数据、临时表空间和回滚段。

估算工作量

为容量计划和测试目的估算工作量经常被当作魔法来描述。在考虑各种各样的情况时，很容易看出为什么这个过程在很大程度上是不可能得到正确的改正。可是，设计师需要指定机器的CPU，内存和磁盘驱动，并最终推出应用软件。这里有一些估算工作量的技术，每个技术都有它的长处。在估算中，最好是使用至少两个方法来验证你的决策过程和提供的支持文档。

从一个相似的系统来推断

把一个已经存在相似的特征和已知性能的系统用来作为参照评估的基本的系统，这完全是经验主义的方案。这个系统的详述是专家依照已知的差异来评估工作量的大小。这个方案的价值在于它是以一个已经存在的系统作评估的参照标准，但是当处理情况不同时它提供的帮助是很小的。

这个方案通常用于评估几乎是所有的大型的工程学科在准备工程项目的价值，比如一个大型的施工：一条船，一坐桥或者是石油钻塔。假如引用的系统与准备的预期的系统在工作量上存在巨大的差异，那么系统中的一些组件将超过设计的限制。

基准法

基准过程是资源和时间两者的消耗，它可能无法得到正确的结果。以接近开发环境或原型中模拟一个基准，它存在实际的产品系统中不可能有类同之处的风险。这听起来很奇怪，但是以数据库开发组织的基准客户的多年的经验来看，我们已经看到了基准应用软件和实际产品系统之间的良好关系。这是减少在开发过程中的无效的应用程序的方法。

可是，基准法在相似水准的系统中应用很成功。 特别是，基准法很合适用来确定实际 I/O 的请求和测试系统满负荷的恢复过程。

基准法是通过系统所有组件的压力来检测极限。在基准环境中，所有的组件在压力下，我们可以看到软件设计和实现的所有错误。基准法也用于数据库、操作系统、硬件组件的测试。因为大部分基准是在高峰期执行，将产生预期的挫折和系统组件失败时的问题。基准是一个动态的压力测试，它带来一些在基准之外的经验的思考。

应用模型

应用建模能够从复杂的数学模型经验延伸到在一个信封的背面执行典型的简单计算。两种方法都有价值，使用其中一种方法来尝试达到很高的精确度，另一种方法产生毛重估算。这两种方法都不请允许出现错误和无效率的实现。

评估和度量的过程是一个不严密的科学。可是，通过调查的过程，一些智能的评估由此产生。在整个评估的过程中，不允许糟糕的SQL书写、糟糕的索引设计、糟糕的游标管理引起应用程序无效率的问题。一个优秀的度量工程师为应用程序的无效性构建范围，一个优秀的性能认证工程师善于发现效率低的地方,使得评估更贴近现实。在 Oracle 性能方法中描述了发现应用软件的无效性的过程。

测试，调试和验证设计

测试的过程由功能性和稳定性测试组成。在这些过程中的某些时间点中，做性能测试是必须的。

下面是软件的一些简单的性能测试规则。假如记录正确，它将为产品的应用和软件已经使用之后的容量计划的过程提供重要的信息。

使用数据库自动诊断监视工具（ADDM）和SQL优化建议工具（STA）。

在实际的数据量和数据分布中测试。

所有测试必须在包含数据库中所有的表的环境中进行。测试的数据库应该包含产品系统中的有代表性的数据量和表之间的基数。

使用正确的优化器

所有测试应该在产品将会使用的优化器中进行。所有Oracle搜索和开发努力的焦点是升级查询优化器，因此 Oracle官方推荐使用查询优化器。

测试单一用户的性能

在空闲和轻负荷的系统，使用一个单一的用户来测试可接受的性能。假如一个单一的用户在理想的条件下，不能得到可接受的性能，那么在多用户共享资源的条件下是不可能得良好的性能。

获取并记录所有SQL语句的执行计划

为每一条SQL获取一个执行计划，因为一些指标应该有至少一个语句的执行计划。这个过程是用来验证一个好的执行计划是通过优化器生成的和相关SQL语句在CPU组合的响应时间和物理I/O次数所花费的成本。这个过程有助于标识繁重的事务，这个事务将来需要更多的性能调优。请参考第18章“使用计划的稳定性”的计划稳定性的信息。

尝试多用户测试

这个过程很难精确地执行，因为用户的工作量和配置不可能完全相同。可是，事务执行DML语句时可用来测试确保程序没有死锁和序列化问题。

用正确的硬件配置来测试

在尽可能的接近产品系统的配置环境中测试是很重要的。这对遵守网络的等待时间，子系统的I/O带宽和处理器的类型和速度特别重要。如果这个测试失败了，可能导致一个有潜在的性能问题的错误的分析报告。

测量稳定状态时的性能

当基准建立时，在稳定状态条件下，测量性能是很重要的。每个基准的运行应该有一个加速的阶段，用户创建与程序建立连接，开始渐渐地在程序中执行工作。这个过程经常允许把数据初始化到缓存中和执行单一的操作，比如解析，在稳定状态条件下完成优先级。同样的，在基准运行的结束阶段，应该是一个减速的周期，那时资源从系统中释放，用户停止工作和断开连接。

部署新的应用程序

这节讲述与部署有关的设计决策。

首推策略

当新的应用程序回滚时，通常采用两种策略：

决堤方案——所有用户立即移植到一个新的系统中。

滴流方案——用户慢慢地从当前系统移植到新的系统中。

两种方案都有各自的优点和缺点。在需求阶段，决堤方案依赖于良好的应用程序测试，但是有最少量的数据转换和与旧系统同步的优点，因为它可以简单地关闭。滴流方案允许在工作量增量时可以调试可扩展性，但是这意味着事务发生时，需要从继承的旧系统中移植数据。

很难评论这两种方案哪一个更好，因为在事务发生时，每种方法都存在导致系统宕机的风险。

当然，滴流方案允许在他们介绍新的应用软件时切断实际用户，和允许只在影响移植用户时重新配置系统。这个方案在工作的初期效果最好，但限制用户登录服务，这意味着非计划宕机会影响小部分用户。

如何推出一个新的应用程序的决定是具体到每个业务。方案的采用都有它自身唯一的压力和着重点。从测试过程中累积越多，你将会认识到什么是最好的首推策略。

性能检查列表

为了帮助在首推过程中更加有序，像这样建立一个工作清单，假如执行正确，增加了产品的良好性能，如果有问题，可以快速地调试应用程序。例如：

1.       在你为产品数据库创建控件文件时，允许把 MAXINSTANCES(最大实例), MAXDATAFILES(最大数据文件), MAXLOGFILES(最大的日志文件), MAXLOGMEMBERS(最大家日志段), and MAXLOGHISTORY(最大历史日志)参数的设置比你在首推时的预期值调得更大些。这会导致使用更多的磁盘空间和更在的控件文件，但是在紧急情况下，当你需要扩展时会为你节约很多时间。

2.       设置开发环境的块的大小。如果在典型数据量和当前SQL 的执行计划中的测试是正确的，那么把开发/测试环境的schema 统计表导到产品数据库中。

3.       设置最小数量的初始化参数，理想状态下，大多数参数应该是初始化好了。如果有很多参数需要调整，那么这表明系统负载过轻，请参考“第四章 为性能配置数据库”的设置初始实例的配置相关信息。

4.       通过设置数据库对象的存储选项来管理块连接。表和索引与 INSERT/UPDATE/DELETE 比率应该由自动段空间管理创建。为了避免连接回滚段，应该使用自动撤销段。请看“第4章 为性能配置数据库”的撤销和临时段的相关信息。

5.       所有 SQL 语句应该进行最佳的性能检验和理解它们使用资源的情况。

6.       验证中间软件和程序与数据库连接时是有效率的连接管理和不做重复的登录/登出操作。

7.       验证SQL语句使用游标是有效率的。每条SQL语句都会被解析一次，然后重复执行。SQL语句的 where 子句中没有使用绑定变量而是以字符拼接的方式传递参数，则是每次都重新解析，只执行一次。假如预编译器是用来开发应用程序，那么要确保MAXOPENCURSORS, HOLD_CURSOR, and RELEASE_CURSOR 参数从默认值的优先级重置到预编译应用程序的值。

8.       验证所有的 schema 对象是否是正确地从开发环境移植到产品数据库中，它包括表，索引，序列，触发器，包，存储过程，函数，java对象，同义词，授权和视图。确保在测试时的一丁点改动都能在产品环境中体现。

9.       系统一首推，就从数据库和操作系统的统计中创建一个基线。这是一套验证或者纠正在设计时和首推过程中产生的假想的统计。