关于 Oracle 优化方针
当拥护抱怨系统的响应时间时，通常优化不是在者种情况下才进行。因为当响应时间比较慢时，再通过实现某些最有效的优化策略来解决，就已经太迟了，出现这种情况时，如果用户还不愿意
彻底重新设计
I/O
来或多或少地提高一点性能。
应用程序，那么就只能通过重新
分配内存或优化
§1.1
优化的优先步骤
下面是对基于ORACLE应用的优化的推荐方法，它分为10个步骤。按照投资回报减少的顺序给出优化过程步骤，对性能影响最大就越靠前：
应用系统的优化方法
为获得最佳的系统性能，用户有时需要调整商业规则。主要考虑有关配置问题。比如所申请的
线路；所购买的
网络设备
等。即如果在实际使用时已经发现超出物理的能力，则公司的上层就应该
追加另外的配置方案
，如采用
多层配置
方案等。
数据库设计阶段通常要经历规范化阶段，此时需要对数据进行分析，以降低数据冗余，除了主键外，任何数据元素都应当在数据库中只能出现一次。有时又需打破这种规范形式，用户还需要保证数据库通过汇总值经常性地进行记忆。例如，在每次进行访问的时候，不应当强迫应用程序重新计算给定订单中的所有商品的总价。另外，为了更快地访问信息，用户应当建立主关键字和外部关键字索引。
数据设计阶段的另一个考虑是避免数据争用。也就是说，把对数据的访问进行定位，以避免任何请求特定数据范围的进程可以局限到特定的实例。
在ORACLE 并行服务器中，需要寻找同步点，对设计不良的系统，就存在顺序命令编号的要求，也就是同步的问题。
为了避免数据争用，考虑：
l
将数据分区
l
使用局部或全局索引
对于某些带智能处理的设计而言，在战略上
使用缓存数据技术。在某零售应用程序中，用户在每天开始的时候可以选择一次税率，并将其缓存在应用程序中，通过这种方式，就可以避免一天之中总是重复地获取相同的信息。
在设计完应用系统应用程序之后，就需要对数据库的逻辑结构进行规划，这一步主要是对索引的设计进行调整，以保证数据被正确索引。在逻辑结构设计阶段，则应当创建辅助索引来支持应用程序。
对于由于争用所引起的性能问题，经常会涉及到插入相同的块，或者是序号错误的使用。在索引的设计、使用和定位的时候，以及使用序号产生程序和簇的时候，应当格外小心。
优化ORACLE服务器之前，应当确保用户应用程序充分利用了SQL语言的特性，以及Oracle为增强应用程序处理能力的相关特性。根据用户应用程序的要求，可以运用下述特性技术：
l
数组处理
l
ORACLE 优化程序
l
行级锁管理器
l
PL/SQL
无论用户在编写新的SQL 语句，或是对应用程序中存在的疑问的语句进行优化，对数据库操作的优化本质上都是关心CPU,磁盘I/O等资源情况。下面是所作的步骤。
1．
查找最消耗资源的语句
利用诸如 TKPROF、SQL TRACE、SQL Analyze、Oracle trace 和Enterprise Manager Tuning Pack 等工具。可以查出存在问题的语句和存储过程。此外，用户还可以通过V$SORT_USAGE视图来查看与临时段关联的会话和SQL语句。
在优化工作中，最有可能提高性能的语句包括：
l
整体消耗资源最多的 语句
l
每行消耗资源最多的语句
l
执行频率高的语句
在V$SQLAREA视图中，用户可以发现仍然驻留在缓存的语句，这些语句进行了大量的磁盘I/O和缓存获取操作。
2
．对这些语句进行优化
需要记住的是，应用程序的设计情况是性能好坏的基础。对于低效的应用程序设计方案，不能通过SQL语句的优化来弥补它的不足。如果用户遭遇到SQL 语句的优化问题，那么也许就需要改应用程序设计方案。下面方法可以减少特定语句所消耗的资源：
l
使语句使用更少的资源
l
降低使用语句的频率
由于语句执行大量的事务处理
，或者其工作效率低下，或者两者兼而有之，就可能消耗大量的资源。用户可以不改程序，而是更改索引结构；或只需改变SQL 语句自身（不改环境逻辑）就可以完成任务。
为了确保数据库访问的效率，需要考虑使用簇、哈希簇、B*树索引、位图索引、以及优化程序提示。此外，还应当考虑对表进行分析，以及利用直方图表来分析。从而帮助优化程序确定最佳查询方案。
有效访问可能意味着增加索引，或增加特定应用程序的索引，随后再其撤消。还可能意味着建立数据库之后，再对设计结果进行再次分析。如果用户发现实际响应时间比必须响应时间要长，则需要寻找其他的方法来提高设计性能。
在ORACLE 8I ， 系统共享内存被动态地分配如下结构：
l
数据字典缓存
l
库缓存
l
上下文区域（如果运行多线程服务器）
用户可以设置下面内存结构：
l
缓冲区缓存
l
日志缓冲区
l
序列缓冲区
内存资源的适当分配可以提高缓存的性能，降低SQL语句的解析，同时可以减少分页（Paging）和叫换(Swapping)。
进程的本地区域包括：
l
上下文区域（如果运行多线程服务器）
l
排序区域
l
哈希区域
值得注意的是，对与大量的影响到分页和交换的机器物理内存。不要将其分配相同全局区（SGA）。
磁盘I/O 操作会降低软件应用程序的性能。优化I/O涉及到：
l
调度数据，以使I/O分配时避免磁盘争用问题
l
最佳访问方式是将数据存储在数据块中：将自由列表设定为合适的大小，以及恰当的PCTFREE和PCTUSED
l
为用户创建足够大的盘区，以避免表的动态扩展，它的负面影响到高容量OLTP应用程序的性能。
l
评测原设备（raw device）的使用情况。
对于多个ORACLE 并发请求，会产生对ORACLE资源的争应。应避免下面的争用发生：
l
块争用
l
共享池争用
l
锁争用
l
Pingping(并行环境)
l
锁存器（latch）争用
涉及以下方面：
l
UNIX 缓冲区的大小
l
逻辑卷管理器
l
内存使用及进程的大小
§1.2
应用优化方法
在没有建立明确的优化目标前，最好不要开始进行优化。“使其尽用户所能运转起来”听起来是一个目标，但
很难确定实际情况是否已达到了目标。
一个更有用的目标如下：我们需要20名操作员，每名每小时输入20条 命令，在30 分钟内必须组装列表。
此外，用户还应当记住，在获得目标后可能存在一些冲突。如为获得SQL语句的最佳性能，就会牺牲并发运行在数据库中的其他SQL语句性能。
用户应当创建一系列的最少可重复测试，如，如果用户却定某条SQL语句影响性能。那么就在SQL*PLUS 中（用SQL Trace 或ORACLE Trace）运行原始版本和 修订版本的语句，以便可通过察看统计结果发现性能的差别。
在创建了最少可重复测试后，可通过脚本来执行测试，可对结果进行汇总和报告。通过这种方法，用户可以对各种假设情况进行测试。
从ORACLE的缓存算法可以看出，当第一次把数据缓存到内存中，它的开销比以后（只从内存中访问数据）的都要大。因为第2次以后不需磁盘读数据到内存。
1.通过分析执行每个脚本及所得的结果记录，此外，用户还应当是测试自动化，有下列优点：
2.可以根据优化程序的能力，更快地对测试的效能进行计算。
3.由于每次测试所使用的设备相同，可保证测试体系方法的一致性。
无经验的人经常犯下面的错误：
l
受预先设想的见解影响较大；
l
随机进行各种方案的测试；
l
无目的、无依据的修改环境。
我们应该通过编写用户认为问题出处的描述，仔细
推敲分析过程，理清用户的思路，进而确定
错误所在
。还要请一些
对应用程序有较好了解
的人参与，验证
SQL语句优化程序，设计出解决方案。
另外，要避免解决方案以外的
奇怪的想法
，如，通过猜测方法来更改系统的参数，用户对这种做法要十分谨慎，否则做出了某种假设，而用户并没有对这种假设有完整的理解，却急于实现这种想法。于是草率行事。由此导致性能严重下降以至于用户只好从备份中恢复某些系统环境。再就是
避免偏见
。当定位优化问题的时候，要避免偏见，而要用户描述性能问题所在。但也不要期望用户确切知道问题所在。
Oracle数据库系统的安装与以后应用系统的运行有着密切的关系，如果一个中大型的应用系统没有充分设计和规划，而是采用默认的方法安装，则给以后应用系统的运行带来一定的影响。下面给出一些建议。
如果在分析阶段得到用户的初步资料，在与用户讨论确认之后就可以订购数据库服务器了。当数据库服务器到货后，就可以与操作系统人员一起规划服务器的操作系统的安装和Oracle数据库系统的安装等。
当数据库服务器在开箱后，就开始规划如何安装操作系统软件。因为一般的小型机或多数服务器机器在出厂后是不安装任何软件的。所有安装操作系统和其他所需要的软件都是在机器安装完成后由供应商进行的。
为了使所安装的操作系统能满足Oracle系统的基本要求，有的服务器的操作系统需要注意某些Oracle的要求：
l
操作交换区
交换区是Oracle的一项基本的要求。可以根据Oracle的发行要求来确定。一般交换区大小的要求是该服务器内存的2倍至4倍之间。过小的交换区可能导致Oracle系统安装的失败，所以建议交换区最好是内存的4倍为佳。
l
硬盘格式化的考虑
在安装操作系统时，安装程序回提示将硬盘化分为不同大小的部分。在安装操作系统时就开始考虑哪个硬盘是用来安装Oracle系统的，哪个是用来存放数据文件的等。建议用于存放Oracle数据库系统的目录一定比Oracle系统发行要求的2倍以上；其次就是考虑Oracle数据库系统的数据文件的目录所对应的硬盘的大小。Oracle系统所在硬盘最好不要与其他的软件混早一起。
当服务器平台已完成操作系统的安装后，就应该开始认真的考虑下面的问题：
l
操作系统的信号量
Oracle在某些UNIX操作系统环境下安装需要合适的操作系统信号量。应该根据Oracle版本发行的要求进行设置，比如在SUN 环境下，需要以root 登录并根据Oracle安装手册的参数要求修改/etc目录的system文件。然后在进行Oracle RDBMS的安装。
l
是否采用升级方案
如果应用是将旧的应用系统上进行升级的话，要考虑系统的性能问题。一般建议采用非升级安装，采用人工升级。因为系统自动升级安装会给应用带来性能问题。
l
安装类型方案
采用自定义安装进行Oracle数据库系统的安装，这样考虑根据需要定义包括字符集、数据库块的大小、数据文件的大小等。
l
安装点的考虑
Oracle的安装点就是指数据文件、日志文件和控制文件的安置路径，为了使系统在以后运行性能达到优化，建议将数据文件、日志文件和控制文件的安置路径与数据库系统存放在不同的路径上。最好将数据文件、日志文件和控制文件分别存放在不同的路径。
l
SYSTEM表空间对应数据文件
在自定义安装会话中，建议你根据需要设置system表空间所对应的数据文件的大小。一般要设置比默认值的2倍。该数据文件的大小最好是在300MB至500MB间。因为数据文件太小不利于系统的运行。
l
临时表空间对应的数据文件
临时表空间对应的数据文件可以根据将来系统存放的应用的处理情况来定。比如系统将来可能要经常进程排序处理，则需要设置较大的临时表空间，也可能需要再建立新的临时表空间。这里建议临时表空间的数据文件在100MB至300MB左右。
l
回滚段表空间对应的数据文件
如果是Oracle8i及以前的版本，则考虑为RBS表空间建立较大的数据文件。最好数据文件在300MB至500MB之间，如果不够在完成安装后再进行扩展。但是不要采用默认值。
l
日志文件的大小
日志文件的大小对于Oracle系统的运行也是相当重要。默认值是太小。建议日志文件大小在10MB至50MB左右。
l
控制文件的大小
如果是Oracle8及以上版本，控制文件文件除了存放数据文件信息和日志文件信息外，换存放恢复信息等。所以控制文件所在目录应该有足够的扩展空间。一般建议在该目录应该有200MB 以上空间。
l
数据库块的大小
如果你的应用系统是OLTP的话，可以采用较小的数据库块。如果是DSS类型的应用系统，则可以设置较大的数据库块，目前Oracle产品所允许的数据库块可以是2KB至64KB之间。无论你选择较大的块或较小的块，它的值都必须是2的整数倍，比如2048,4096,8192等。但需要注意的是，如果操作系统为64位，则可选择较大的块。
l
字符集的选择
字符集是Oracle系统专门支持的一项技术。详细请参考另外的章节。一般不要与另外的已经存放的Oracle系统的字符集产生冲突即可。但如果你的环境是一个新的平台，不需要与其它平台进行数据交换的话，建议选择默认的字符集。这样可以利于将来的修改。
一部分设计师和用户都这样认为，用户的应用系统有几个子系统，就应该建立几个数据库（实例）。将每个应用系统建立在一个独立的数据库（实例）上。这样的考虑主要是对Oracle系统的结构或工作方式不够了解造成。一般来说，如果用户的应用系统不是非常庞大，服务器的内存也有限，建议不要在同一台服务器上创建两个以上的数据库（实例）。因为每个数据库（实例）在启动后都回占用大量的内存和CPU时间。如果有多个不同的应用系统，只要分别为不同的应用系统建立的表空间即可。
§2.3 Oracle
系统安装后的优化基础工作
一般在安装成功后，管理员确认Oracle系统正常启动和关闭没有问题后，除了要修改SYS和SYSTEM帐户的口令外，最好还要做下面的工作：
将所有文件，特别是数据文件、控制文件几次日志文件的设置为不可删除的状态。避免任何人有意无意的删除。如果你的环境是UNIX操作系统，建议将所有文件设置为不可删除状态。
在修改了SYS和SYSTEM帐户的口令后，基本可避免任何人都可随意窗新用户的操作。这时，管理员自己应该在创建新用户时，一定要为用户指定默认表空间。
§2.4 Oracle
系统所在服务器的独立性
由于Oracle是一个消耗资源较大的大型软件系统，为了确保Oracle系统在运行期间不与其它的软件系统发生资源的竞争。建议将其它软件系统，包括Oracle9i的iAS软件，不要与Oracle系统所在的服务上安装这些软件。以保证服务器资源能满足Oracle系统的要求。
