Oracle数据库常见的瓶颈问题与性能监测工具

1、内容摘要：数据库系统的性能最终了决定数据库的可用性和生命力。大多数数据库系统在运行一段时刻后都会存在一定的性能问题，要紧涉及数据库硬件、数据库服务器、数据库内存、应用程序、操作系统、数据库参数等方面。因此，基于数据库系统的性能调整与优化关于整个系统的正常运行起着至关重要的作用。数据库性能调整与优化涉及到多个层面，通过统一规划、系统分析做出相应的调整，能够提高数据库的稳定性和可用性，保障系统高效地运行，解决系统瓶颈，节约系统开销，具有良好的应用价值，同时也对理论研究提供了一定的方法指导。基于此，论文将Oracle 10g数据库的内存分配、磁盘I/O以及SQL语句等方面的性能调整与优化问题作为要紧

2、研究内容，对其进行了深入地分析和讨论，给出了一般情况下Oracle数据库应用系统的性能调整策略及优化方法。关键词：Oracle 10g 数据库；体系结构；系统全局区；性能调整与优化 AbstractAbstract: The performance of database systems eventually determines their availability and survivability. Most of them will bring about some performance problems more or less after running for a period

3、 of time, which mainly involve database hardware, database server, database memory, applications, operating systems and database parameters, etc. Therefore,performance tuning and optimization of database systems,which concern multiple aspects, are very vital to the normal running of the whole system

4、. We can improve the stability and availability of database, guarantee its high running efficiency, solve system bottleneck, reduce system overhead, obtain considerable applicability and in them meanwhile, provide some guidelines for theoretical research through a unified plan and systematical analy

5、sis to make appropriate adjustment.Based on the above-mentioned idea, the paper principally pays attention to the research on the performance tuning and optimization problems of memory allocation of Oracle 10g, disc I/O, SQL statements, etc, and makes a further analysis and discuss. Besides, it prov

6、ides some performance tuning strategies and optimization approaches of Oracle application system in general condition. Key Words: Oracle 10g Database不Architecture不System Global Area不 Adjustment and Optimization of Performance1 导言网格技术是本世纪初最新和最有吸引力的技术之一，数据库治理系统作为信息系统的差不多支撑在信息化建设中扮演着重要的要色。目前的Oracle 10g

7、数据库是业界首个为网格计算而设计的数据库，是一种高效率、可靠性好的适应高吞吐量的数据库解决方案，该方案可让客户将多台标准服务器系统整合成一套可扩充的容错运算平台。然而，随着数据库规模的扩大及用户数量的增加，数据库应用系统的响应速度下降，性能问题越来越突出。Oracle 10g数据库系统体系结构庞大、技术细节繁杂，如何合理有效地建立基于Oracle的数据库系统及如何调整使系统性能达到最优，成为Oracle数据库应用领域的热点问题。本课题通过对Oracle 10g数据库系统的深入分析，设计一套完整的Oracle数据性能评测指标和方法，并针对发觉的性能问题制定相应的性能优化策略。 2 Oracle

8、10g体系结构Oracle数据治理系统是Oracle实例(Instance)和Oracle数据库构成的。下面是Oracle 10g数据库的体系结构图：图1 Oracle 10g数据库体系结构2.1 ORACLE实例Oracle 实例包括系统全局共享区System Global Are 和后台进程Background Process。2.1.1 系统全局共享区System Global Area(SGA)System Global Area 是一块巨大的共享内存区域，他被看做是Oracle 数据库的一个大缓冲池，那个地点的数据能够被ORACLE的各个进程共用1。其大小能够通过如下语句查看：SQL

9、 select * from v$sga;NAME VALUE- -Fixed Size 39816Variable Size 259812784Database Buffers 1.049E+09Redo Buffers 327680要紧包括以下几个部分： 共享池(Shared pool)共享池是SGA中最关键的内存片段，特不是在性能和可伸缩性上。一个太小的共享池会扼杀性能，使系统停止，太大的共享池也会有同样的效果，将会消耗大量的CPU来治理那个共享池。不正确的使用共享池只会带来灾难。共享池要紧又能够分为以下两个部分：（1）SQL语句缓冲(Library Cache)当一个用户提交一个SQL

10、语句，Oracle会将这句SQL进行分析(parse)，那个过程类似于编译，会耗费相对较多的时刻。在分析完那个SQL，Oracle会把他的分析结果给保存在Shared pool的Library Cache中，当数据库第二次执行该SQL时，Oracle自动跃过那个分析过程，从而减少了系统运行的时刻。这也是什么缘故第一次运行的SQL 比第二次运行的SQL要慢一点的缘故。下面举例讲明parse的时刻SQL select count(*) fromscpass ;COUNT(*)-243Elapsed: 00:00:00.08这是在Share_pool 和Data buffer 都没有数据缓冲区的情况

11、下所用的时刻SQL alter system flush SHARED_POOL;System altered.清空Share_pool，保留Data bufferSQL select count(*) from scpass ;COUNT(*)-243Elapsed: 00:00:00.02SQL select count(*) from scpass ;COUNT(*)-243Elapsed: 00:00:00.00从两句SQL 的时刻差上能够看出该SQL 的Parse 时刻约为00:00:00.02。关于保存在共享池中的SQL语句，能够从V$Sqltext、v$Sqlarea中查询到，关

12、于编程者来讲，要尽量提高语句的重用率，减少语句的分析时刻。一个设计的差的应用程序能够毁掉整个数据库的Share pool，提高SQL语句的重用率必须先养成良好的变成适应，尽量使用Bind变量。（2）数据字典缓冲区(Data Dictionary Cache)显而易见，数据字典缓冲区是ORACLE特地为数据字典预备的一块缓冲池，供ORACLE内部使用。 块缓冲区高速缓存(Database Buffer Cache)这些缓冲是对应所有数据文件中的一些被使用到的数据块。让他们能够在内存中进行操作。在那个级不里没有系统文件，户数据文件，临时数据文件，回滚段文件之分。也确实是任何文件的数据块都有可能被缓

13、冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘2。那个缓冲区的块差不多上在两个不同的列表中治理。一个是块的“脏”表(Dirty List)，需要用数据库块的书写器(DBWR)来写入，另外一个是不脏的块的列表(Free List)，一般的情况下，是使用最近最少使用 (Least Recently Used,LRU)算法来治理。块缓冲区高速缓存又能够细分为以下三个部分（Default pool,Keep pool,Recycle pool）。假如不是人为设置初始化参数(Init.ora)，ORACLE将默认为Default pool。由于操作系统寻址能力的限制，不通过

14、专门设置，在32位的系统上，块缓冲区高速缓存最大能够达到1.7G，在64位系统上，块缓冲区高速缓存最大能够达到10G。 重做日志缓冲区(Redo log buffer)重做日志文件的缓冲区，对数据库的任何修改都按顺序被记录在该缓冲，然后由LGWR进程将它写入磁盘。这些修改信息可能是DML语句，如(Insert,Update,Delete)，或DDL语句，如(Create,Alter,Drop等)。 重做日志缓冲区的存在是因为内存到内存的操作比较内存到硬盘的速度快专门多，因此重作日志缓冲区能够加快数据库的操作速度，然而考虑的数据库的一致性与可恢复性，数据在重做日志缓冲区中的滞留时刻可不能专门长。

15、因此重作日志缓冲区一般都专门小，大于3M之后的重作日志缓冲区差不多没有太大的实际意义。 Java程序缓冲区(Java Pool)Java 的程序区，Oracle 8I 以后，Oracle 在内核中加入了对Java的支持。该程序缓冲区确实是为Java 程序保留的。假如不用Java程序没有必要改变该缓冲区的默认大小。 大池(Large Pool)大池的得名不是因为大，而是因为它用来分配大块的内存，处理比共享池更大的内存，下面对象使用大池：MTS在SGA的Large Pool中分配UGA。语句的并行查询(Parallel Execution of Statements)同意进程间消息缓冲区的分配，用

16、来协调并行查询服务器。备份(Backup)用于RMAN磁盘I/O缓存。2.1.2 后台进程(Background process)后台进程是Oracle的程序，用来治理数据库的读写，恢复和监视等工作。Server Process要紧是通过他和user process进行联系和沟通，并由他和user process进行数据的交换。在Unix机器上，Oracle后台进程相关于操作系统进程，也确实是讲，一个Oracle后台进程将启动一个操作系统进程；在Windows机器上， Oracle后台进程相关于操作系统线程，打开任务治理器，我们只能看到一个ORACLE.EXE的进程，然而通过另外的工具，就能够

17、看到包含在那个地点进程中的线程。在Unix上能够通过如下方法查看后台进程：ps ef | grep ora_# ps -ef | grep ora_ | grep XCLUATOracle 29431 1 0 Sep 022:02 ora_dbwr_SIDOracle 29444 1 0 Sep 020:03 ora_ckpt_SIDOracle 29448 1 0 Sep 022:42 ora_smon_SIDOracle 29442 1 0 Sep 023:25 ora_lgwr_SIDOracle 29427 1 0 Sep 020:01 ora_pmon_SID Oracle系统有5个

18、差不多进程他们是DBWR(数据文件写入进程)LGWR(日志文件写入进程)SMON(系统监护进程)PMON(用户进程监护进程)CKPT(检查点进程,同步数据文件，日志文件，操纵文件)（1）DBWR（Database Writer 数据写入进程）将数据缓冲区的数据写入数据文件，是负责数据缓冲区治理的一个后台进程。当数据缓冲区中的一数据被修改后，就标记为dirty，DBWR进程将数据缓冲区中“脏”数据写入数据文件，保持数据缓冲区的“洁净”。由于数据缓冲区的数据被用户修改并占用，空闲数据缓冲区会不断减少，当用户进程要从磁盘读取数据块到数据缓冲区却无法找到足够的空闲数据缓冲区时，DBWR将数据缓冲区内容

19、写入磁盘，使用户进程总能够得到足够的空闲数据缓冲区。DBWR的作用：治理数据缓冲区，以便用户进程总能够找到足够的空闲缓冲区。将所有修改后的缓冲区数据写入数据文件。使用LRU（最近最少使用）算法保持缓冲区数据是最近经常使用的。通过延迟写来优化磁盘I/O读写。（2）LGWR（Log Writer 日志写入进程）将日志数据从日志缓冲区写入磁盘日志文件组。数据库在运行时，假如对数据库进行修改则产生日志信息，日志信息首先产生于日志缓冲区。当日志达到一定数量时，由LGWR将日志数据写入到日志文件组，再通过日志切换, 由归档进程（ARCH）将日志数据写入归档进程（前提是数据库运行在归档模式下）。数据库遵循写

20、日志优先原则，即在写数据之前先写日志。（3）SMON工作要紧包含：清除临时空间在系统启动时，完成系统实例恢复聚结空闲空间从不可用的文件中恢复事务的活动OPS中失败节点的实例恢复清除OBJ$表缩减回滚段使回滚段脱机（4）PMON要紧用于清除失效的用户进程，释放用户进程所用的资源。如PMON将回滚未提交的工作，释放锁，释放分配给失败进程的SGA资源。（5）CKPT同步数据文件，日志文件和操纵文件，由于DBWR/LGWR的工作原理，造成了数据文件，日志文件，操纵文件的不一至，这就需要CKPT进程来同步。CKPT会更新数据文件/操纵文件的头信息。CKPT工作的要紧条件如下：a.在日志切换的时候。b.数

21、据库用Immediate ,Transaction , Normal 选项Shutdown 数据库的时候。c.依照初始化文件LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_IO_TARGET、的设置数值来确定。d.用户触发。 以下进程的启动需要手工配置（1）ARCH当数据库以归档方式运行的时候，Oracle会启动ARCH进程，当重做日志文件被写满时，日志文件进行切换，旧的重做日志文件就被ARCH进程复制到一个/多个特定的目录/远程机器。这些被复制的重做日志文件被叫做归档日志文件。（2）RECO负责解决分布事物中的故障。Orac

22、le能够连接远程的多个数据库，当由于网络问题，有些事物处于悬而未决的状态。RECO进程试图建立与远程服务器的通信，当故障消除后，RECO进程自动解决所有悬而未决的会话。（3）服务进程Server Process服务进程的分类：专用服务进程(Dedicated Server Process)一个服务进程对应一个用户进程共享服务进程(MultiTreaded Server Process)一个服务进程对应多个用户进程，轮流为用户进程服务。PGA & UGAPGA = Process Global AreaUGA = User Global Area他保存了用户的变量、权限、堆栈、排序空间等用户信息

23、，关于专用服务器进程，UGA在PGA中分配。关于多线程进程，UGA在Large pool中分配。（4）用户进程User Process在客户端，将用户的SQL 语句传递给服务进程2.2 ORACLE 数据库ORACLE数据库的组成物理操作系统文件的集合。要紧包括以下几种。2.2.1 操纵文件（参数文件init.ora记录了操纵文件的位置）操纵文件包括如下要紧信息：数据库的名字，检查点信息，数据库创建的时刻戳，所有的数据文件，联机日志文件，归档日志文件信息，备份信息等。有了这些信息，Oracle就明白那些文件是数据文件，现在的重做日志文件是哪些，这些差不多上系统启动和运行的差不多条件，因此他是O

24、racle运行的全然。假如没有操纵文件系统是不可能启动的。操纵文件是特不重要的，一般采纳多个镜相复制来爱护操纵文件，或采纳RAID来爱护操纵文件。操纵文件的丢失，将使数据库的恢复变的专门复杂。操纵文件信息能够从V$Controlfile中查询获得。2.2.2 数据文件（数据文件的详细信息记载在操纵文件中）能够通过如下方式查看数据文件SQL select name from v$datafile;NAME-/u05/dbf/PROD/system_01.dbf/u06/dbf/PROD/temp_01.dbf/u04/dbf/PROD/users_01.dbf/u09/dbf/PROD/rbs_

25、01.dbf/u06/dbf/PROD/applsys_indx_01.dbf/u05/dbf/PROD/applsys_data_01.dbf从以上能够看出，数据文件大致能够分为以下几类： 系统数据文件(system_01.dbf)存放系统表和数据字典，一般不放用户的数据，然而用户脚本，如过程，函数，包等却是保存在数据字典中的。（数据字典是一些系统表或视图，他存放系统的信息，他包括数据库版本，数据文件信息，表与索引等段信息，系统的运行状态等各种和系统有关的信息和用户脚本信息。数据库治理员能够通过对数据字典的查询，就能够了解到Oracle的运行状态。） 回滚段文件(rbs_01.dbf)假如数

26、据库进行对数据的修改，那么就必须使用回滚段，回滚段是用来临时存放修改前的数据(Before Image)。回滚段通常都放在一个单独的表空间上（回滚表空间），幸免表空间碎片化，那个表空间包含的数据文件确实是回滚数据文件。 临时数据文件(temp_01.dbf)要紧存放用户的排序等临时数据，与回滚段相似，临时段也容易引起表空间碎片化，而且没有方法在一个永久表空间上开发临时段，因此就必须有一个临时表空间，它所包含的数据文件确实是临时数据文件，要紧用于不能在内存上进行的排序操作。我们必须为用户指定一个临时表空间。 用户数据文件(/applsys_data_01.dbf ,applsys_indx_01

27、.dbf)存放用户数据，那个地点列举了两类常见的用户型数据，一般数据和索引数据，一般来讲，假如条件许可的话，能够考虑放在不同的磁盘上。2.2.3 用户对数据库进行的任何操作都会记录在重做日志文件。在了解重做日志之前必须了解重做日志的两个概念，重做日志组和重做日志组成员(Member)，一个数据库中至少要有两个日志组文件，一组写完后再写另一组，即轮流写。每个日志组中至少有一个日志成员，一个日志组中的多个日志成员是镜相关系，有利于日志文件的爱护，因为日志文件的损坏，特不是当前联机日志的损坏，对数据库的阻碍是巨大的。联机日志组的交换过程叫做切换，需要特不注意的是，日志切换在一个优化效果不行的数据库中

28、会引起临时的“挂起”。通过v$log能够查看日志组，v$logfile能够查看具体的成员文件。2.2.4 Oracle能够运行在两种模式之中，归档模式和不归档模式4。假如不用归档模式，因此，就可不能有归档日志，然而，系统将可不能是一个有用系统，特不是不能用于生产系统，因为此系统可能会丢失数据。然而在归档模式中，为了保存用户的所有修改，在重做日志文件切换后和被覆盖之间系统将他们另外保存成一组连续的文件系列，该文件系列确实是归档日志文件。有人或许会讲，归档日志文件占据了用户大量的硬盘空间，然而具体想一想，用户是情愿白费一点磁盘空间来爱护数据，依旧情愿丢失数据呢？显而义见，我们需要保证我们的数据的安

29、全性。事实上，归档并不是一直占据用户的磁盘空间，用户能够把它备份到磁带上，或则删除上一次完整备份前的所有日志文件。2.2.5 initSID.ora或init.ora文件，因为版本的不一样，其位置也可能会不一样。初始化文件记载了许多数据库的启动参数，如内存，操纵文件，进程数等，在数据库启动的时候加载（Nomount时加载），初始化文件记录了专门多重要参数，对数据库的性能阻碍专门大。2.2.6 密码文件用于Oracle 的具有sysdba权限用户的认证. 其它日志文件（1）报警日志文件（alert.log或alrt.ora）记录数据库启动，关闭和一些重要的出错信息。数据库治理员应该经常检查那个文

30、件，并对出现的问题作出即使的反应。能够通过以下SQL 找到他的路径select value from v$PARAMETERwhere name =background_dump_dest;（2）后台或用户跟踪文件系统进程或用户进程出错前写入的信息，一般不可能读明白，能够通过ORACLE的TKPROF工具转化为能够读明白的格式。关于系统进程产生的跟踪文件与报警日志文件的路径一样，用户跟踪文件的路径，你能够通过以下SQL找到他的路径select value from v$PARAMETER where name =user_dump_dest;3 Oracle数据库常见的瓶颈问题Oracle 数

31、据库系统提供了相应的应用工具，治理人员能够方便地对Oracle进行有效的治理。从而建立一个良好的环境，使系统发挥最大的效能5。然而，有时用户依旧抱怨系统运行速度慢，对用户查询反应的时刻长，即出现所谓的瓶颈效应。这就需要治理人员对Oracle进行调整。在Oracle系统中比较常见的瓶颈出现在以下部件中：3.1 中央处理器(CPU)CPU是计算机在运行中最重要的部分，假如CPU总是运行在极限速度下，那么我们讲CPU成为系统的瓶颈，尤其在多用户同时使用系统时，CPU的计算能力尤为重要。尽管多数情况下，差不多上由操作系统的内核来治理分配有效的CPU给RACLE数据库进程使用。然而，仍然会出现过多的应用

32、进程对CPU使用周期激烈竞争的现象。3.2 内存内存是计算机程序运行的场所，处于等待状态数据和请求信息也都存放在内存中。假如内存不足，cache(高速缓存区)的命中率就可不能太高，大部分所需数据不在cache中，因此出现了瓶颈问题。3.3 存储设备诸如硬盘驱动器、CD-ROM等设备，用于存储系统所需信息，计算机系统每秒能处理的最大I/O数量是固定的，当CPU和内存要求的I/O速度大于系统的速率时，存储设备的瓶颈就会发生。3.4 网络当网络负担太重，网络部件速度跟不上，不可能把数据传输得更快，网络瓶颈就会发生。3.5 其它由于其它系统硬件或软件的缘故而导致的瓶颈，如应用系统本身的设计问题，超出系

33、统吞吐量(在一定时刻内系统处理数据的能力)的限制等造成的瓶颈。关于Oracle数据库系统的存在的瓶颈问题的解决，事实上最终依旧归结为数据库性能优化问题。实际上，为了保证ORACLE数据库运行在最佳的性能状态下，在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、ORACLE数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面，其中应用程序的分析与设计是在信息系统开发之前完成的。分析评价ORACLE数据库性能要紧有数据库吞吐量、数据库用户响应时刻两项指标6。数据库吞吐量是指单位时刻内数据库完成的SQL语句数目：数据库用户响应时刻是指用户从提交SQ

34、L语句开始到获得结果的那一段时刻。数据库用户响应时刻又能够分为系统服务时刻和用户等待时刻两项，即：数据库用户响应时刻=系统服务时刻 + 用户等待时刻，上述公式告诉我们，获得中意的用户响应时刻有两个途径：一是减少系统服务时刻，即提高数据库的吞吐量：二是减少用户等待时刻，即减少用户访问同一数据库资源的冲突率。4 CPU参数的调整CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时C使用率在90%以上。假如空闲时刻CPU使用率就在90%以上，讲明服务器缺资源，假如工作高峰时CPU使用率仍然专门低，讲明服务器CPU资源还比较富玉。使用操作相同命令能够看到CPU的使用情况，一般UNLK操作系

35、统的服能够使用sar一命令查看CPU的使用率，NT操作系统的服务器，能够使用N能治理器来查看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差不多上被OR

36、ACLE数据库使用着，这是合理，反之，讲明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时刻。数据库治理员还能够通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时刻，从而得知什么会话耗用服务器CPU比较多7。出现 CPU 资源不足的情况是专门多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。（1）数据库治理员能够执行下述语句来查看SQL语句的解析情况。SELECT*FROM V$SYSSTATWHERE NAME IN(parse time cpu , parse time elapsed , parse

37、count(hard);那个地点 parse time cpu是系统服务时刻，parse time elapsed是响应时刻，用户等待时刻waite time = parse time elapsed - parse time cpu。由此能够得到用户SQL语句平均解析等待时刻=waite time/ parse count。那个平均等待时刻应该接近于0，假如平均解析等待时刻过长，数据库治理员能够通过下述语句来发觉是什么SQL语句解析效率比较低。程序员能够优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。SELECT SQL_TEXT,PARSE_CALL

38、S,EXECUTIONSF ROM V$SQLAREAORDER BY PARSE_CALLS.（2）数据库治理员还能够通过下述语句查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。SELECT BUFFER_GETS,EXECUTIONS, SQL_TEXT FROM V$SQLAREA.（3）数据库治理员能够通过v$systen_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，假如没有冲突的话，latch free查询出来没有结果。假如冲突太大的话，数据库治理员能够降低spin_count参数值，来消除高的CPU使用率。5 内存参数的调整

39、内存参数的调整要紧是指ORACLE数据库的系统全局区(SGA)的调整。SGA要紧由三部分构成:共享池、数据缓冲区、日志缓冲区。系统全局区(System Global Area，SGA)，SGA随着不同的环境而不同，没有一种一般的最佳方案，我们在设置它之前要先考虑以下的几个方面：物理内存多大；操作系统是那种及占多大的内存，数据库系统是文件系统依旧裸设备；数据库运行的模式8。SGA包括：Fixed size、Variable Buffers、Redo Buffers。SGA占有物理内存的比例没有严格的规定，只能遵从一般的规则：SGA占据物理内存的40%60%左右。假如通过直观的公式化来表达则为：O

40、S使用内存+SGA+并发进程数*(sort_area_size+Hash_area_size+2M) select sum(value)/1024/1024 from v$sga;SUM(VALUE)/1024/1024- 500现在 SGA 的当前总大小近似为 500MB，同时那个值将变为 SGA_TARGET 的值。接下来，执行语句： alter system set sga_target = 500M scope=both;这种方法不需要为各个池设置不同值；因而，将需要在参数文件中使它们的值为零或全部删除它们。 shared_pool_size = 0large_pool_size =

41、0java_pool_size = 0db_cache_size = 0 再循环数据库，使这些值生效。 那个人工过程还能够通过 Enterprise Manager 10g 实施。从数据库主页中，选择 Administration 选项卡，然后选择 Memory Parameters。关于人工配置的内存参数，将显示标记为 Enable 的按钮，以及所有人工配置的池的值。单击 Enable 按钮，启用自动共享内存治理特性。企业治理器将完成剩下的工作。 在配置了自动内存分配之后，能够利用以下命令检查它们的大小： SQL select current_size from v$buffer_pool;

42、CURRENT_SIZE- 340SQL select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;POOL MBYTES- -java pool 4large pool 4shared pool 148正如所看到的，所有的池都从 500MB 的总目标大小中自动进行分配。如图2所示缓冲高速缓存大小是 340MB，Java 池是 4MB，大型池是 4MB，共享池是 148MB。它们合起来总的大小为 (340+4+4+148=) 496MB，近似与 500MB 的目标 SGA 的大小相同。 图 2 池的初始分配现在假

43、定提供给Oracle的主机内存从 500MB 减少为 300MB，这意味着必须减少总 SGA 的大小。能够通过减小目标 SGA 大小来反映这种变化。 alter system set sga_target = 300M scope=both;现在查看各个池，能够看到： SQL select current_size from v$buffer_pool;CURRENT_SIZE- 244SQL select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;POOL MBYTES- -java pool 4large

44、pool 4shared pool 44占用的总大小是 240+4+4+44 = 296MB，接近于目标的 300MB。如图 3 所示，当 SGA_TARGET 改变时，如何自动重新分配池。 图 3 在将 SGA 大小减少到 300MB 之后重新分配池这些池的大小是动态的。池将依照工作负载扩展，以容纳需求的增长，或缩小以容纳另一个池的扩展。这种扩展或缩小自动发生，无需 DBA 的干预，这与本文开头的示例不同。让我们临时返回到那个场景，假定在初始分配后，RMAN 作业启动，指示需要一个更大的大型池，大型池将从 4MB 扩展到 40MB，以容纳需求。那个额外的 36MB 将从数据库缓冲中划出，数据

45、库块缓冲将缩小，如图 4 所示。 图 4 在对大型池的需求增长之后通过重新分配的池池的大小变化基于系统上的工作负载，因此不需要为最坏的情况调整池的大小它们将依照需求的增长自动调整。此外，SGA 的总大小始终在由 SGA_TARGET 指定的最大值之内，因此不存在使内存需求的增长比例失调（这将导致分页和交换）的风险。能够动态地将 SGA_TARGET 增加至绝对最大值,那个绝对最大值是通过调整参数 SGA_MAX_SIZE 指定的。 5.4.2 不受阻碍的池SGA 中的一些池不受动态大小调整的阻碍，然而必须显式指定这些池11。其中值得注意的是非标准块大小的缓冲池，以及 KEEP 池或 RECYC

46、LE 池的非默认块大小。假如数据库有一个块大小为 8K，而想要配置 2K、4K、16K 和 32K 块大小的池，那么必须手动设置它们。它们的大小将保持不变；它们将可不能依照负载缩小或扩展。当使用多种大小的缓冲池、KEEP 池和 RECYCLE 池时，应当考虑那个因素。此外，日志缓冲不受内存调整的阻碍不管工作负载如何，在参数 log_buffer 中设定的值是不变的。( 在 10g 中，还能够在 SGA 中定义一种新的池：流池 (stream pool)，它用参数 streams_pool_size 进行设置。该池也不受自动内存调整的阻碍。） 这就产生了一个问题，假如需要一个非默认块大小的池，而

47、且想自动治理其它的池，那么该如何办？ 假如指定了这些非自动调整的参数中的任意一个（如 db_2k_cache_size），那么它们的总大小将从 SGA_TARGET 值中减去，以计算自动调整的参数值，以使 SGA 的总大小保持不变。例如，假设值看起来像如此。sga_target = 500Mdb_2k_cache_size = 50M其余的池参数未设置。50MB 的 2KB 缓冲池为自动调整的池（如默认块大小缓冲池 (db_cache_size)、共享池、Java 池和大型池）保留了 450MB。当以一种方法动态地调整不可自动调整的参数（如 2KB 块大小池）这种方法将阻碍到可自动调整部分的大

48、小，可自动调整的部分将重新调整。例如，将 db_2k_cache_size 的值从 50MB 提高到 100MB 只为可自动调整的参数剩余 400MB。因此，如图 5 所示,可调整的池（如共享池、大型池、Java 池和默认缓冲池）自动缩小，以将它们的总大小从 450MB 减少到 400MB。图 5 配置非自动缓冲参数的效果但假如有足够的可用内存，或者上述风险可能不是那么明显，那应该如何办？假如如此的话，能够通过不指定参数文件中的参数 SGA_TARGET、通过在文件中将其设为 0，或者通过使用 ALTER SYSTEM 动态地将其修改为 0 来关闭自动大小调整。当 SGA_TARGET 被设为

49、 0 时，池的当前值被自动设为它们的参数。 5.4.3 使用 Enterprise Manager 还能够使用 Enterprise Manager 10g 来处理这些参数。从数据库主页中单击超链接 Memory Parameters，如图 6 所示。 图 6 在 Enterprise Manager 中调整自动共享内存治理注意红圈中的项目：数据库在 Automatic Shared Memory Management 模式下运行，总大小为 564MB，与在参数 SGA_TARGET 中指定的值相同。能够在此修改它，然后单击Apply按钮同意这些值，可调整的参数将自动调整。 为每个池指定一个最

50、小值，假定将 SGA_TARGET 设为 600MB，同时各个池已自动分配。表1 各个池的最小值池大小（MB）缓冲池404Java 池4大型池4共享池148看上述值，可能推断 4MB 的 Java 池和大型池可能有点不足，那个值在运行时无疑需要增加。因此，可能想确保这些池至少在最初时具有更高的值，比如讲，分不为 8MB 和 16MB。能够通过在参数文件中显式地指定这些池的值或动态使用 ALTER SYSTEM 来实现这一目的（如下所示）。 alter system set large_pool_size = 16M;alter system set java_pool_size = 8M;现在

51、查看这些池，能够看到SQL select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;POOL MBYTES- -java pool 8large pool 16shared pool 148SQL select current_size from v$buffer_pool;CURRENT_SIZE- 388表2 池的重新分配显示如下池大小（MB）缓冲池388Java 池8大型池16共享池148如表2所示Java 池和大型池被重新配置为 8MB 和 16MB，同时为了使总的 SGA 保持在 600MB 以下，缓

52、冲池已从 404MB 减少为 388MB。因此，这些池仍然由自动共享内存治理操纵它们的大小将依照需求缩小或扩展。显式指定的值为池的大小设定了一个下限；它们将永久可不能缩小到低于那个界限。 5.4.4 小结 Oracle SGA 中的各种池的内存需求不是静态的。相反，它们依照系统上的需求而变化。Oracle 数据库 10g 中的自动共享内存治理特性通过动态地将资源重新分配到最需要它们的地点同时施加一个指定的最大值以防止分页和交换，使得Oracle 10g 数据库的内存得到更好的优化配置。6 调整I/OOracle RDBMS的性能与操作系统和I/O子系统紧密相关。某些时候，操作系统会阻碍Orac

53、le的性能。Oracle几乎确实是它自己的操作系统。治理员必须利用操作系统来实现几个关键任务，这些任务包括内存治理系统、进程调度程序和I/O子系统等。在操作系统的这些任务中，I/O子系统及I/O子系统的性能对Oracle RDBMS的性能是特不重要的12。Oracle的要紧功能是为数据库用户提供和维护数据；数据库的数据(不在内存中时)确实是存放在I/O子系统中的。Oracle的性能是和I/O子系统的性能直接相关的。6.1 定位I/O性能问题如何确定系统的要紧问题是I/O问题，并定位存在I/O性能瓶颈的设备是解决I/O性能问题的第一步。使用操作系统的监控工具能够实时监控I/O的情况。第一种方法是

54、使用vrnstat工具，使用该工具，能够查看b列的值，假如该值比较大，讲明等待I/O的进程比较多，I/O可能存在问题，如图7所示。图7 vmstat输出 图8 sar输出然后，通过sar1命令或者iostat命令能够进一步确认，如图8所示，从上图中发觉wio值长时刻高于40（那个值是个经验值，依照不同的系统，那个值能够调整），这讲明I/O等待比较严峻。现在能够通过sar-d命令来监控到底哪些I/O设备存在性能问题。假如发觉某个设备的繁忙度长时刻超过90%，那就讲明该设备比较繁忙，假如该设备的平均服务时刻比较大或者比其它设备高专门多。那么就讲明该设备存在性能问题。通过Oracle的statspa

55、ck工具也能够检查系统的I/O问题，假如系统的性能不佳，同时从报告中看到的db file sequential read等待事件是系统等待事件中排在前几位的事件，占系统总等待时刻的比例比较高，那么系统专门可能存在I/O性能问题。能够通过检查文件I/O情况来进一步确认并找出存在性能问题的设备。方法是通过检查文件I/O中的平均读响应时刻，假如某个文件的平均读响应时刻超过20毫秒，那么讲明该文件所在的设备可能存在性能问题。应该注意的是，20毫秒是一个相对的参数，在不同的应用环境下可能选择不同的参考值。通过比对操作系统的情况，数据库治理员应该专门快就能确定所治理的系统的平均读响应时刻和操作系统I/O情

56、况的对应关系。检查读平均响应时刻的时候还要注意几个问题。第一个问题是在报告时刻区域内的I/O量，假如某个文件在报告时刻区间内的I/O数量专门小，那么此平均响应时刻可能缺乏代表性，能够通过检查存放在相同设备上的其它文件来进一步确认。另外一种情况是平均每次读的数据量比较多（每次读的块数比较多），那么略高的平均读响应时刻也是正常的。下面图3中的数据确实是从I/O存在问题的数据库上取下的statspack数据。图9 statspack报告能够看出db file sequential read是等待事件的第一位事件，同时占整个等待事件的60%以上。这是一个典型的I/O存在性能瓶颈的例子，通过statsp

57、ack报告的“文件I/O性能分析”数据中，能够进一步检查到底哪些文件出现了问题。另外，buffer busy waits等待事件也往往是伴随着I/O性能存在问题的系统中经常出现，通过下列语句查询： SELECT pl “File”,p2 “Block”,p3”Reason” FROM v$session-wait WHERE event=buffer busy waits假如Reason值是130，那么讲明当某个会话需要访问某个数据块的时候，有另外一个会话正在将该数据块读入缓冲区。现在确信有一个相同p1,p2参数的等待事件，该等待事件或者是db file sequential read,或者是

58、db file scattered read。也确实是讲产生buffer busy waits的全然缘故是I/O的等待。6.2 Oracle对I/0的依靠性Oracle RDBMS的要紧任务是维护数据。Oracle把RDBMS中的数据存在于两个地点:内存和磁盘。内存中的数据要么来源于磁盘，要么最终被写入磁盘。Oracle RDBMS对I/O子系统具有专门强的依靠性。就正如Oracle RDBMS依靠于I/O子系统一样，Oracle RDBMS的性能也依靠于I/O子系统的性能。实际上，Oracle RDBMS的性能对I/O子系统的性能具有专门强的依靠性。Oracle RDBMS执行的绝大部分任务

59、都涉及到某些I/O操作，而且专门多任务还涉及到大量的I/O操作。为深入理解造成I/O性能低下的缘故，需要参考一些实际例子。因为检索数据时，磁盘驱动器有搜索时刻和旋转延迟，因此磁盘驱动器的性能受到了某些限制。因此，为了满足一个随机请求，I/O子系统需要花6.3ms的时刻。那个时刻被称为写操作延迟。6.2.1 读操作延迟的重要性因为读数据请求是用户请求，因此Oracle对读操作的时刻延迟是特不敏感的。该用户可能需要等待系统返回数据，因此读数据操作花的时刻越长用户等待的时刻也越长。治理员可能会问什么缘故会有人关怀仅需要6ms的读数据操作。假如读数据操作确实只需要6ms的时刻，那么那个问题的答案将是没

60、有人会关怀读数据操作。问题在于仅仅一次读操作全然满足不了用户需求。目前，读操作延迟仍然是个问题。一个缺乏效率的I/O子系统可能使大型查询需要花几个小时而不是几分钟。然而，在绝大多数系统中，I/O子系统一直被使用，在专门多情况下。I/O延迟时刻可能特不长。这通常表明I/O子系统的性能己经阻碍了Oracle的性能。一般情况下，因为排队和随机I/O的特性，读操作的延迟时刻在1020ms的范围内。尽管20ms是那个时刻范围的临界点，但这些值是专门合理的。在最坏情况下，读操作的性能会如何样?在过载I/O子系统中，50-100ms的时刻延迟是专门普遍的。治理员甚至可能会经历数百微秒的延迟时刻。读操作延迟时