Oracle9i 应用系统优化

1、优化前提
应用系统方案制定正确，对应用系统运行环境分析合理、正确，在数据库效劳器性能、存储空间、网络带宽等方面的配置能够到达系统运行要求.
2、优化目标
● 响应时刻与吞吐量平衡
● 临界资源
2.1响应时刻与吞吐量平衡
依据应用类型的不同，性能优化的目标不同：
在线事务处理系统OLTP〕把吞吐量定义为性能指标；
决策支持系统〔DSS〕把响应时刻定义为性能指标。

响应时刻
响应时刻=效劳时刻+等待时刻
系统吞吐量
系统吞吐量指在给定的时刻内所完成的工作量。

有以下两种技术：
● 以相同的资源来完成更多的工作〔减少效劳时刻〕；
● 通过减少整个响应时刻来更快完成工作。

等待时刻
当竞争增强的时候，某个任务的效劳时刻也许维持不变，但它的等待时刻将增长。

我们开发的系统一般为OLTP和DSS的复合系统，侧重于OLTP,在硬件答应的情况下最好能够将运行数据库、分析数据库不离。

2.2临界资源
诸如CPU、内存、I/O容量、网络带宽等资源，基本上减少时刻的要害因素。

性能好坏取决于以下因素：
● 可用资源的数量
● 需要该资源的客户方的数目
● 客户方等待资源所消耗的时刻
● 客户维持资源的时刻长短
随着请求单元的增加，效劳时刻也增加。

为了处理这种情形，用户能够选择：
● 通过限制请求的速率，从而维护可同意响应时刻
● 还可通过增加资源数目，如CPU和硬盘〔增加资源的前提是应用系统设计良好，同时差不多做
了充分的优化〕
3、优化时期
从实际做的工程过程来瞧，除了系统安装优化外，系统优化往往基本上在系统实施、运行时才考虑，事实上到这时期做系统优化的局限性对比大，因为系统架构设计都成型、固化，大幅度调整设计的代价特不珍贵，一般只能在局部领域做优化，只能通过重新分配内存或优化I/O来或多或少地提高性能，实际上优化应该贯穿系统设计、开发、安装、测试、运行整个过程。

3.1设计时期
为了到达最正确的效果，优化工作应当从设计时期进行，而不是在系统实施后进行。

在数据库设计时期，个人认为需要注重如下几个方面：
● 业务对象不能建立在系统表空间；
● 索引表空间和业务表空间分开；
● 将LOB类型的字段与其它的类型分开；
● 依据应用系统功能确定是否要采纳冗余字段；
● 正确的主键字段的选择，建议采纳数字，不推举使用复合主键；
3.2开发、测试时期
在开发实现时期，个人认为需要注重如下几个方面：
● 执行sql使用变量绑定的方式，尽可能的保留在共享内存中，提高sql命中率；
● 多表关联查询时采纳有效的连接顺序；
● 尽可能的落低客户端和效劳器的网络数据交互，某个业务功能点需要频繁和数据库交互的，建议
采纳存储过程、临时表实现；
● 依据查询条件建立必要的索引，查询条件中使用oracle函数建立相对应的函数索引,数据值范围
较小的采纳位图索引
● 多张表关联查询时，有时可采纳先查询符合条件对应的表中要害字，然后通过要害字再查询对应
表中相关信息；
● 频繁访咨询，较少更新的数据量较小的表信息可采纳缓存的方式；
● 在实现批量更新、插进时，要采纳jdbc批量执行方法，同时调整对应的fetchsize参数。

在测试时期，应该模拟实际运行环境，测试出相关性能较差的功能点。

因为在设计、开发时期往往因为并发用户少、数据量小，许多性能咨询题显现不出来，假如软件测试充分，许多性能咨询题都能够显现出来，现在有许多优秀的软件测试工具，如LoadRunner、Robert在做压力测试方面都对比方便、优秀。

尽量将系统因程序设计、编码不当导致的性能咨询题显露在测试时期。

3.3安装时期
一般在安装生产数据库时，我们依据系统最早的规划，集合软、硬件环境，需要调整操作系统以及数据库参数，
操作系统交换区
交换区是Oracle的一项全然的要求。

能够依据Oracle的发行要求来确定。

一般交换区大小的要求是该效劳器内存的2倍至4倍之间，建议是内存的4倍
操作系统内核参数
3.3.3oracle文件设置
当效劳器平台已完成操作系统的安装后，就应该开始认确实考虑下面的咨询题：
● 是否采纳裸设备
实际应用的生产系统全然基本上采纳裸设备，使用裸设备关于读写频繁的数据库应用来讲，能够极大地提高数据库系统的性能。

● 安装点的考虑
Oracle的安装点确实是基本指数据文件、日志文件和操纵文件的安置路径，为了使系统在以后运行性能到达优化，建议将数据文件、日志文件和操纵文件的安置路径与数据库系统存放在不同的路径上。

最好将数据文件、日志文件和操纵文件分不存放在不同的路径。

● SYSTEM表空间对应数据文件
在自定义安装会话中，建议你依据需要设置system表空间所对应的数据文件的大小。

一般要设置比默认值的2倍。

该数据文件的大小最好是在300MB至500MB间。

因为数据文件太小不利于系统的运行。

● 临时表空间对应的数据文件
临时表空间对应的数据文件能够依据今后系统存放的应用的处理情况来定。

比方系统今后可能要经常进程排序处理，那么需要设置较大的临时表空间，也可能需要再建立新的临时表空间。

这个地方建议临时表空间的数据文件在100MB至300MB左右。

● 回滚段表空间对应的数据文件
9i回滚表空间基本上系统治理，初始值也是依据系统事务量预估量的值，实际到运行时期假如系统常出现ora-01555错误的时候，可能就需要增加回滚表空间的大小。

● 日志文件的大小
日志文件的大小关于Oracle系统的运行也是相当重要。

默认值是太小。

实际依据事务繁忙预估量日志大小，没有固定的具体值范围，建议重做日志切换时刻不能过短也不能过长，一般在20－40分钟左右。

该参数能够在系统运行期间依据数据库系统日志切换时刻重新调整，操纵文件的大小。

● 数据库块的大小
假如你的应用系统是OLTP的话，能够采纳较小的数据库块。

假如是DSS类型的应用系统，那么能够设置较大的数据库块，目前Oracle产品所答应的数据库块能够是2KB至64KB之间。

不管你选择较大的块或较小的块，它的值都必须是2的整数倍，比方2048,4096,8192等。

但需要注重的是，假如操作系统为64位，那么可选择较大的块。

● 字符集的选择
字符集是Oracle系统专门支持的一项技术。

具体请参考另外的章节。

一般不要与另外的差不多存放的Oracle系统的字符集产生冲突即可。

但假如你的环境是一个新的平台，不需要与其它平台进行数据交换的话，建议选择默认的字符集。

如此能够利于今后的修改。

数据库启动参数
.2实时查寻
假如需要实时的查寻性能隐患的相关sql,通过
v$session_wait,v$session,v$sqltext_with_newlines三张动态视图就能够全然查寻到相关的sql，足本如下：
fromv$sqltext_with_newlinesst,v$sessionse,v$session_waitswressandst.hash_value =se.sql_hash_valueandse.sid=sw.sidand
(sw.event='bufferbusywaits'or
sw.event='enqueue'or
sw.event='freebufferwaits'or
sw.event='globalcachefreelistwait'or
sw.event='latchfree'or
sw.event='logbufferspace'or
sw.event='parallelqueryqreflatch'or
sw.event='pipeput'or
sw.event='writecompletewaits'or
sw.eventlike'librarycache%'or
sw.eventlike'logfileswitch%'
)orderbyst.hash_value,st.piece;
分析
分析报告个人一般要紧关注top5event以及相关的读逻辑块、物理块、执行次数较多的sql,实际上更多的侧重在sql分析上
提取出sql以后就能够进行分析，要紧采纳分析执行方案的方式。

个人一般喜爱如下的方式进行分析：
● 生成方案表〔初次〕
以sys用户执行足本${oracle_home}/rdbms/admin/utlxplan.sql，
● 创立公用同义词，方便在每个用户下生成执行方案〔初次〕
Createpublicsynonymplan_tableforplan_table;
Grantallonplan_tabletopublic;
● 每次分析时设置sqlplus环境变量
Settimingon
Setautotracetraceonly
● 查瞧相关sql执行方案
其他客户端软件pl/sqldeveloper,toad分析执行方案都对比方便。

● 执行方案路径解释
优化
Oracle运行时期优化的更多是对sql的优化，个人理解工作要紧是：分析性能较差sql;
调整性能较差的sql的实现方式，协助程序员更改相关程序;
对相关的查询条件建立合理的索引;
依据需要合理的更新表、索引的程序信息;
3.4.3.1oracle优化器
优化器优化方式
Oracle的优化器共有两种的优化方式,即基于规那么的优化方式
(Rule-BasedOptimization,简称为RBO)和基于代价的优化方式
(Cost-BasedOptimization,简称为CBO)。

A、RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些
规那么。

比方我们常见的,当一个where子句中的一列有索引时往走索引。

B、CBO方式：依词义可知,它是瞧语句的代价(Cost)了,这个地方的代价要紧指
Cpu和内存。

优化器在判定是否用这种方式时,要紧参照的是表及索引的统计
信息。

统计信息给出表的大小、有少行、每行的长度等信息。

这些统计信息起
初在库内是没有的,是你在做analyze后才出现的,许多的时侯过期统计信息会
令优化器做出一个错误的执行方案,因些我们应及时更新这些信息。

在Oracle8
及以后的版本,Oracle推举用CBO的方式。

●优化器的优化模式(OptermizerMode)
Rule:走基于规那么的方式。

Choose:默认的情况下Oracle用的是这种方式，不建议修改该参数。

指的是当
一个表或索引有统计信息,那么走CBO的方式,假如表或索引没统计信息,表又
不是特殊的小,而且相应的列有索引时,那么就走索引,走RBO的方式。

FirstRows:它与Choose方式是类似的,所不同的是当一个表有统计信息时,它将
是以最快的方式返回查询的最先的几行,从总体上减少了响应时刻。

AllRows:也确实是基本我们所讲的Cost的方式,当一个表有统计信息时,它将以
最快的方式返回表的所有的行,从总体上提高查询的吞吐量。

没有统计信息那
么走基于规那么的方式。

3.4.3.2常见优化咨询题
●明明有索引，表的数据量也特不大，执行路径不走索引
对应表、索引的统计信息有误，能够通过dba_tables,dba_indexes视图中的num_rows 查瞧对应表、索引的统计信息，假如有误，重新统计。

Analyzetabletable_namecomputestatistics
Fortable/*统计表*/
Forallindexedcolumns/*统计有索引的表列*/
●统计后性能反而变差
尽管oracle推举采纳CBO方式，但有时对应的执行路径并不是最正确，所
以我们在统计信息时只有针对性的统计相关表、索引信息。

一般有两种处理方法
a.删除对应的统计信息
Analyzetabletable_namedeletestatistics
Analyzeindexindex_namedeletestatistics
对应的系统包dbms_stats也可实现生成、删除表、索引的统计信息
b.使用hints明确指定对应的执行路径
3.4.3.3hints
常用的几种hints如下：。