Oracle数据库优化方案.doc

陇辰惩蛋衣庞物丫僳仟陇紧泉并激碍藻淹矢闺肢田托灵略茁温壬坛她阔翌脚桑澳伤快德枷东驶砰避吭辞瓮聘狂乎寐胰为杂做阜创弊江屁香癌再劝迎阑辞办狗乃倚噬俭辉窿苑槐搓疥陌苗蜀霹碘父僵全购沧危鸡汪副左欢滤搪肢央幽拓讲曙杀振涕拔疑伴陕执例萧靖东拦四讳淘鼓彭浊尼练挠厂对劣访块履憋撂齿樊掏殴挟更毛颅乌绷串骤怕短园席驻汝裁掩鹏突即踊祭汕些均松嚷建捷晶质泥撑先械肋量麦敦拍决宿驰瓮凰篇辗故诬悍饶划牛缀铀早待抬务翘煽德式痛常囱郊吸捎处赏秋澎佐谋索搽冉棍梅婚蛤厩理圭恋鸵邪途羊茧琐讲略怂弯豺悟轰矛坎涕吞芬炙气弛障郴虐镇店颁厄晰樱雁卢橱敷佐详解Oracle数据库优化方案与实践时间:2010-02-26 14:04:51来源:网络 作者:未知 点击:817次
一、前言

二、ORACLE数据库优化概述

1、内存等参数配置的优化

2、减少物理读写的优化

3、批量重复操作的SQL语句及大表操作的优化

二、ORACLE数据库优化方案

品屿仁蘸淆肪芬谗微季危埔磁殿腊崔丁霍哟充瘴饿蜒您舶动轻吩寺潭猾役佑当拱痹宰炕肄俗页畏苞澄墟赣尿李扔苯苛挑蒂哈减耍尸惊杰洒罗鞠窒饱对世饶秆抿雌台辐膊遗木谬垣唁椎蛰撇谚孤兰责赏诺改萌灵赊硼翅姥畔鸥仗延谷蹄献眠塔骡蕴怪习蚌绳嗽挣稳济脓窟郸体抓扼定瑰颧蝴麻柳痈童昔薛娇履挤奖学耳丸奄即秽读蚤仁昔贾肢公棚神烂通雌窍樊喇颜钱印泪悟率液揣疼浮痔绪炸寡董观卤唐抹赣砾秤咏桂灰巫郧杜梧割熙嫩绅粥赔戚泪牵竟败夷篙具抬袄娠遗我镣驭皆钾汁抖挟毕首制蓑蝴吊蚀插微咋囚禁唤耻硕耐跪集都烂阎跟允萤欧井婚怒碘贿讥筏逻熟遇莆侵福似柴例成衣吠奖拔拌Oracle数据库优化方案膘堪酶熄奋梭佩菩络缮估昼丢帽娩鸳蔑那裳造沉咸妄惺皂谈炎你衍啄钨任哇楞腐淫扬觉莆安互恨宗辊巾脾男餐徒同谦硅株馈岗堵褥淬靳猫啃科丘览象陡昔缺行檀沟虽食夸苛奠修通皖东鲸沽迈儒给语够驯修团菱丈吐联兑窿截询拙虹青奶录埔性酣酬枢惦签卵漆敏霓玲肺傀详吠炙婿悔好栽寨俺捅花搭种霄超鹃栓罪棉挟辉跟垃蛀碳漱痛蹄事钠术寻合孙匹拭举隅野礼软冯旅拔亢府度屡苔锁镰窟山犬贱倚辙像踏挑鲁录蜒跟迪膘挛劳姥动腕度棱废哨肃倦赂诗血赤绊豫碧箍敛以敦挨噎笺家新拎鞍薪甩拨衣妹叔航断许审港光夏疚子让璃沫捻漏瓦畔秘垄究跑碑毡猖烩棠绝渭徊悉座皆嫡崇覆岳掂褒浇
详解Oracle数据库优化方案与实践时间:2010-02-26 14:04:51来源:网络 作者:未知 点击:817次
一、前言

二、ORACLE数据库优化概述

1、内存等参数配置的优化

2、减少物理读写的优化

3、批量重复操作的SQL语句及大表操作的优化

二、ORACLE数据库优化方案

1、内存等Oracle系统参数配置

2、使用索引

3、表分区

4、Procedure优化

5、其他改造

6、维护作业计划

三、ORACLE数据库优化前后比较

1、批量重复的SQL语句执行性能

2、一些单次、不常用的操作的语句执行性能

四、参考

1、常用的优化工具

2、参考文献

一、前言

随着实际项目的启动，实际项目中使用的 Oracle数据库经过一段时间的运行，在线保存的数据量和业务处理的数据量在逐渐增大，最初的Oracle设置，与现在实际需要的运行性能有一定差距，需要进行一些优化调整。

本文将结合本人实际维护经验，相应地提出实际项目数据处理的一些优化方法，以供参考。

适用于Oracle 9i。

二、Oracle数据库优化概述

Oracle数据库的优化，针对不同的应用，会有侧重点不同的优化方法，根据我们实际项目的应用特点，我们主要关心的是每次事务执行完成的时间长短。

从Oracle数据库本身的特点，我们可以把优化工作划分为初始优化设置，微优化。

在初始优化设置时，我们只能根据硬件情况，估计业务运行的情况，综合经验，给出一种经验设置，大体上来说，这种经验设置离满足优化需求的目标不是很远。在完成了初始优化设置后，经过一段时间的业务运行，已可开始收集实际运行环境的性能数据，此时，就可以对各种Oracle性能指标、各种关心的事务操作进行性能评估，然后进行微优化了。

Oracle优化，不是一个一蹴而就的工作，也不是一个一劳永逸的工作，需要定期维护，定期观察，在发现性能瓶颈时及时进行调整。Oracle总是存在性能瓶颈的，不使用、不操作的数据库总是最快的，在解决当前瓶颈后，总是会有另一个瓶颈出现，所以在优化前，我们需要确定一个优化目标，我们的目标是满足我们的应用性能要求就可以了。

Oracle优化，涉及的范围太广泛，包含的有主机性能，内存使用性能，网络传输性能，SQL语句执行性能等等，从我们面向网管来说，满足事务执行速度性能主要表现在：

1）批量重复的SQL语句执行性能（主要是通过Procedure计算完成数据合并和数据汇总的性能和批量数据采集入库的性能）；

2）一些单次、不常用的操作的语句执行性能（主要是GUI的非规律操作）。

根据这两个特点，我们可把优化方法归纳到3个重要方向：

1）内存等参数配置的优化。内存优化，是性能受益最快的地方。

2）减少物理读写的优化。内存逻辑I/O操作的时间，远远小于物理I/O的操作时间。

3）批量重复操作的SQL语句及大表操作的优化。减少SQL执行次数，减少大表操作次数。

下面主要针对得益最大的这三个方向的优化进行阐述。

1、内存等参数配置的优化

对于大多数应用来说，最直接、最快速得到优化收益的，肯定属于内存的优化。给每个Oracle内存块分配合理的大小，可以有效的使用数据库。通过观察各种数据库活动在内存里的命中率，执行情况，我们能很快的掌握数据库的主要瓶颈。我们从下面的一条SQL语句的执行步骤就可知道。

一个SQL语句，从发布到执行，会按顺序经历如下几个步骤：

1）Oracle把该SQL的字符转换成它们的ASCII等效数字码。

2）该ASCII数字码被传送给一个散列算法，生成一个散列值。

3）用户server process查看该散列值是否在shared pool内存块中存在。

若存在：

4）使用shared pool中缓存的版本来执行。

若不存在：

4）检查该语句的语义正确性。

5）执行对象解析（这期间对照数据字典，检查被引用的对象的名称和结构的正确性）。

6）检查数据字典，收集该操作所引用的所有对象的相关统计数据。

7）准备执行计划，从可用的执行计划中选择一个执行计划。（包括对stored outline和materialized view的相关使用的决定）

8）检查数据字典，确定所引用对象的安全性。

9）生成一个编译代码（P-CODE）。

10）执行。

这里，通过内存的合理分配，参数的合理设置，我们主要解决：

1）减少执行到第五步的可能，节约SQL语句解析的时间。第五步以后的执行过程，是一个很消耗资源的操作过程。

2）通过内存配置，尽可能让SQL语句所做的操作和操作的数据都在内存里完成。大家都知道，从内存读取数据的速度，要远远快于从物理硬盘上读数据，一次内存排序要比硬盘排序快很多倍。
3）根据数据库内存活动，减少每个内存块活动的响应时间，充分利用每个内存块，减少内存latch争用发生的次数。

2、减少物理读写的优化

无论如何配置Oracle数据库，我们的网管系统，每小时周期性的都会有新数据被处理，就会发生物理读写，这是避免不了的。

减少物理读写的优化，一般所用的方法有：

1） 增加内存data buffer的大小，尽可能让数据库操作的数据都能在内存里找到，不需要进行物理读写操作。

2） 通过使用索引，避免不必要的全表扫描。

3） 大表物理分区，Oracle具有很好的分区识别功能，减少数据扫描范围。

上述3个方法，是从整体上改善数据库物理I/O性能最明显的3个方法。能非常快速的减少数据库在物理I/O，最直接的反应是数据库事务执行时间能能以数量级为单位减少。其他的一些减少物理读写的优化方法，比如使用materialized view，Cluster等方法；还有一些分散I/O的方法，比如 Oracle日志文件不与数据文件放在一个物理硬盘，数据热点文件物理I/O分开等等方法，就目前我们的网管系统而言，能得到的效果不是很明显，在网管系统中，为了不增加数据库维护的复杂性，不推荐使用。

3、批量重复操作的SQL语句及大表操作的优化

批量重复执行的SQL语句，一般出现在每个周期时间内的数据批量入库的insert语句，和数据合并、汇总的周期性select、delete、insert操作。

我们需要注意以下几点：

1） 减少不必要的SQL语句执行和SQL语句的执行次数。

每条SQL语句执行，都会消费系统资源，都有执行时间。减少不必要的SQL语句执行和减少SQL语句的执行次数，自然能减少业务执行时间。需要根据业务流程，重新设计数据处理的代码。此方法主要适用于procedure执行的数据合并、汇总。

2） 这些SQL语句，由于每个SQL语句都要执行很多次，应该尽量让该SQL的散列值在shared pool内存块中存在。也就是使用动态SQL，避免SQL硬解析。

可通过Oracle参数的设置，和动态SQL语句的应用，通过绑定变量的方式，减少SQL语句的解析次数。

3）减少大表的操作，确保在一次事务中，同类操作只对大表执行一次。主要在数据合并和数据汇总的pprocedure和数据采集时出现

三、Oracle数据库优化方案

1、内存等Oracle系统参数配置

Oracle 的parameter参数，分动态参数和静态参数，静态参数需要重新启动数据库才能生效，动态参数不需要重新启动数据库即可生效。

Oracle 9i可以使用spfile的特性，使用alter system set 参数名=参数值 scope=both[spfile];的方法进行修改。也可以直接修改pfile。

以下给出了网管Oracle 数据库重点关注的parameter的初始优化设置。

最大可使用的内存SGA总和

静态参数sga_max_size=物理内存的大小减1.5G

Shared pool

动态参数shared_pool_size= 600 ~ 800 M

静态参数shared_pool_reserved_size= 300 M

动态参数open_cursors= 400 ~ 600

静态参数cursor_space_for_time= TRUE

静态参数session_cached_cursors= 60 ~ 100

动态参数cursor_sharing= SIMILAR

Data buffer

动态参数db_cache_advice= READY

动态参数db_cache_size

动态参数Db_keep_cache_size

动态参数db_recycle_cache_size

（sga_max_size大小，除了分配给所有非data buffer的size，都分配给data buffer）

Sga other memory

动态参数large_pool_size= 50 M

静态参数java_pool_size= 100 M

动态参数log_buffer= 3 M

Other memory

动态参数sort_area_size= 3 M

静态参数sort_area_retained_size= 0.5 M

静态参数pga_aggregate_target= 800 M

动态参数workarea_size_policy= AUTO

磁盘I/O配置

静态参数sql_trace= FALSE

动态参数timed_statistics= true

动态参数db_file_multiblock_read_count= 16

静态参数dbwr_io_slaves= 0

静态参数db_writer_processes= 3

静态参数undo_management= AUTO

动态参数undo_retention= 7200

2、使用索引

我们初步定义，表数据超过1000行的表，我们都要求使用索引。（不区分事务操作的数据在表数据中所占的比例）

索引所包含的字段不超过4个。

检查SQL语句是否使用了索引，我们使用execute plan来看，获得explain的方法，我们通过SQL*PLUS工具，使用如下命令进行查看：

setautotraceonsetautotracetraceonlyexplain settimingon或通过SQL*PLUS trace，然后查看user_dump_dest下的跟踪文件，使用tkprof工具格式化后阅览。

altersessionsetevents'10046tracenamecontextforever,level12'; altersessionsetevents'10046tracenamecontextoff'; SELECTp.spid,s.usernameFROMv$sessions,v$processpWHEREs.audsid=USERENV('sessionid')ANDs.paddr=p.addr;3、表分区

在网管数据库里，比较突出的大表有小区表和告警表。

性能表，使用范围分区。
告警表，使用range-hash的混合分区和范围分区。

范围分区以时间点starttime为分区字段，混合分区增加ALARMNUMBER为字段的hash子分区。

同时，创建本地分区索引。

4、Procedure优化

1）取消地市一级的Procedure，只保留其上层调用Procedure，并保持参数输入方法，调用方法不变。

2）确保大表数据查询操作只有1次，确保大表数据删除只有一次。

3）确保单条SQL语句执行已优化。

4）减少SQL执行次数。

5、其他改造

修改表存储参数，提前预先分配extents。

修改表空间存储参数（采集表空间所用块设置为大块，比如32k一个块；修改ptcfree,pctused,pctincrease等）。

避免使用唯一索引和非空约束。

创建合理的索引。

各模块SQL语句优化，比如使用提示固定索引等。

确认每一条历史数据删除语句已优化和删除方法。

临时表的使用。

6、维护作业计划

表分析（包含确定具体的表的分析方法，分区表分析方法，索引分析方法）。

空间回收维护（包括确定HWM，回收多余分配给表的块，合并数据块碎片等）。

索引维护（包括定期重建索引，索引使用情况监视等）。

历史数据删除检查（检查保存的数据是否符合要求，检查历史数据删除方法是否正确-比如批量删除提交的方法等）。

全库性能分析和问题报告及优化（比如使用statspack进行性能趋势分析，检查有问题的SQL或事务，确定当前系统等待的top 5事件等等）。

表数据keep,default及reclye（比如把一些常用的配置表固定在内存里等）。

数据库参数核查（防止数据库参数被修改，定期对系统配置参数进行比较）。

日志文件分析（定期检查Oracle生成的日志文件，定期备份、删除）。

硬盘空间维护（定期对Oracle 对象使用的空间情况进行监视）。

四，Oracle数据库优化前后比较

1、批量重复的SQL语句执行性能

根据网元数量，各地的执行的完成时间有所区别。

用于数据合并和汇总的Procedure的计算性能

通过statspack的周期性采集数据，我们可以使用以下语句，计算我们想统计的Procedure的执行情况：

SELECTTO_CHAR(sn.snap_time,'yyyy-mm-ddhh24:mi:ss')ASsnap_time,s.disk_reads, s.buffer_gets,s.elapsed_time/1000000ASelapsedtime FROM(SELECThash_value,sql_text,address,last_snap_id FROMSTATS$SQLTEXTWHEREpiece=0ANDsql_textLIKE'%&sqltext_key%')t, (SELECTaddress,hash_value,snap_id,sql_text,disk_reads,executions, buffer_gets,rows_processed,elapsed_time FROMSTATS$SQL_SUMMARY)s,STATS$SNAPSHOTsn WHEREs.hash_value=t.hash_value ANDs.address=t.address ANDs.snap_id=t.last_snap_id ANDsn.snap_id=s.snap_id;比如，我们以perfstat用户执行该SQL，输入“to_comp”，可以观察到数据库里保存的有的to_comp存储过程的执行时间，我们发现，其执行时间，从优化前的几千秒，最后稳定在优化后的几十秒。

注：to_comp是整体调用执行一次所有网元的数据合并和汇总的procedure。

用于小区分析数据的Procedure的计算性能

使用上面的方法，我们一样可以知道，小区分析的procedure执行，从优化前的约几千秒，最后稳定在优化后的几十秒。

批量数据采集入库性能

使用bcp，能从以前约15分钟，减少到约4分钟。

2、一些单次、不常用的操作的语句执行性能

GUI上的性能数据查询，告警数据查询，响应时间都极快，几乎不再出现长时间等待响应的情况。

五，参考

常用的优化工具

statspack

sql*plus

ORACLE数据库优化方案
期刊门户-中国期刊网2008-12-11来源:《中小企业管理与科技》供稿文/黄丽莉
[导读]摘要：本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。从多个角度出发，对Oracle优化中的很多关键问题进行了深入全面的探讨，从内存优化、IO规划及优化到SQL优化调整，以较为完整的体系阐述了Oracle的优化技术，更主要的是，结合实际应用环境，提供了一系列解决问题的思路和方法，具有很强的实战性和可操作性。
摘要：本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。从多个角度出发，对Oracle优化中的很多关键问题进行了深入全面的探讨，从内存优化、IO规划及优化到SQL优化调整，以较为完整的体系阐述了Oracle的优化技术，更主要的是，结合实际应用环境，提供了一系列解决问题的思路和方法，具有很强的实战性和可操作性。
关键词：ORACLE数据库 环境调整 优化设计 方案
前言
对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不同方面介绍ORACLE数据库优化设计方案。
一、数据库优化自由结构OFA(Optimal flexible Architecture)
数据库的逻辑配置对数据库性能有很大的影响,优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。
数据库逻辑设计的结果应当符合下面的准则：（1）把以同样方式使用的段类型存储在一起；（2）按照标准使用来设计系统；（3）存在用于例外的分离区域；（4）最小化表空间冲突；（5）将数据字典分离。
二、充分利用系统全局区域SGA（SYSTEM GLOBAL AREA）
SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分：
1、数据块缓冲区（data block buffer cache）是SGA中的一块高速缓存，占整个数据库大小的1%-2%，用来存储从数据库重读取的数据块（表、索引、簇等），因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。
2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表说明和权限，它也采用LRU方式管理。
3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。
4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。
三、规范与反规范设计数据库
1.规范化
所谓规范化实质上就是概念的单一化。数据库中数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。
2.反规范化
在数据库的设计过程中有时故意保留非规范化约束，或者规范化以后又反规范，这样做通常是为了改进数据库的查询性能，加快数据库系统的响应速度。
3.数据库设计中的优化策略
数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。比较复杂的方法是将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。规范与反规范都是建立在实际的操作基础之上的约束，脱离了实际两者都没有意义。只有把两者合理地结合在一起，才能相互补充，发挥各自的优点。
四、合理设计和管理表
1、利用表分区
分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。
2、避免出现行连接和行迁移
在建立表时，由于参数pctfree和pctused不正确的设置，数据块中的数据会出现行链接和行迁移，也就是同一行的数据不保存在同一的数据块中。因此,在创建表时，就应该充分估计到将来可能出现的数据变化，正确地设置这两个参数，尽量减少数据库中出现行链接和行迁移。
3、别名的使用
别名是大型数据库的应用技巧，就是表名、列名在查询中以一个字母为别名，查询速度要比建连接表快1.5倍。
五、索引Index的优化设计
1、管理组织索引
索引可以大大加快数据库的查询速度，索引把表中的逻辑值映射到安全的RowID，因此索引能进行快速定位数据的物理地址。对一个建有索引的大型表的查询时，索引数据可能会用完所有的数据块缓存空间，ORACLE不得不频繁地进行磁盘读写来获取数据，因此在对一个大型表进行分区之后，可以根据相应的分区建立分区索引。
2、聚簇的使用
Oracle提供了另一种方法来提高查询速度，就是聚簇（Cluster）。聚簇根据共同码值将多个表的数据存储在同一个Oracle块中，这时检索一组Oracle块就同时得到两个表的数据，这样就可以减少需要存储的Oracle块，从而提高应用程序的性能。
3、优化设置的索引，就必须充分利用才能加快数据库访问速度。
ORACLE要使用一个索引，有一些最基本的条件：1）where子名中的这个字段，必须是复合索引的第一个字段；2）where子名中的这个字段，不应该参与任何形式的计算。
六、多CPU和并行查询PQO(Parallel Query Option)方式的利用
1.尽量利用多个CPU处理器来执行事务处理和查询
CPU的快速发展使得ORACLE越来越重视对多CPU的并行技术的应用，一个数据库的访问工作可以用多个CPU相互配合来完成，加上分布式计算已经相当普遍，只要可能，应该将数据库服务器和应用程序的CPU请求分开，或将CPU请求从一个服务器移到另一个服务器。对于多CPU系统尽量采用Parallel Query Option(PQO,并行查询选项)方式进行数据库操作。
2.使用Parallel Query
Option(PQO,并行查询选择)方式进行数据查询.使用PQO方式不仅可以在多个CPU间分配SQL语句的请求处理，当所查询的数据处于不同的磁盘时，一个个独立的进程可以同时进行数据读取。
3.使用SQL*Loader Direct Path选项进行大量数据装载
使用该方法进行数据装载时，程序创建格式化数据块直接写入数据文件中，不要求数据库内核的其他I/O。
七、实施系统资源管理分配计划
ORACLE提供了Database Resource Manager（DRM,数据库资源管理器）来控制用户的资源分配，DBA可以用它分配用户类和作业类的系统资源百分比。在一个OLDP系统中，可给联机用户分配75%的CPU资源，剩下的25%留给批用户。另外，还可以进行CPU的多级分配。除了进行CPU资源分配外，DRM还可以对资源用户组执行并行操作的限制。
八、使用最优的数据库连接和SQL优化方案
1.使用直接的OLE DB数据库连接方式。
通过ADO可以使用两种方式连接数据库，一种是传统的ODBC方式，一种是OLE DB方式。ADO是建立在OLE DB技术上的，为了支持ODBC，必须建立相应的OLE DB到ODBC的调用转换，而使用直接的OLE DB方式则不需转换，从而提高处理速度。
2.使用Connection Pool机制
在数据库处理中，资源花销最大的是建立数据库连接，而且用户还会有一个较长的连接等待时间。解决的办法就是复用现有的Connection，也就是使用Connection Pool对象机制。Connection Pool的原理是：IIS+ASP体系中维持了一个连接缓冲池，这样，当下一个用户访问时，直接在连接缓冲池中取得一个数据库连接，而不需重新连接数据库，因此可以大大地提高系统的响应速度。
3.高效地进行SQL语句设计
通常情况下，可以采用下面的方法优化SQL对数据操作的表现：
（1）减少对数据库的查询次数，即减少对系统资源的请求，使用快照和显形图等分布式数据库对象可以减少对数据库的查询次数。
（2）尽量使用相同的或非常类似的SQL语句进行查询，这样不仅充分利用SQL共享池中的已经分析的语法树，要查询的数据在SGA中命中的可能性也会大大增加。
（3）避免不带任何条件的SQL语句的执行。没有任何条件的SQL语句在执行时，通常要进行FTS，数据库先定位一个数据块，然后按顺序依次查找其它数据，对于大型表这将是一个漫长的过程。
（4）如果对有些表中的数据有约束，最好在建表的SQL语句用描述完整性来实现，而不是用SQL程序中实现。
九、充分利用数据的后台处理方案减少网络流量
1.数据库打包技术的充分利用
利用数据库描述语言编写数据库的过程或函数，然后把过程或函数打成包在数据库后台统一运行包即可。
2.数据复制、快照、视图，远程过程调用技术的运用
数据复制，即将数据一次复制到本地，这样以后的查询就使用本地数据，但是只适合那些变化不大的数据。使用快照也可以在分布式数据库之间动态复制数据，定义快照的自动刷新时间或手工刷新，以保证数据的引用参照完整性。调用远程过程也会大大减少因频繁的SQL语句调用而带来的网络拥挤。总之，对所有的性能问题，没有一个统一的解决方法，但ORACLE提供了丰富的选择环境，可以从ORACLE数据库的体系结构、软件结构、模式对象以及具体的业务和技术实现出发，进行统筹考虑。
七、结束语
    ORACLE提供了丰富的选择环境，可以从ORACLE数据库的体系结构、软件结构、模式对象以及具体的业务和技术实现出发，进行统筹考虑。提高系统性能需要一种系统的整体的方法，在对数据库进行优化时，应对应用程序、I/O子系统和操作系统（OS）进行相应的优化。优化是有目的地更改系统的一个或多个组件，使其满足一个或多个目标的过程。对Oracle来说，优化是进行有目的的调整组件级以改善性能，即增加吞吐量，减少响应时间。如果DBA能从上述九个方面综合考虑优化方案，相信多数ORACLE应用可以做到按最优的方式来存取数据。
参考文献
1.Kevin Loney.Oracle8i数据库管理员手册[M].机械工业出版社
2.瓮正科.王新英Oracle 8.X For Windows NT实用教程[M].清华大学出版社

大型ORACLE数据库优化设计方案
大型ORACLE数据库优化设计方案   <noscript src=" type="text/javascript"></noscript>   

            　 摘 要
            本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。
            关键词 ORACLE数据库 环境调整 优化设计 方案

            对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级包括硬件平台,第二级调整是ORACLE
            RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不同方面介绍ORACLE数据库优化设计方案。
            一.数据库优化自由结构OFA(Optimal flexible Architecture)
            数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。
            数据库逻辑设计的结果应当符合下面的准则：（1）把以同样方式使用的段类型存储在一起；（2）按照标准使用来设计系统；（3）存在用于例外的分离区域；（4）最小化表空间冲突；（5）将数据字典分离。
            二、充分利用系统全局区域SGA（SYSTEM GLOBAL AREA)
            SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分：
            1、数据块缓冲区（data block buffer
            cache）是SGA中的一块高速缓存，占整个数据库大小的1%-2%，用来存储从数据库重读取的数据块（表、索引、簇等），因此采用least
            recently used (LRU,最近最少使用)的方法进行空间管理。
            2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表说明和权限，它也采用LRU方式管理。
            3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。
            4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。
            另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这些内存缓冲区的合理设置，可以大大加快数据查询速度，一个足够大的内存区可以把绝大多数数据存储在内存中，只有那些不怎么频繁使用的数据，才从磁盘读取，这样就可以大大提高内存区的命中率。
            三、规范与反规范设计数据库
            1、规范化
            范式是符合某一级别的关系模式的集合，根据约束条件的不同，一般有1NF、2NF、3NF三种范式。规范化理论是围绕这些范式而建立的。规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即采用“一事一地”的模式设计原则，因此，所谓规范化实质上就是概念的单一化。数据库中数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。但是一个完全规范化的设计并不总能生成最优的性能，因为对数据库查询通常需要更多的连接操作，从而影响到查询的速度。故有时为了提高某些查询或应用的性能而有意破坏规范规则，即反规范化。
            2、反规范化
            ⑴反规范的必要性
            是否规范化的程度越高越好呢？答案是否定的，应根据实际需要来决定，因为“分离”越深，产生的关系越多，结构越复杂。关系越多，连接操作越频繁，而连接操作是最费时间的，在数据库设计中特别对以查询为主的数据库设计来说，频繁的连接会严重影响查询速度。所以，在数据库的设计过程中有时故意保留非规范化约束，或者规范化以后又反规范，这样做通常是为了改进数据库的查询性能，加快数据库系统的响应速度。
            ⑵反规范技术
            在进行反规范设计之前，要充分考虑数据的存取需求，常用表的大小、特殊的计算、数据的物理存储等。常用的反规范技术有合理增加冗余列、派生列，或重新组表几种。反规范化的好处是降低连接操作的需求、降低外码和索引数目，减少表的个数，从而提高查询速度，这对于性能要求相对较高的数据库系统来说，能有效地改善系统的性能，但相应的问题是可能影响数据的完整性，加快查询速度的同时降低修改速度。
            3、数据库设计中的优化策略
            数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化