Oracle数据库性能优化技术.pptx
- 文档编号:1142435
- 上传时间:2022-10-17
- 格式:PPTX
- 页数:73
- 大小:3.18MB
Oracle数据库性能优化技术.pptx
《Oracle数据库性能优化技术.pptx》由会员分享,可在线阅读,更多相关《Oracle数据库性能优化技术.pptx(73页珍藏版)》请在冰豆网上搜索。
Oracle数据库性能优化技术,技术创新,变革未来,智慧IT,02,03,04,目录Contents,资源使用优化,常用工具,案例分享,01性能诊断,01性能诊断,01,性能诊断,网络2,性能指标:
响应时间:
从发出指令之后到收到结果之间消耗的时间响应时间(ResponseTime)=服务时间(serviceTime)+等待时间(waittime)只要降低工作时间和等待时间,响应时间自然随之降低,并增加用户满意度比如:
车站买票,排队时间30分钟,实际买票1分钟,响应时间就是31分钟吞吐量:
固定时间之内可以完成的工作量比如tpcc的评定结果就是TPM(每分钟完成的交易数量),04,性能诊断,中间件,客户端,终端客户响应时间=t1+t2+t3+t4+t5数据库响应时间=t5,t1,t3,t4,t2,t5数据库,02,性能诊断,性能突变,整体慢,部分慢,操作系统资源使用是否正常(cpu,内存使用率,磁盘,网络延迟是否正常。
),是否锁等待、sql执行计划异变。
业务、程序、数据库是否有调整,收集并分析故障和正常时期的awr报告,优化sql并或调整应用,是否硬件或者网络故障,修理硬件,异常会话持有锁未释放,杀掉异常会话,数据库性能问题最直观的表现就是响应时间变慢,04,性能诊断,awr报告关键指标,03,性能诊断,OWIORACLEWAITINTERFACEOWI是面向问题的OWI是定量的记录了历史和当前所有等待事件的等待次数,等待时间、平均等待时间OWI是征兆学的OWI是不断进步完善的等待事件数ORACLE7:
104个ORACLE8:
140个,ORACLE8I:
220ORACLE9I:
400ORACLE10G:
800ORACLE11G:
1367OWI最强有力的表现形式-AWR报告(从10g开始提供,之前是Statspack),03,性能诊断,awr是什么AWR(AutomaticWorkloadRepository)AWR和SYSAUX都是10g出现的,是Oracle调优的关键依据,其收集历史性能数据并保存到sysaux表空中,大约1999年左右开始开发默认快照间隔1小时,10g保存7天、11g保存8天;可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改select*fromDBA_HIST_WR_CONTROL验证修改结果每个快照点记录了数据库在那个时间点的所有统计信息的总量,awr快照就是对比两个快照点之间的数据增量,这样就可以分析一个时间段内的系统负载是否正常。
正因为如此收集报告时快照点之间实例不能重启(重启之后有些数据是重新开始计数的)如何收集awr报告?
/rdbms/admin/awrrpt本实例?
/rdbms/admin/awrrptiRAC环境选择其他实例,03,性能诊断,awr数据从那里来到那里去?
dba_advisor_*dba_hist_*dba_feture_*dba_high_water_mark_*dba_tab_stats_history,v$sysstatv$sessionv$sqlv$segment_statisticsv$sys_time_modlev$sysmetric_historyv$system_wait_classv$osstatv$active_sesion_history,03,性能诊断,04,性能诊断,awr报告关键指标,05,性能诊断,awr-DBTIME,Elapsed为两个快照点在自然时间上的跨度DBTIME=所有前台进程花费在数据库调用上的总和时间:
包括CPU时间、IOTime、和其他一系列非空闲等待时间,cpuonqueuetimeDBTime描绘了数据库总体负载,但要和elapsedtime逝去时间结合其他来oAverageActiveSessionAAS=DBtime/ElapsedTimeDBTime=60min,ElapsedTime=60minAAS=60/60=1负载一般DBTime=1min,ElapsedTime=60minAAS=1/60负载很轻DBTime=60000min,ElapsedTime=60minAAS=1000系统hang了吧?
如果故障时间段的dbtime相比与正常时间的dbtime大幅增加,说明数据库层面确实出现了性能问题,反之则说明性能问题不是数据库层面上的,需要排查其他层面。
这里说说的正常时期也就是数据库的性能基线,这个是好与坏的对比依据,05,性能诊断,awr-LoadProfile,05,性能诊断,awr-LoadProfileDBTime(s):
这个表示每秒自然时间内经历了XX数据库时间,计算方式是DBTime/Elapsed=9023.56/59.53=151.6(统计值单位是分钟,这里是秒,其实是一样的,只是单位换算不一样)DBCPU(s):
对于多核cpu服务器(比如8核),在自然时间1秒上如果100%全负荷运行则总共拥有8秒的cpu时间,也就是如果服务器上只有数据库消耗cpu,则系统cpu使用率应该是6.6/8=82.5%,正好跟HostCPU中显示的Idle%=21.2%基本吻合而跟每秒151.6秒的dbtime比起来,说明有151.6-6.6=145秒是在等待,也就是说尽管cpu使用率偏高82%,但是并非是cpu资源紧缺导致了性能问题,应该关注在等待上redosize单位bytes,redosize可以用来估量update/insert/delete的频率,大的redosize往往对lgwr写日志,和arch归档造成I/O压力,PerTransaction可以用来分辨是大量小事务,还是少量大事务。
如上例每秒redo约1MB,每个事务800字节,符合OLTP特征LogicalRead单位次数*块数,相当于“人*次”,如上例196,888*db_block_size=1538MB/s,逻辑读耗CPU,主频和CPU核数都很重要,逻辑读高则DBCPU往往高,也往往可以看到latch:
cachebufferchains等待。
大量OLTP系统(例如siebel)可以高达几十乃至上百Gbytes。
BlockchangesPhysicalRead,单位次数*块数,描绘数据变化频率单位次数*块数,如上例5076*8k=39MB/s,物理读消耗IO读,体现在IOPS和吞吐量等不同纬度上;但减少物,理读可能意味着消耗更多CPU。
好的存储每秒物理读能力达到几GB,例如Exadata。
这个physicalread包含了physicalreadscache和physicalreadsdirectPhysicalwrites单位次数*块数,主要是DBWR写datafile,也有directpathwrite。
dbwr长期写出慢会导致定期logfileswitch(checkpointnocomplete)检查点无法完成的前台等待。
这个physicalwrite包含了physicalwritesdirect+physicalwritesfromcacheUserCalls单位次数,用户调用数,moredetailsfrominternalParses解析次数,包括软解析+硬解析,软解析优化得不好,则夸张地说几乎等于每秒SQL执行次数。
即执行解析比1:
1,而我们希望的是解析一次到处运行哦!
HardParses万恶之源CursorpinsonX,librarycache:
mutexX,latch:
rowcacheobjects/shared,06,性能诊断,创建一个数据库建库,这里曾是基于命中率调优的重点内容,但是从awr开始,这里的命中率不再是特别重要的内容,命中率高低跟性能问题没有绝对的因果关系,但是以下指标仍然值得关注ExecutetoParse%执行解析比,计算方式为1-(parse/execute),目标为100%即接近于只执行而不解析数据来源v$sysstatstatisticsparsecount(total)和executecountLatchHit%:
willing-to-waitlatch闩申请不要等待的比例。
数据来源V$latchgets和missesParseCPUToParseElapsd:
解析CPU时间和总的解析时间的比值(ParseCPUTime/ParseElapsedTime);若该指标水平很低,那么说明在整个解析过程中实际在CPU上运算的时间是很短的,而主要的解析时间都耗费在各种其他非空闲的等待事件上了(如latch:
sharedpool,rowcachelock之类等),数据来源V$sysstat的parsetimecpu和parsetimeelapsed%Non-ParseCPU非解析cpu比例,计算方式为(DBCPUParseCPU)/DBCPU,此值若很低则说明sql共享没有做好,cpu大量消耗在解析而不是执行上。
数据来源v$sysstat的parsetimecpu和cpuusedbythissession,05,性能诊断,awr-topevents,05,性能诊断,awr-topeventstopevents是最需要结合基线来分析的部分比如等待时间最长的事件不一定就是性能问题的原因,比如对于olap系统来说dbfilesectredread可能就是等待时间最大的消耗来源,因为它确实需要做大量的全表扫描,结合基线来看如果发现了之前未曾有过的等待事件,即使他不是最大的消耗者也比最大的消耗者嫌疑更大,06,性能诊断,创建一个数据库建库,这里最需要关注的是sga+pga占物理内存的比例是否合理,建议不要超过60%,同时需要关注是否有内存抖动。
对于unix操作系统,比如aix和hp-ux,文件系统缓存默认比例都很高,建议调低,因为对于数据库来说有专门的sga就够了,再使用文件系统缓存会导致操作系统内存资源紧张进而产生交换,这时性能问题就不可避免了,对于HP11iv3以上的版本,filecache_min和filecache_max控制,注意单位为字节数,也可以写百分比:
kctune-u-sfilecache_max=10%kctune-u-sfilecache_min=5%AIX5可用而在11.23中,则使用dbc_max_pct和dbc_min_pct参数来控制kctune-u-sdbc_max_pct=10kctune-u-sdbc_min_pct=5,06,性能诊断,parsetimeelapsed、hardparseelapsedtime结合起来看解析是否是主要矛盾,若是则重点是软解析还是硬解析sequenceloadelapsedtimesequence序列争用是否是问题焦点PL/SQLcompilationelapsedtimePL/SQL对象编译的耗时注意PL/SQLexecutionelapsedtime纯耗费在PL/SQL解释器上的时间。
不包括花在执行和解析其包含SQL上的时间connectionmanagementcallelapsedtime建立数据库session连接和断开的耗时failedparseelapsedtime解析失败,例如由于ORA-4031hardparse(sharingcriteria)elapsedtime由于无法共享游标造成的硬解析hardparse(bindmismatch)ela
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Oracle 数据库 性能 优化 技术