ORACLE 数据库性能优化参考书目:《ORACLE 9i Database Performance Tuning Guide and Reference》《ORACLE 9i Database Reference》《ORACLE 9i SQL Reference》《ORACLE 9i Database Administrator’s Guide》一、数据库实例创建过程参数确定在创建数据库实例过程中,需要确定以下几个参数:1. 数据块大小(DB_BLOCK_SIZE)该参数指明了ORACLE所处理的数据存贮于数据文档以及SGA内存中的数据块大小。
该参数的可选择的范围为:4k,8k,16k,32k,64k。
对于OLTP系统而言,取值可以为4K或8K,对于DSS系统而言,则可以取较大的数据,如32K或64K 建议统一取8K(即8192)说明DB_BLOCK_SIZE的大小将影响创建表时的EXTENT的大小。
例如指定db_block_size=16K,某表空间的EXTENT MANAGEMENT 为local autoallocate,则其系统将extent的大小最小指定为1M.所以将可能导致空间的浪费。
2. 字符集(Character set)该参数确定数据库以何种字符集来存贮CHAR以及V ARCHAR、V ARCHAR2等字符类型的值。
对于ORACLE数据字典中的字符(如表及字段的COMMENT 内容)具有同样的作用。
因此需要考虑如字符集的使用。
对于国际项目,因为数据库中的comment内容(包括表及字符、存贮过程中的中文字符等内容)可能性需要以中文存贮,而用户业务数据使用的字符可能性是使用本地的语言,基于此,该参数需要选择支持UNICODE的字符编码的字符集。
目前ORACLE9i支持以下二种UNICODE字符集:⏹UTF8⏹AL32UTF8建议统一取AL32UTF83. 扩展段管理(EXTENT MANAGEMENT)该参数指明表空间中的扩展段的管理方式。
对于ORACLE9i以前的数据库,其表空间中的扩展段的分配/回收是通过系统字典表中的信息来分配的。
对于该种扩展段的管理方式,ORACLE9i做了根本性的改动。
现在可以不通过系统表中的信息来管理扩展段,改为通过位图方式。
即在各表空间中通过位图方式记录自己所属的EXTENT信息。
该种方式管理表空间中的EXTENT的分配其效果好。
所以ORACLE公司建议使用这各位图方式来管理表空间中的EXTENT。
如果选择这各方式,则参数为LOCAL 对于使用这种LOCAL方式本分配EXTENT的情况下,还有一种参数,即EXTENT的大小的分配方式:⏹AUTOALLOCATE⏹UNIFORM如果选择UNIFORM分配大小,则可以根据该表空间的使用特性,确定一个值。
如某表空间上存贮的基本上都是代码类的表,则可以定义UNIFORM大小为64K;而对于清单类表空间,则可以定义UNIFORM大小为2M或更大。
如果选择AUTOALLOCATE,则ORACLE会自动确定其每个EXTENT的大小。
注:ORACLE 的系统表空间SYSTEM的管理方式不能选择UNIFORM 方式分配大小,只能选择AUTOALLOCATE方式分配。
建议:所有业务表空间使用EXTENT MANAGEMENT LOCAL 方式来管理EXTENT对于清单类表空间,其UNIFORM SIZE=2M注意:如果指明表空间的管理方式是EXTENT MANAGEMENT LOCAL,则必须指表系统默认表空间。
指定为系统缺省的TEMP表空间即可。
4. 最大数据文件数(MAXDATAFILES )指明了该实例最大的数据文件数。
如果系统中数据文件使用数据大于这个值,则表空间创建或扩展将无法进行。
系统默认时该值比较小。
需要更改这个参数。
建议取值:1000或更大5. 最大重做日志文件数(MAXLOGFILES)该参数确定系统最大的REDO文件数据。
同样的,系统默认时取值有点小。
需要更改。
建议取值:206. 重做日志(redo log )文件大小重做日志文件的大小将影响数据库的性能。
大的日志文件能够提高数据库的性能。
因为数据库在切换不同的日志文件时将做检查点操作,如果日志文件太小,则检查点操作将会太频繁而导致性能的降底。
但是太大的日志文件将给数据可恢复性带来不利。
例如当一个日志组中的所有日志不可用的情况发生时,则数据库的恢复将只能恢复到上一次检查点的时刻,即在大多数情况下是恢复到上一个日志文件结束时所做的检查点操作的时刻。
(实际情况会因为数据库的相关参数的设置不同而有所不一样,如log_checkpoint_interval、FAST_START_MTTR_TARGET等参数)所以理想的情况是,将重做日志文件的位置存放于快速、独立的物理设备上,这样可以有效减少LGWR与DBWR进程的冲突等。
重做日志文件的大小因系统规模及业务特性不同而有所不同。
如计费数据库的重做日志文件应比营收的要大。
设置其大小有一个经验值:即观察日志文件切换的时间间隔,控制其时间间隔在20分钟左右。
如果当前系统的日志切换时间间隔比这值小,则可能需要增大每组日志的大小;否则做相反的改动。
注意:调整系统的日志大小只能通过增加新的日志组,将然后再删除以前旧的日志组的方式进行。
ORACLE不支持直接更改日志文件的大小。
建议:对于100万用户量的系统,计费数据库:500M-1G,分5-10组,每组两个LOG成员文件营收数据库:300M-1G,分5-10组,每组两个LOG成员文件7. 表空间的数据段管理(SEGMENT SPACEMANAGEMENT)当创建表空间的EXTENT的管理方式是LOCAL且为非临时表空间时,需要指定数据段(如表、索引、分区等)的管理方式。
系统有两种选择:⏹MANUAL⏹AUTO如果指定为MANUAL方式,则ORACLE使用系统字典表中的FREE LIST 的相关信息来分配SEGMENT空间;如果选择AUTO,则系统通过表空间上的BITMAP信息来分配空间。
建议:使用AUTO方式来管理SEGMENT的分配。
注意:当设置成AUTO方式时,建表时的PCTUSED、FREELIST等参数将不再有效二、内存调整1. 内存调整的意义ORACLE将其数据存贮于内存以及磁盘中。
对内存的访问速度将远快于对磁盘的访问速度。
因此,数据库性能调优的一个最基本目标就是如何有效地减少对磁盘的访问(物理IO)。
加大内存的容量并根据业务特性有效地分配内存给ORACLE的不同内存结构使用将可以大大提高系统的性能。
2. ORACLE的内存结构⏹Buffer cacheORACLE数据块的缓存。
ORACLE在访问数据时,首先从该缓存在查找所需数据,如果该缓存中没有数据,则系统试图从磁盘中获取数据。
⏹Shared pool该部分内存存贮ORACLE的许多方面的数据,包括被执行过的SQL语句以及其执行计划、系统数据字典以及其他数据。
⏹Large pool这部分主要用来保存并行查询时候的一些信息,还有就是RMAN 在备份的时候可能会使用到。
如果设置了MTS,则由于UGA部分要移入这里,则需要具体根据session最大数量和sort_ares_size 等相关会话内存参数的设置来综合考虑这部分大小的设置⏹Log bufferORACLE在写REDO LOG 文件之前,是先将LOG数据存于此处,当LOG BUFFER的大小充满度达到1/3时,将会触发物理的写日志操作。
说明1.如果系统中设置了buffer_pool_keep 、buffer_pool_recycle两个缓存的话,其内存的分配并不是从buffer cache中获取,而是从整个SGA的内存区获取。
具体相关说明见以下相关章节。
2.在项目中,数据库一般不安装成MTS方式3. SGA内存之外的内存在设置与调整SGA内存之前,需要了解在数据库相同的主机上还有什么其他应用程序也需要较大的内存。
如计费数据库主机上,很可能同时也在跑计费程序。
另外就是操作系统本身出需要一定的内存。
虽然各类操作系统都有虚拟内存的支持,也就是说可以将SGA设置成比物理内存还要大的数据值,但这样做已完成违背了性能调优的意义,从而导致大量的内存页面的切换以及物理IO操作。
说明可以通过操作系统的命令来查看是否存在大量的页面切换:HP-UX:swapinfo、vmstat等AIX:lsps、vmstat等4. SGA内存的取值范围确定分配给ORACLE的内存的大小需要考虑的主要因素有:主机上其他应用的内存的需求、操作系统的内存需求、数据库的使用特性等。
通常情况下,可以将SGA内存的最大使用值确定在ORACLE可用物理内存的70%以内(即从物理内存中去除各类非ORACLE应用所需内存所剩余的内存的70%以内)。
说明设置SGA最大可用内存可通过修改参数max_sga_size5. 设置BUFFER CACHEa)确定BUFFER CACHE大小在安装一个新的实例时,不可能比较准确知道设置多大的BUFFER CACHE 是合适的。
所以通常的做法是先根据经验设置一个大小,然后启动ORACLE的相关统计开关,然后在该数据库上执行典型的应用或模拟实际应用。
最后检查ORACLE的相关系统计数据,做出相应的调整。
可以通过以下两个方面了解BUFFER CACHE的设置:⏹检查系统表:V$DB_CACHE_ADVICE,获取BUFFER CACHE的大小的建议以及不同BUFFER CACHE大小对系统性能的影响。
⏹检查当前系统的BUFFER CACHE的命中率。
为了获取V$DB_CACHE_ADVICE中的数据,需要将数据库的参数DB_CACHE_ADVICE设置成TRUE。
可以通过以下SQL语句来获得BUFFER CACHE的大小的建议:SELECT size_for_estimate, buffers_for_estimate,estd_physical_read_factor, estd_physical_readsFROM V$DB_CACHE_ADVICEWHERE name = ’DEFAULT’AND block_size = (SELECT value FROM V$PARAMETERWHERE name = ’db_block_size’)AND advice_status = ’ON’;以下是从测试机中采集下来的统计数据:以下是其统计图表:从以上数据得知,当前的DB_CACHE_SIZE大小约为32M,如果在有空闲物理内存的情况下,将DB_CACHE_SIZE调成240M将会有效减少系统的物理IO读的次数。
但时,如果再增大其大小,对读的性能的提高将不会再有明显的改善。