oracle performance tunning.docx
- 文档编号:30398848
- 上传时间:2023-08-14
- 格式:DOCX
- 页数:30
- 大小:114.86KB
oracle performance tunning.docx
《oracle performance tunning.docx》由会员分享,可在线阅读,更多相关《oracle performance tunning.docx(30页珍藏版)》请在冰豆网上搜索。
oracleperformancetunning
一、SGA
1、Sharedpooltunning
Sharedpool的优化应该放在优先考虑,因为一个cachemiss在sharedpool中发生比在databuffer中发生导致的成本更高,由于dictionary数据一般比librarycache中的数据在内存中保存的时间长,所以关键是librarycache的优化。
Gets:
(parse)在namespace中查找对象的次数;
Pins:
(execution)在namespace中读取或执行对象的次数;
Reloads:
(reparse)在执行阶段librarycachemisses的次数,导致sql需要重新解析。
1)检查v$librarycache中sqlarea的gethitratio是否超过90%,如果未超过90%,应该检查应用代码,提高应用代码的效率。
Selectgethitratiofromv$librarycachewherenamespace=’sqlarea’;
2)v$librarycache中reloads/pins的比率应该小于1%,如果大于1%,应该增加参数shared_pool_size的值。
Selectsum(pins)“executions”,sum(reloads)“cachemisses”,sum(reloads)/sum(pins)fromv$librarycache;
reloads/pins>1%有两种可能,一种是librarycache空间不足,一种是sql中引用的对象不合法。
3)sharedpoolreservedsize一般是sharedpoolsize的10%,不能超过50%。
V$shared_pool_reserved中的requestmisses=0或没有持续增长,或者free_memory大于sharedpoolreservedsize的50%,表明sharedpoolreservedsize过大,可以压缩。
4)将大的匿名pl/sql代码块转换成小的匿名pl/sql代码块调用存储过程。
5)从9i开始,可以将executionplan与sql语句一起保存在librarycache中,方便进行性能诊断。
从v$sql_plan中可以看到executionplans。
6)保留大的对象在sharedpool中。
大的对象是造成内存碎片的主要原因,为了腾出空间许多小对象需要移出内存,从而影响了用户的性能。
因此需要将一些常用的大的对象保留在sharedpool中,下列对象需要保留在sharedpool中:
a.经常使用的存储过程;
b.经常操作的表上的已编译的触发器
c.Sequence,因为Sequence移出sharedpool后可能产生号码丢失。
查找没有保存在librarycache中的大对象:
Select*fromv$db_object_cachewheresharable_mem>10000andtypein('PACKAGE','PROCEDURE','FUNCTION','PACKAGEBODY')andkept='NO';
将这些对象保存在librarycache中:
Executedbms_shared_pool.keep(‘package_name’);
对应脚本:
dbmspool.sql
7)查找是否存在过大的匿名pl/sql代码块。
两种解决方案:
A.转换成小的匿名块调用存储过程
B.将其保留在sharedpool中
查找是否存在过大的匿名pl/sql块:
Selectsql_textfromv$sqlareawherecommand_type=47andlength(sql_text)>500;
8)Dictionarycache的优化
避免出现Dictionarycache的misses,或者misses的数量保持稳定,只能通过调整shared_pool_size来间接调整dictionarycache的大小。
Percentmisses应该很低:
大部分应该低于2%,合计应该低于15%
Selectsum(getmisses)/sum(gets)fromv$rowcache;
若超过15%,增加shared_pool_size的值。
2、BufferCache
1)granule大小的设置,db_cache_size以字节为单位定义了defaultbufferpool的大小。
如果SGA<128M,granule=4M,否则granule=16M,即需要调整sga的时候以granule为单位增加大小,并且sga的大小应该是granule的整数倍。
2)根据v$db_cache_advice调整buffercache的大小
SELECTsize_for_estimate,buffers_for_estimate,estd_physical_read_factor,estd_physical_readsFROMv$db_cache_adviceWHERENAME='DEFAULT'ANDadvice_status='ON'ANDblock_size=(SELECTValueFROMv$parameterWHERENAME='db_block_size');
estd_physical_read_factor<=1
3)统计buffercache的cachehitratio>90%,如果低于90%,可以用下列方案解决:
增加buffercache的值;
使用多个bufferpool;
Cachetable;
为sortingandparallelreads建独立的buffercache;
SELECTNAME,valueFROMv$sysstatWHERENAMEIN('sessionlogicalreads','physicalreads','physicalreadsdirect','physicalreadsdirect(lob)');
Cachehitratio=1-(physicalreads-physicalreadsdirect-physicalreadsdirect(lob))/sessionlogicalreads;
Select1-(phy.value-dir.value-lob.value)/log.valuefromv$sysstatlog,v$sysstatphy,v$sysstatdir,v$sysstatLOBwherelog.name='sessionlogicalreads'andphy.name='physicalreads'anddir.name='physicalreadsdirect'andlob.name='physicalreadsdirect(lob)';
影响cachehitratio的因素:
全表扫描;应用设计;大表的随机访问;cachehits的不均衡分布
4)表空间使用自动空间管理,消除了自由空间列表的需求,可以减少数据库的竞争
3、其他SGA对象
1)redologbuffer
对应的参数是log_buffer,缺省值与OS相关,一般是500K。
检查v$session_wait中是否存在logbufferwait,v$sysstat中是否存在redobufferallocationretries
A、检查是否存在logbufferwait:
Select*fromv$session_waitwhereevent=’logbufferwait’;
如果出现等待,一是可以增加logbuffer的大小,也可以通过将log文件移到访问速度更快的磁盘来解决。
B、Selectname,valuefromv$sysstatwherenamein(‘redobufferallocationretries’,’redoentries’)
Redobufferallocationretries接近0,小于redoentries的1%,如果一直在增长,表明进程已经不得不等待redobuffer的空间。
如果Redobufferallocationretries过大,增加log_buffer的值。
C、检查日志文件上是否存在磁盘IO竞争现象
Selectevent,total_waits,time_waited,average_waitfromv$system_eventwhereeventlike‘logfileswitchcompletion%’;
如果存在竞争,可以考虑将log文件转移到独立的、更快的存储设备上或增大log文件。
D、检查点的设置是否合理
检查alert.log文件中,是否存在‘checkpointnotcomplete’;
Selectevent,total_waits,time_waited,average_waitfromv$system_eventwhereeventlike‘logfileswitch(check%’;
如果存在等待,调整log_checkpoint_interval、log_checkpoint_timeout的设置。
E、检查logarchiver的工作
Selectevent,total_waits,time_waited,average_waitfromv$system_eventwhereeventlike‘logfileswitch(arch%’;
如果存在等待,检查保存归档日志的存储设备是否已满,增加日志文件组,调整log_archiver_max_processes。
F、DB_block_checksum=true,因此增加了性能负担。
(为了保证数据的一致性,oracle的写数据的时候加一个checksum在block上,在读数据的时候对checksum进行验证)
2)javapool
对于大的应用,java_pool_size应>=50M,对于一般的java存储过程,缺省的20M已经够用了。
3)检查是否需要调整DBWn
Selecttotal_waitsfromv$system_eventwhereevent=’freebufferwaits’;
二、数据库配置和IO问题
降低磁盘的IO
分散磁盘的IO
表空间使用本地管理
1、将文件分散到不同的设备上
1)将数据文件与日志文件分开
2)减少与服务器无关的磁盘IO
3)评估裸设备的使用
4)分割表数据
2、表空间的使用
系统表空间保留给数据字典对象
创建本地管理表空间以避免空间管理问题
将表和索引分散到独立的表空间中
使用独立的回滚表空间
将大的数据库对象保存在各自独立的表空间中
创建一个或多个独立的临时表空间
下列数据库对象应该有单独的表空间:
数据字典、回滚段、索引、临时段、表、大对象
3、检查IO统计数据
Selectphyrds,phywrts,d.namefromv$datafiled,v$filestatfwheref.file#=d.file#orderbyd.name;
检查最有可能引起磁盘IO瓶颈的文件。
4、分割文件
可以通过RAID和手工进行
Altertabletable_nameallocateextent(datafile‘fiile_name’size10M);
但手工操作工作量很大。
5、优化全表扫描操作
1)检查有多少全表发生:
Selectname,valuefromv$sysstatwherenamelike‘%tablescan%’;
tablescans(shorttables)/tablescans(longtables)与全表扫描相关,如果tablescans(longtables)的值很高,说明大部分的tableaccess没有经过索引查找,应该检查应用或建立索引,要确保有效的索引在正确的位置上。
合理的DB_FILE_MULTIBLOCK_READ_COUNT能减少tablescan需要调用的IO次数,提高性能(与OS相关)。
2)查看fulltablescan操作:
Selectsid,serial#,opname,target,to_char(start_time,’HH24:
MI:
SS’)“start”,(sofar/totalwork)*100“percent_complete”fromv$session_longops;
通过v$session_longops里的sql_hash_value与v$sqltext关联,可以查询导致fulltablescan的sql。
6、Checkpoint
Checkpoint进行的操作:
DBWn进行IO操作;CKPT更新数据文件头和控制文件。
经常进行Checkpoint的结果:
减少恢复所需的时间;降低了系统运行时的性能。
LGWR以循环的方式将日志写到各个日志组,当一个日志组满时,oracleserver必须进行一个Checkpoint,这意味着:
DBWn将对应log覆盖的所有或部分脏数据块写进数据文件;CKPT更新数据文件头和控制文件。
如果DBWn没有完成操作而LGWR需要同一个文件,LGWR只能等待。
在OLTP环境下,如果SGA很大并且checkpoint的次数不多,在Checkpoint的过程中容易出现磁盘竞争的状况,在这种情况下,经常进行Checkpoint可以减少每次Checkpoint涉及到的脏数据块的数目。
调节Checkpoint次数的办法:
增大日志文件;增加日志组以增加覆盖的时间间隔。
7、日志文件
建立大小合适的日志文件以最小化竞争;
提供足够的日志文件组以消除等待现象;
将日志文件存放在独立的、能快速访问的存储设备上(日志文件可以创建在裸设备上)。
日志文件以组的方式组织管理,每个组里的日志文件的内容完全相同。
8、归档日志文件
如果选择归档模式,必须要有两个或两个以后的日志组,当从一个组切换到另一个组时,会引起两种操作:
DBWn进行Checkpoint;一个日志文件进行归档。
归档有时候会报错:
ARC0:
Beginningtoarchivelog#4seq#2772
Currentlog#3seq#2773……
ARC0:
Failedtoarchivelog#4seq#2772
ARCH:
Completedtoarchivinglog#4seq#2772
建议init参数修改如下:
log_archive_max_processes=2
#log_archive_dest=‘/u05/prodarch’
log_archive_dest_1="location=/u05/prodarchMANDATORY’
log_archive_dest_state_1=enable
log_archive_dest_2="location=/u05/prodarch2OPTIONALreopen=10"(或其它目录)
log_archive_dest_state_2=enable
log_archive_min_succeed_dest=1
log_archive_dest_state_3=DEFER
log_archive_dest_state_4=DEFER
log_archive_dest_state_5=DEFER
三、优化排序操作
1、概念
服务器首先在sort_area_size指定大小的内存区域里排序,如果所需的空间超过sort_area_size,排序会在临时表空间里进行。
在专用服务器模式下,排序空间在PGA中,在共享服务器模式下,排序空间在UGA中。
如果没有建立largepool,UGA处于sharedpool中,如果建立了largepool,UGA就处于largepool中,而PGA不在sga中,它是与每个进程对应单独存在的。
PGA:
programglobalarea,为单个进程(服务器进程或后台进程)保存数据和控制信息的内存区域。
PGA与进程一一对应,且只能被起对应的进程读写,PGA在用户登录数据库创建会话的时候建立。
有关排序空间自动管理的两个参数:
Pga_aggregate_target:
10M-4000G,等于分配给oracleinstance的所有内存减去SGA后的大小。
Workarea_size_policy:
auto/manual,只有Pga_aggregate_target已定义时才能设置为auto。
这两个参数会取代所有的*_area_size参数。
措施:
尽可能避免排序;尽可能在内存中排序;分配合适的临时空间以减少空间分配调用。
2、需要进行排序的操作:
A、创建索引;
B、涉及到索引维护的并行插入
C、orderby或者groupby(尽可能对索引字段排序)
D、Distinct
E、union/intersect/minus
F、sort-mergejoin
G、analyze命令(仅可能使用estamate而不是compute)
3、诊断和措施
Select*fromv$sysstatwherenamelike‘%sort%’;
Sort(disk):
要求Io去临时表空间的排序数目
Sort(memory):
完全在memory中完成的排序数目
Sort(rows):
被排序的行数合计
Sort(disk)/Sort(memory)<5%,如果超过5%,增加sort_area_size的值。
SELECTdisk.Valuedisk,mem.Valuemem,(disk.Value/mem.Value)*100ratioFROMv$sysstatdisk,v$sysstatmemWHEREmem.NAME='sorts(memory)'ANDdisk.NAME='sorts(disk)';
4、监控临时表空间的使用情况及其配置
Selecttablespace_name,current_users,total_extents,used_extents,extent_hits,max_used_blocks,max_sort_blocksFROMv$sort_segment;
Column
Description
CURRENT_USERS
Numberofactiveusers
TOTAL_EXTENTS
Totalnumberofextents
USED_EXTENTS
Extentscurrentlyallocatedtosorts
EXTENT_HITS
Numberoftimesanunusedextentwasfoundinthepool
MAX_USED_BLOCKS
Maximumnumberofusedblocks
MAX_SORT_BLOCKS
Maximumnumberofblocksusedbyanindividualsort
临时表空间的配置:
A、initial/next设置为sort_area_size的整数倍,允许额外的一个block作为segment的header
B、pctincrease=0
C、基于不同的排序需要建立多个临时表空间
D、将临时表空间文件分散到多个磁盘上
四、诊断latch竞争
1、概念
Latch是简单的、低层次的序列化技术,用以保护SGA中的共享数据结构,比如并发用户列表和buffercache里的blocks信息。
一个服务器进程或后台进程在开始操作或寻找一个共享数据结构之前必须获得对应的latch,在完成以后释放latch。
不必对latch本身进行优化,如果latch存在竞争,表明SGA的一部分正在经历不正常的资源使用。
1)Latch的作用:
A、序列化访问:
保护SGA中的共享数据结构;保护共享内存的分配。
B、序列化执行:
避免同时执行某些关键代码;避免互相干扰。
2)Latch请求的两种类型:
A、willing-to-wait:
请求的进程经过短时间的等待后再次发出请求,直到获得latch
B、immediate:
如果没有获得latch,请求的进程不等待,而是继续处理其他指令。
2、检查Latch竞争
检查latchfree是不是主要的waitevent:
Select*fromv$system_eventorderbytime_waited;
检查latch的使用情况:
Select*fromv$latch:
与willing-to-wait请求有关的列:
gets、misses、sleeps、wait_time、cwait_time、spin_gets
与immediate请求有关的列:
immediate_gets、immediate_misses
Gets:
numberofsuccessfulwilling-to-waitrequestsforalatch;
Misses:
numberoftimesaninitialwiling-to-waitrequestwasunsuccessful;
Sleeps:
numberoftimesaprocesswaitedafteraninitialwilling-to-waitrequest;
Wait_time:
numberofmillisecondswaitedafterwilling-to-waitrequest;
Cwait_time:
ameasureofthecumulativewaittimeincludingthetimespentspinningandsleeping,theoverheadofcontextswitchesduetoOStimeslicingandpagefaultsandinterrupts;
Spin_gets:
getsthatmissesfirsttrybutsucceedafterspinning.
Immediate_gets:
numberofsuccessfulimmediaterequestsforeachlatch;
Immediate_misss:
numberofunsuccessfulimmediaterequestsforeachlatch;
一般无需调整latch,但是下列的措施是有用的:
A、对处于竞争中的latch做进一步的调查
B、如果竞争主要存在于sharedpool和library
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- oracle performance tunning