数据库应用的类型是复杂的，有大量用户同时更新数据库的联机事务处理应用（如银行储蓄系统）、对海量数据进行查询并生成报告的数据仓库应用（如分析商场销售数据的决策支持系统）、在互联网上大量用户同时查询和更新数据的联机事务处理应用（如网上银行应用）等等。为了满足与适应各种各样的商业应用，使各种不同的应用在不同的环境下都能达到最优的状态，Oracle 数据库系统提供了大量的非常灵活的可调节内容。为了保证Oracle数据库运行在最佳的性能状态下，在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面，其中应用程序的分析与设计是在信息系统开发之前完成的。
分析评价Oracle数据库性能主要有数据库吞吐量、数据库用户响应时间两项指标。数据库用户响应时间又可以分为系统服务时间和用户等待时间两项，即“数据库用户响应时间=系统服务时间＋用户等待时间”。因此，获得满意的用户响应时间有两个途径：一是减少系统服务时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。
数据库性能优化包括如下几个部分：
- 调整数据结构的设计这一部分在开发信息系统之前完成，程序员需要考虑是否使用Oracle数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。
- 调整应用程序结构设计这一部分也是在开发信息系统之前完成的。程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
- 调整数据库SQL语句应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了Oracle数据库的性能。 Oracle公司推荐使用Oracle语句优化器（Oracle Optimizer）和行锁管理器（Row-Level Manager）来调整优化SQL语句。
- 调整服务器内存分配内存分配是在信息系统运行过程中优化配置的。数据库管理员根据数据库的运行状况不仅可以调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小，而且还可以调整程序全局区（PGA区）的大小。
- 调整硬盘I/O 这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O 负载均衡。
- 调整操作系统参数例如：运行在Unix操作系统上的 Oracle数据库，可以调整Unix数据缓冲区的大小、每个进程所能使用的内存大小等参数。
实际上，上述数据库优化措施之间是相互联系的。Oracle 数据库性能恶化的表现基本上都是用户响应时间比较长，需要用户长时间的等待。而性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。
Oracle数据库的性能优化调整是一个系统工程，涉及的方面很多。数据库管理员需要综合运用上面介绍的规律，认真分析Oracle在运行过程当中出现的各种问题，以保证Oracle数据库运行的高效率。还需要指出的是，上面给出的语句只是测得Oracle运行过程的某一个时间点的情况，数据库管理员不能仅仅根据一个点的情况就断定数据库运行性能的好坏，只有多运行一些时间点才能对数据库运行状况做出一个综合评估。
Oracle 优化和性能调整将要涉及的问题
为了保证Oracle数据库运行在最佳的性能状态下，在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面，其中应用程序的分析与设计是在信息系统开发之前完成的。
分析评价Oracle数据库性能主要有数据库吞吐量、数据库用户响应时间两项指标。数据库用户响应时间又可以分为系统服务时间和用户等待时间两项，即：
数据库用户响应时间=系统服务时间＋用户等待时间
因此，获得满意的用户响应时间有两个途径：一是减少系统服务时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。
数据库性能优化包括如下几个部分：
- 调整数据结构的设计这一部分在开发信息系统之前完成，程序员需要考虑是否使用Oracle数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。
- 调整应用程序结构设计这一部分也是在开发信息系统之前完成的。程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
- 调整数据库SQL语句应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了Oracle数据库的性能。 Oracle公司推荐使用Oracle语句优化器（Oracle Optimizer）和行锁管理器（Row-Level Manager）来调整优化SQL语句。
- 调整服务器内存分配内存分配是在信息系统运行过程中优化配置的。数据库管理员根据数据库的运行状况不仅可以调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小，而且还可以调整程序全局区（PGA区）的大小。
- 调整硬盘I/O 这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O 负载均衡。
- 调整操作系统参数例如：运行在Unix操作系统上的 Oracle数据库，可以调整Unix数据缓冲区的大小、每个进程所能使用的内存大小等参数。
实际上，上述数据库优化措施之间是相互联系的。Oracle 数据库性能恶化的表现基本上都是用户响应时间比较长，需要用户长时间的等待。而性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。
Oracle数据库常用的数据库性能优化工具有：
- Oracle数据库在线数据字典 Oracle在线数据字典能够反映出Oracle的动态运行情况，对于调整数据库性能是很有帮助的。
- 操作系统工具例如使用Unix操作系统的Vmstat、 Iostat等命令可以查看到系统级内存和硬盘I/O的使用情况，这些工具能够帮助管理员弄清楚系统瓶颈出现在什么地方。
- SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，并使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。
- Oracle Enterprise Manager（OEM）这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的Oracle数据库管理的命令。
- Explain Plan——SQL语言优化命令使用这个命令可以帮助程序员写出高效的SQL语言。
系统性能评估
信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统类型来着重考虑不同的数据库参数。
- 在线事务处理信息系统（OLTP）这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的Oracle数据库需主要考虑以下参数：
- 数据库回滚段是否足够？
- 是否需要建立Oracle数据库索引、聚集、散列？
- 系统全局区（SGA）大小是否足够？
- SQL语句是否高效？
- 数据仓库系统（Data Warehousing）这种信息系统的主要任务是从Oracle的海量数据中进行查询，以得到数据之间的某些规律。数据库管理员需要为这种类型的Oracle数据库着重考虑下述参数：
- 是否采用B＊?索引或者Bitmap索引？
- 是否采用并行SQL查询以提高查询效率？
- 是否采用PL/SQL函数编写存储过程？
- 有必要的话，需要建立并行数据库以提高数据库的查询效率。
参数的调整
CPU参数
- CPU是服务器的一项重要资源，服务器良好的工作状态表现为在工作高峰时CPU的使用率高于90％。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源；如果工作高峰时CPU使用率仍然很低，则说明服务器CPU 资源还比较充足。
- 使用操作命令可以看到CPU的使用情况，一般Unix操作系统的服务器，可以使用sar-u命令查看CPU的使用率；NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。
- 数据库管理员可以通过查看v＄sysstat数据字典中的 “CPU used by this session”统计项得知Oracle数据库使用的CPU时间；查看“OS User level CPU time”统计项得知操作系统用户状态下的CPU时间；查看“OS System call CPU time” 统计项得知操作系统系统状态下的CPU时间，操作系统总的CPU时间就是用户状态和系统状态时间之和。如果Oracle数据库使用的CPU时间占操作系统总CPU时间的90％以上，就说明服务器CPU基本上被Oracle数据库使用着，这是合理的，反之，则说明服务器CPU被其他程序占用过多，Oracle数据库无法得到更多的CPU时间。
内存参数
----内存参数的调整主要是指Oracle数据库的系统全局区（SGA）的调整。SGA主要由3部分构成：共享池、数据缓冲区、日志缓冲区。
----共享池由两部分构成：共享SQL区和数据字典缓冲区。共享SQL区是存放用户SQL命令的区域，数据字典缓冲区则存放数据库运行的动态信息。
结束语
----Oracle数据库的性能优化调整是一个系统工程，涉及的方面很多。数据库管理员需要综合运用上面介绍的规律，认真分析Oracle在运行过程当中出现的各种问题，以保证Oracle数据库运行的高效率。还需要指出的是，上面给出的语句只是测得Oracle运行过程的某一个时间点的情况，数据库管理员不能仅仅根据一个点的情况就断定数据库运行性能的好坏，只有多运行一些时间点才能对数据库运行状况做出一个综合评估。
Oracle 联机决策支持系统下的性能调整和优化原则
DSS 系统的特征是从大量的数据中产生有意义的报告。DSS 应用可能会经常与 OLTP 一起使用，但因为它们的设计要求差异很大，把 OLTP 系统用于决策支持不是好的主意。OLTP 的用户一般很多，而 DSS 系统的用户一般较少。决策支持系统的例子有与定单录入系统（OLTP系统）一起工作的现金流预测工具，该工具可以帮助决定需要多大的现金储备。另一个决策支持的例子是客户需求分析工具，该工具可以找出某个地域客户对哪个产品购买量最大。
决策支持系统的主要特征是：
- 读取大容量的数据，经常使用全表扫描作为存取数据的方法。
- 极少量地更新数据。一般而言，从OLTP 系统的数据（也可能是其它的数据源）会以批的方式流向 DDS 系统，用户自己极少会更新 DSS 的数据。
下图反映了DSS系统的特征：
DSS系统在运行时，有如下的一些要求：
- 合理的响应时间。
- 结果是准确的。
- 可以在白天使用。
为了满足上面的要求，应当从以下几个方面考虑调节数据库DSS应用系统。
1. 在使用应用逻辑和声明约束来维护完整性方面，切记声明完整性约束的代价要小。在DSS系统中，相关完整性约束和表的check 约束是主要使用的约束形式。
2. 尽量要使代码被存储过程对象共享。
3. 即使一条SQL语句在不同的运行环境下捆绑变量（bind variable）取了不同的值，Oracle认为他们是同样的SQL语句。因此，要使分析SQL语句的工作减少到最抵，应当使用捆绑变量，而不是将这些不同的值直接放到SQL语句中（使用 literal）（如果这样做了，Oracle 认为它们之间是不同的SQL，需要重新分析）。但是，这样做会有如下的损失：优化器无法知道列的可选择性。而完全写出来的SQL 语句（使用 literal），可使基于成本的Oracle优化器使用直方图统计（histogram）。
4. 无论如何，对DSS系统来说，分析 SQL 用的时间要比执行SQL语句用的时间要少的多。工作重点应当是优化SQL语句执行计划的存取路径上。这里的微小调节可能会带来几分钟，甚至是几小时性能的提高。开发人员必须考虑：
- 使用并行查询（parallelized query）。这可以使多个处理器工作在一起，同时处理一条SQL语句。使用镜像多处理（Symmetric Multiprocessors，SMP）、集群、大规模并行处理（massively parallel processing，MPP）会极大地提高DSS系统的性能，因为这样做可以将工作分在多个 CPU 上完成。
- 应当用提示来控制SQL 语句的存取路径，并利用 explain plan 来调节SQL 语句。
5. 因为DSS系统的数据更新以定时的批处理为特征，所以，DBA 在进行性能调节时有很多选择。DSS系统可以使用索引和簇（特别是哈稀簇），因为数据更新并不经常发生。在批量的数据更新完成后，可以重新创建索引和簇，以避免修改索引和簇的负面影响。如果不能在批量处理完成后重新创建簇，则为存取性能考虑，不应为在装入时不断增长的表创建簇。
6. 应当将索引存放到一起。
7. 因为大多数查询是全表扫描，应当仅在有选择性查询的表上加索引。
8. 应当经常用 analyze 进行统计。对那些数据分布不均匀的表，应当经常产生统计直方图（Histogram）。
9. 对那些不同值很少的列，使用 bitmap 索引。
10. 对于块插入和修改，必须设置如下的初始化参数：SORT_AREA_SIZE、BITMAP_MERGE_AREA_SIZE、CREATE_BITMAP_AREA_SIZE。
11. 对那些需要用键列做条件做准确匹配的查询或范围查询，如果要将行的信息全部查出，应考虑使用组织索引表。
12. 在一些情况下，一些表根本不变化，此时可以将这些表放到一个特殊的表空间中，并使该表空间只读。
13. 因为DSS应用经常进行全表扫描，所以应当将 DB_BLOCK_SIZE 的值设得高一些，即使这需要重新创建数据库也应这样做。因为大量读是DSS系统的基本特征，这样做会使DSS系统的性能发生根本改变。还应当注意参数 DB_FILE_MUTIBLOCK_READ_COUNT 的设置，该参数决定了全表扫描和快速全索引扫描每次操作系统读调用操作的数据库块数。盘区的尺寸应当是DB_BLOCK_SIZE* DB_FILE_MUTIBLOCK_READ_COUNT的倍数。
14. 建立实体化视图，并使用查询重写。
Oracle 联机决策支持系统下的性能调整和优化原则
很多组织都有联机事务处理系统。这类系统的特征是：
- 存在很高的数据更新活动，而这些活动通常是由大量用户进行的。
- 大量用户并发存取数据库。
- 数据是持续增长的。
这类应用的例子有超市销售系统、航空售票系统、银行存取款系统、网上商店等等。下图显示了 OLTP 系统的基本特征：
OLTP 系统在运行时，有如下的一些要求：
- 高可用性（7*24）。
- 高响应速度。
- 高的并发处理能力。
- 快速的故障恢复。
为了满足上面的要求，应当从以下几个方面考虑调节数据库应用系统。
1. 为避免Oracle 动态地为数据库对象分配存储空间而影响系统性能，应当经常检查对象的空间使用和分配情况，人工为表、索引、和簇等分配存储空间。
2. OLTP 系统的设计目标是可以快速地输入和修改数据而不牺牲数据的准确性。因为很多用户可能会操作同样的数据，所以必须有良好的并发处理机制。另外，因为用户会根据现有的数据进行加减操作，所以必须有将数据改变联机快速地显示出来的机制。
在 OLTP 系统中，有很多两难的问题。OLTP 需要快速地输入数据而不牺牲准确性。而检查录入数据的正确性又会降低系统的性能。Oracle 通过完整性约束（如 CHECK约束、外键约束）提供了一个良好地检查录入数据的结构。因为这些检查机制是定义在数据定义语言里的，它们比触发器效率更高。但是，完整性约束只能解决简单的问题，对于复杂的情况，还必须用触发器解决。
3. 通常，OLTP 系统需要实时地看到数据，这是 OLTP 系统最难解决的问题之一。Oracle 用索引和簇来帮组数据查询。对有较少改变的表来说，索引工作的很好；但对簇来说，因为簇必须仔细存储来装载那么多的数据，数据的改变会导致行迁移和链。而行迁移和链又会抵消簇得到的性能改善。然而，数据更新是 OLTP 的主要功能，因此，设计人员需要和 DBA 以及用户一起来平衡快速地查询数据和快速地改变数据的得失：
a) 索引会提高查询的性能，但会降低DML操作的性能，因为DML操作必须维护索引。
b) 在子表的外键上加索引可以避免在修改数据时对父表加锁。
c) B-tree 索引优于 bitmap 索引。因为如果锁住了B-tree 索引的一个入口，则仅仅锁住一行，而锁住了bitmap索引的一个入口，则锁住了一系列的行。
d) 对于如序列号这样的列，可以使用反转索引来避免数据的单调增长，从而产生块分裂。
e) 应当经常重建索引。
f) 使用 hash 索引可以加速相等条件的查询，但对于经常插入的表或经常用大的列值修改的表（可能发生行迁移）则应避免使用使用 hash索引。
g) 如果表在增长，则在 hash 键上会有许多碰撞，从而导致将行存储在 overflow 块上。为避免这个问题，应正确地预计 hashkeys 的值。对给定数量的行用大数量的 hash keys 会使碰撞降低。
无论如何，索引会降低数据更新的性能，因此，在OLTP系统中应尽量减少索引。
4. OLTP事务是较小的，回退段的空间是够用的。大量的事务要求足够数量的回退段来防止对回退段的竟争。要设置正确的回退段的数目，需要了解事务的运行方式。假设在任意时刻有9个事务，则3个回退段是足够的。另外，对于小的数据库来说，应将回退段的 minextents 设置成最小 10，而对于大的数据库来说，应将回退段的 minextents 设置成最小 20，这样即可避免回退段的动态扩展，又可避免回退段头移入一个活动的盘区，从而回退段需要分配额外的盘区。
5. 通过数据的规范化也可以达到快速检索数据的目标。
6. 如果可能，DBA 应当参加到数据建模的过程中，从而可以知道哪些表会不断更新。一般来说，将经常更新的表放到一个特殊的表空间中经常备份是明智的。另外，表空间可以设置成缺省地具有高的 PCTFREE 值和低的 PCTUSED 值，这样可以减少数据迁移和行链的可能性。
Oracle 数据库性能调节和优化的一般过程和步骤(
很多性能问题可以用以下的三种方法解决：
- 购买新硬件。性能问题的一种解决办法是购买功能和性能更强的硬件。然而，这样的硬件往往非常昂贵，且随着时间的推移，软件的升级和复杂化，数据的增加，再好的硬件也会过时。DBA 必须最好地利用现有的硬件资源，想其它办法提高系统的性能。
- 有效的数据库性能调节；
- 有效的应用设计。
- 有效的应用开发。
Oracle 自己给出了DBA 应当采用的性能调节的5大步骤。一般而言，在所有的情况下，都应从第1步开始，以避免在解决问题的过程中又产生新的问题。在此同时，也应注意到，随着步骤的深入，调节所影响的范围和深度也在加大。下面是调节的步骤：
1. 调节系统结构设计和应用系统的设计。
2. 调节应用。在很多情况下，写的很差的查询语句是性能问题的根源。DBA 应当在进入下一步的性能调节之前鼓励开发人员调整 SQL 查询语句的性能。
3. 调节内存结构。在应用调节后，内存结构恰当的配置和调节会对应用和数据库有极大的性能影响。Oracle 应当有足够的空间分配给 SQL/PLSQL、数据字典缓冲区、数据缓冲区、重做日志缓冲区以获取高的性能回报。这些回报体现在以下几个方面：
- 对已存在于内存中的数据库数据更快的查询。
- 减少 RDBMS 对 SQL 不必要的分析。
- 消除操作系统的页面交换，特别是将SGA交换到磁盘。
4. 调节磁盘I/O使用。Oracle 设计成防止 I/O 负面地影响应用系统的性能。Oracle 服务器、DBWR、LGWR、CKPT 以及 SMON 的特性均可对磁盘的使用进行有效的管理，并设计成减少应用对磁盘快速写的依赖来提高性能。调节磁盘使用一般意味着将 I/O 分布到多个磁盘上以避免竞争、将数据存储在块上以方便读取、以及产生恰当尺寸的盘区来存储数据。
5. 检测和消除资源竞争。与调节磁盘I/O使用一样，Oracle 设计成尽量减少资源竞争。例如，Oracle 可以检测和消除死锁。然而，有很多情况用户会竞争使用资源，例如回退段、信使（dispatchers）、重做日志缓冲区拴（latches）等等。虽然不常出现，但这些竟争会对应用的性能极其不利。
6. 调节操作系统配置。Oracle 在操作系统之上工作。操作系统性能的好坏会直接影响到 Oracle。即使 Oracle 本身已经调节的很好，很差的操作系统设置会令数据库的性能表现的很差。
上面是在性能出现问题的情况下进行调节的6个步骤。即使一切运转良好，DBA 也应预调节数据库，这样做的好处是可以减少遇到问题时的调整时间。DBA 可能会遇到这样的问题：要花时间解决前面出现的问题，又要做预调节工作。无论如何，都应做一些预调节工作，这样既可以增加对应用系统的了解，又可以减少一旦出现问题需要的调节时间。
不同类型系统中优化时特别关注的问题和参数
信息系统的类型不同，需要关注的数据库方面也是不同的。数据库管理员需要根据自己的信息系统类型来着重考虑不同的数据库参数。
- 在线事务处理信息系统（OLTP）这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的Oracle数据库需主要考虑以下参数：
- 数据库回滚段是否足够？
- 是否需要建立Oracle数据库索引、聚集、散列？
- 系统全局区（SGA）大小是否足够？
- SQL语句是否高效？
- 数据仓库系统（Data Warehousing）这种信息系统的主要任务是从Oracle的海量数据中进行查询，以得到数据之间的某些规律。数据库管理员需要为这种类型的Oracle数据库着重考虑下述参数：
- 是否采用B＊?索引或者Bitmap索引？
- 是否采用并行SQL查询以提高查询效率？
- 是否采用PL/SQL函数编写存储过程？
- 有必要的话，需要建立并行数据库以提高数据库的查询效率。
参数的调整
- CPU参数
- CPU是服务器的一项重要资源，服务器良好的工作状态表现为在工作高峰时CPU的使用率高于90％。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源；如果工作高峰时CPU使用率仍然很低，则说明服务器CPU 资源还比较充足。
- 使用操作命令可以看到CPU的使用情况，一般Unix操作系统的服务器，可以使用sar-u命令查看CPU的使用率；NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。
- 数据库管理员可以通过查看v＄sysstat数据字典中的 “CPU used by this session”统计项得知Oracle数据库使用的CPU时间；查看“OS User level CPU time”统计项得知操作系统用户状态下的CPU时间；查看“OS System call CPU time” 统计项得知操作系统系统状态下的CPU时间，操作系统总的CPU时间就是用户状态和系统状态时间之和。如果Oracle数据库使用的CPU时间占操作系统总CPU时间的90％以上，就说明服务器CPU基本上被Oracle数据库使用着，这是合理的，反之，则说明服务器CPU被其他程序占用过多，Oracle数据库无法得到更多的CPU时间。
- 内存参数：内存参数的调整主要是指Oracle数据库的系统全局区（SGA）的调整。SGA主要由3部分构成：共享池、数据缓冲区、日志缓冲区。共享池由两部分构成：共享SQL区和数据字典缓冲区。共享SQL区是存放用户SQL命令的区域，数据字典缓冲区则存放数据库运行的动态信息。
Oracle数据库的性能优化调整是一个系统工程，涉及的方面很多。数据库管理员需要综合运用上面介绍的规律，认真分析Oracle在运行过程当中出现的各种问题，以保证Oracle数据库运行的高效率，数据库管理员不能仅仅根据一个点的情况就断定数据库运行性能的好坏，只有多运行一些时间点才能对数据库运行状况做出一个综合评估。
粗略来讲，系统调整一般反映在下列方面：
- Shared Pool and Library Cache Performance Tuning(共享池和Library Cache)：Oracle将SQL语句、存储包、对象信息和很多其他的项目保存在SGA中一个叫共享池（shared pool）的地方。这个可共享的区域由一个成熟的高速缓存和堆管理器管理。它有3个基本的问题要克服：
- 内存分配的单元不是个常量。从池中分配的内存单元可能是从几个字节到几千个字节。
- 在用户完成工作时，不是所有的内存都能够释放出来，因为共享池的目标是使信息最大程度的共享。
- 没有一个象其他常规的高速缓存的文件做后备的存储那样磁盘空间供整页的导出。
只有可重新创建的信息可以从Cache中丢弃，在他被再次需要的时候再重新创建。
共享池调整的技巧有：
- 刷（ Flush）共享池可以使小块的内存合并为大块的内存。当共享池的碎片过多时，这能够暂时恢复性能。刷共享池可以使用语句：alter system flush shared_pool;
- 注意执行这个语句将会造成性能的暂时尖峰，因为对象都要重新加载。所以应当在数据库的负载不是很大的情况下进行。
- 确保联机事务处理（ OLTP）应用使用绑定变量（bind variables）. 这一点对于决策支持系统（DSS）并不重要。
- 确保library cache 的命中率 > 95%
- 增大共享池并不总能解决命中率过多的问题。
- Buffer Cache Performance Tuning(数据库缓存调整)：数据库缓存保持了从磁盘上读去的数据块的备份。因为缓存通常受到内存约束的限制，不是磁盘上所有的数据都可以放到缓存里。当缓存满了的时候，后来的缓存不中使得Oracle将已经在缓存中的数据写到磁盘上。后续的对写到磁盘上的数据的访问还会造成缓存不中。
从缓存调整的角度看，应力求避免以下的问题：
- '缓存的最近最少使用(LRN)链'（'cache buffers LRU chain' ）的加锁竞争
- '平均写队列'（"Average Write Queue" ）长度过大
- 过多时间花在等待‘写完毕等待上’（"write complete waits" ）
- 过多时间花在等待‘缓冲释放等待’上（"free buffer waits" ）
- Latch Contention加锁（插销）竞争：插销加锁是SGA中保护共享数据结构的低层的串行化机制。插销latch是一类可以非常快的获得和释放的锁。插销锁的实现是依赖于操作系统的，尤其在关于一个进程是否会等待一个锁，和等多久方面。
有如下的锁（插销）需要调整：
- Redo Copy/Allocation Latch：重写日志的复制/分配插销
- Shared Pool Latch：共享池的插销
- Library Cache Latch：Library Cache插销
- Redo Log Buffer Performance Tuning（重写日志缓冲的调整）：LGWR 将重写日志缓冲中的重写项写到重写日志文件中。一旦LGWR将这些项复制到重写日志文件中，用户进程就可以重写这些项。统计项目"redo log space requests"反映了用户进程等待重写日志缓冲中空间的时间的数字。
设置重写日志大小的一些提示：
- "redo log space requests"的值应该接近0。
- 设定合适的重写日志的大小，建议每15-30分钟进行一次重写日志的切换。
- Query Performance Tuning（查询效率的调整）：如果查询运行得很慢，请考虑这些方面：
- 你希望这个查询运行的有多快以及有理由这样要求吗？
- 优化模式OPTIMIZER_MODE 设为何值？
- 查询涉及的索引都是有效的吗？
- 在数据库中有没有其他的长时间运行的查询（大查询）
- 对于CBO(基于成本的优化)In case of CBO:
- 表和索引上有统计信息吗？
- 统计信息是被计算出来的还是被估计出来的？
- 对于查询的性能调整由两个主要的调试工具：
- Rollback Segment Performance Tuning（回滚段的调整）：Oracle数据库提供了任何数据库对象上的SELECT, INSERT, UPDATE, 和DELETE 操作的读一致性。回滚段用于保存由那些要回滚的动作或系统需要产生一个和前面某一时间读一致的影像所产生的可取消事务。
设置回滚段大小的技巧如下：
- 建议最少每4个事务一个回滚段
- 建议为长时间运行的大查询提供一个大回滚段。
- v$rollstat中的wrap数接近0。否则增大扩展大小（extent size）。
SELECT b.name, a.wraps FROM V$ROLLSTAT a, V$ROLLNAME b;
- n Temporary Tablespace Performance Tuning（临时表空间的调整）：从RDBMS release 7.3开始，Oracle引入了临时表空间的概念。这个表空间用于保存临时对象，如排序段。排序段采用它所在的表空间的缺省存储参数（DEFAULT STORAGE (NEXT) 子句）作为自己的存储参数。
临时表空间的调整的技巧如下:
- 如果即使在稳定的状态下也存在很多的排序扩展锁（Sort Extent Pool latch）的竞争，你应该通过修改临时表空间的DEFAULT STORAGE 子句的NEXT值来增大扩展块的大小。
- 如果存在很多的排序扩展锁（Sort Extent Pool latch）的竞争并且这种等待是由于过多的并发的排序造成的，你应该增大SORT_AREA_SIZE参数的大小，以使更多的排序能保存在内存中。
- 建议让扩展块的大小和SORT_AREA_SIZE参数相同。
- Utlbstat/Utlestat Performance Tuning（Utlbstat/Utlestat调整）：Utlbstat/Utlestatt 是一堆存放在你的$ORACLE_HOME/rdbms/admin目录下的SQL脚本，他们对于捕获系统范围的数据库性能统计的快照非常有用。UTLESTAT 创建这些视图的第二个快照，并将两个快照之间的差异报告到文件 'report.txt'中。 Utlbstat.sql 在你的sys用户下创建一系列的表和视图，其中包括开始时数据库性能统计的快照。Utlesta.sql在你的sys用户下创建一系列的表，其中包括结束时数据库性能统计的快照和一个叫 'report.txt'的文件。
使用方法：
- 确保你已经将TIMED_STATSTICS设为TRUE (这仅仅给数据库操作增加了一点非常小的开销)。
- 确保数据库在运行utlbstat前，已经启动并且运行了一段时间。
- 从svrmgrl 中而不是sql*plus中运行utbstat.sql和utlestat.sql。
- 确保在脚本utlbstat/estat运行时，数据库不被Down掉，否则产生的统计就不正确。
- 至少运行utlbstat/estat 1-3个小时，才好调试你的数据库。
- Checkpoint Performance Tuning（检查点性能调整）：检查点（ Checkpoint）是一个数据库事件，用来同步内存和磁盘上的数据文件中的数据块。检查点的目的有两个：
检查点调整方法如下：
- 如果LOG_CHECKPOINT_INTERVAL的值比重写日志（ redo log）的大小大，那么 checkpoint只在ORACLE进行日志从一个组到另一组切换的时候才发生。这正是我们希望的。这个行为在 Oracle 8i中有了变化。
- 当把LOG_CHECKPOINTS_TO_ALERT设为TRUE时，将把checkpoint启动和停止的时间记录在alert log日志里。这对于你确定checkpoint是否正以最佳的频率发生很有帮助。
- 理想的情况是，checkpoint在仅在日志切换时发生。
- Import Performance Tuning（数据载入性能调整）：没有什么固定的信息是关于如何加速那些慢得让人难以忍受的import的。显然import要花费它完成所需要的时间，但是作一些事情可以缩短他们所花的时间。方法很简单，并行操作。
