Oracle数据库性能优化概述.pptx
- 文档编号:1130107
- 上传时间:2022-10-17
- 格式:PPTX
- 页数:97
- 大小:2.42MB
Oracle数据库性能优化概述.pptx
《Oracle数据库性能优化概述.pptx》由会员分享,可在线阅读,更多相关《Oracle数据库性能优化概述.pptx(97页珍藏版)》请在冰豆网上搜索。
Oracle数据库性能优化概述,技术创新,变革未来,智慧IT,01性能优化方法概略02性能优化之登录,03性能优化之资源,目录Contents,04性能优化之锁,02,性能优化探讨,原因:
WHY为什么?
慢(响应时间)慢(吞吐量)就想做个优化,02,我们经常遇到的问题,Client,Network,OS,Database,Middle-ware,Application,H/W,嘿!
数据库出问题了!
网络供应商,数据库厂商,中间件厂商,应用开发商,硬件供应商,OS供应商,增加硬件可以解决问题,大家都在尽可能的推卸责任甲方很难沟通和协调,02,性能优化要点,数据库性能优化,定位,监控,预警,自动化运维平台,基线,监控数据库各个组件健康运行状态,及时预警各类非正常的组件及指标,自动化、标准化、内置专家系统,建立各种性能基线(方便寻找变化),相当于一个健康人的体检指标,性能问题典型特点为不报错,需在错综复杂的环境中快速定位故障,要点:
丰富的知识储备,可量化,可比较,02,性能问题常见原因,性能问题症状,前台业务很卡,后台报表很慢,历史数据积压,调度不合理,主机参数不合理,硬件架构对象设计不合理执行计划异常,全表扫描,长长的串行逻辑,硬件性能瓶颈,Oraclebug,高频SQL,数据块争用,Mutex争用,Lock争用,Latch争用数据库参数不合理,02,诊断数据库性能的三把利剑:
AWR,ASH,ADDM,02,系统极限,a,吞吐量到达突变之后,响应时间急剧上升。
b,系统性能优化的目标就是让突变点尽可能后移。
02,性能优化探讨,CPU资源,内存资源,I/O资源,网络资源,主机的四大资源一直在更新换代,02,主机资源的三角关系,内存资源,运行队列,等待队列,上下文切换能力,空闲率,内存容量,内存交换,吞吐量,IOPS,响应时间,存储容量,内存空闲,I/O空闲率,02CPU资源快速发展:
Intel志强E7与POWER8之争,02,I/O资源:
闪存的快速发展,延时,2.5usec,1.3usec,0.7usec,0.5usec,160/200Gb/s,100Gb/s,56Gb/s40Gb/s,10Gb/s,20Gb/s20012002200320042005200620072008200920102011201220132014201520162017,200120022003200420052006200720082009201020112012201320142015201620175usec,带宽,SameSoftwareInterface,0.5usec,02网络资源:
IB网络的快速发展,02,现象:
CPU资源不足,故障现象:
CPU资源空闲率严重不足,监控日志显示如下:
02,现象:
内存资源不足,故障现象:
内存资源严重不足,系统产生大量交换。
登陆主机非常缓慢。
02,现象:
I/O资源不足,故障现象:
I/O资源不足。
表现为磁盘busy程度为100%或者响应时间为大几十ms甚至几百ms。
如下所示:
02现象:
网络资源堵塞,故障现象:
AWR报告显示数据库性能严重出现问题。
02,性能优化之案例,案例之登录访问案例之资源案例之锁,02,性能优化方法论发展,02,案例之登录访问,登录流程:
例:
现象:
某运营商发现从早上就开始接到大量的营帐业务系统性能恶化的投诉和抱怨,主要投诉集中在通过账务系统访问CRM系统的业务处理之中。
手工发起连接到CRM系统的登录响应也非常慢,从CRM系统的Listener.log以及Session跟踪可以发现每秒超过100多个Listener连接发起,绝大部分都来自于账务系统的Databaselink连接。
通过业务变化确认,比较昨天的业务,今天的业务增加了关闭databaselink的操作,以降低CRM系统的Session数量。
02,案例之登录访问,诊断:
数据库服务器本机进行tnsping操作达到了1000ms+数据库的Listener的CPU占用率比较高应急处理:
应急处理为通过增加Listener数量以均衡负载,增加Listener的总处理能力,渡过白天业务周期测试:
在业务周期结束之后,我们对于CRM的Listener进行了人工模拟的数据库登录并发压力测试,在每秒并发数量达到100+之后,Tnsping的Listener响应迅速增加到1000ms+以上,验证了Listener处理能力不足猜测的正确性。
02,案例之登录访问,Listener的并发处理能力是有限制的,而且并不是很高。
数据库登录的整个流程即使正常运行也经常达到180ms+。
关闭Databaselink使得Databaselink访问变成每次访问都需要连接数据库,从而使数据库登录的响应时间纳入了业务响应的时间范畴之内。
02,案例之登录访问,登录输入指标测量Logons:
=EndSnap.logonscumulativeStartSnap.logonscumulative。
LogonsPerSecond:
=Logons/TimeInterval,02,案例之登录访问,登录输出指标测量:
LogonResponseTime:
=NetworkResponseTime*10+NativeTCPLogon:
=NetworkResponseTime*10+ListenerResponseTime+NativeIPCLogonTime。
LogonResponseTimePerLogon:
=LogonResponseTime/Logons,02,案例之登录访问,例:
某运营商电子运维系统(hprx6600|Oracle10.2.0.4)遭遇业务系统性能故障,几乎每12个星期就由于业务系统响应缓慢需要重新启动主机,可以进行远程拨号访问。
优化过程:
从描述来看,似乎这又是一个简单的HP-UX的交换空间缺省配置问题,拨号登录系统之后进行系统检查。
02,案例之登录访问,检查HP-UX交换空间配置,正常。
进入数据库检查,数据库处于轻载运行状态,唯一感觉有问题的就是Logons感觉偏高,达到每秒40多个。
回到操作系统检查,资源表现正常。
Listener进程CPU消耗偏高,本地tnsping响应慢。
本地IPC连接响应很快,本地TCP连接响应缓慢。
检查netstat输出,发现较多的time_waited连接,表示存在着大量频繁退出的连接,和数据库内部Logons偏高一致。
检查Listener.log,每秒产生的大量的连接,几乎所有的连接都来自于中间件服务器。
02,案例之登录访问,告知用户检查中间件连接池,估计是连接池参数配置不当或者没有使用连接池引起。
用户咨询开发商之后确认,系统没有采用连接池管理。
优化结论和改善:
本系统显然是一个轻载型系统,偶尔的高并发性业务导致业务系统性能故障。
短连接的业务响应时间包含了数据库连接过程。
改变短连接为连接池管理。
在开发商完成连接池管理之前遇到类似问题,大多数情况下(非持续性高压力访问)可以通过重新启动Listener而不是重启主机解决。
02,案例之登录访问,例:
某工商局业务系统间歇性表现出业务系统性能不佳,在持续的卡壳之后往往可以自我恢复,自我性能恢复似乎和业务系统吞吐量并没有太大的关系。
优化过程:
检查典型时段的AWR报告,显然数据库处于轻载运行状态。
排除数据库问题,业务性能缓慢应该是由于连接池管理问题引起。
用户检查连接池,在问题出现的时候往往空闲连接池的数量很少。
考虑到用户业务系统性能似乎和业务系统吞吐量高低并没有直接的关系,似乎不是中间件的bug或者其他系统性障碍。
让用户检查中间件活动连接增长状况和min-max配置。
连接池参数配置:
min:
=5,max:
=500,常规活动状况为30左右。
综合来看,应该是连接池配置管理不当引起,设置min:
=100。
02,案例之登录访问,优化结论和改善:
由于connectionpool的最小连接参数设置过小,连接池管理不断进行释放可用连接,导致后续的业务无法从ConnectPool中获得连接,需要进行动态扩张。
频繁的动态扩张连接使数据库登录过程包含进业务系统响应,使业务系统反应缓慢。
检查增加连接池管理最小连接到合适的大小即可。
我们总是建议中间件连接池最小连接和最大连接参数保持相同,避免动态扩展和回收。
我们总是建议连接池管理依据硬件能力和业务需求的综合来进行设置,而且以硬件能力为主,业务需求辅助。
02,案例之登录访问,例:
某医院HIS业务系统的账户登录操作异常缓慢,部分情况下甚至会出现长时间的卡壳情况,业务影响主要发生在每天早上的上班时刻。
02,案例之登录访问,优化过程:
账户登录过程一般涉及到在账户表格以及对应日志表格上的冲突,比如Bufferbusywaits或者TXlock。
AWR未体现该特征。
AWR报告显示connectionmanagementcallelapsedtime时间偏长,sequenceloadelapsedtime具有一个明显偏大的值。
即使在经常发生性能问题的早上上班时刻,tnsping的表现也相对比较正常,说明Listener处理正常。
检查Sequenceaudses$的Cache设置,发现该值为20,和早上上班的高峰期数据库登录有些不相匹配,增加audseq$的cache值到10000。
02,案例之登录访问,优化结论和改善:
SequenceAudses$的cache大小不足是导致数据库登录响应缓慢的主要原因,一般情况下该值在20并不会产生问题,只是在大量高并发登录的时候才会发生问题。
修改sequenceAudses$的cache值为10000以支持同一时间段的大批量数据库登录。
sequencecache不足问题,02,案例之登录访问,访问流程:
业务数据访问处理,Session1,Session2,Session3,SQL1,SQL2,SQL1,SQL2,SQL1,SQL2,02,案例之登录访问,例:
某商业银行RAC中某一个节点(节点不定)间歇性发生CPU资源100%消耗,业务响应几乎挂起。
客户反映在CPU消耗周期并没有太大的业务增加。
检查比较正常周期和异常周期的AWR报告逻辑读异常增长检查TOPSQL判断异常点查看执行计划,执行速度和执行计划都正常执行计划历史执行计划改变,02,案例之登录访问,说明:
该案例显然是输入压力过大(logicalreads)导致了消耗资源(CPU)过多,导致输出响应变慢。
可以预见,只要CPU资源保持充足,即使选择了更差的执行计划,也不会导致导致最后的性能障碍。
02,案例之登录访问,数据流程访问优化步骤:
业务系统响应慢,LogicalreadsPerSecond大幅度增加,发现导致Logicalreads增加的业务和SQL语句,访问流程分解以发现问题子流程,服务和等待分析发现问题在于处理或者等待,通过更多缓存降低Physicalreads,业务压力变化,发现问题资源和组件,业务特征变化,SQL语句Logicalreads变化,确认变化或者优化SQL,PhysicalReads增加,02,案例之登录访问,场景一、Arraysize:
=1SQLselect*fromsys.obj$;51517rowsselected.Elapsed:
00:
00:
13.03统计信息:
26106consistentgets4161424bytessentviaSQL*Nettoclient283786bytesreceivedviaSQL*Netfromclient25760SQL*Netroundtripsto/fromclient51517rowsprocessed从v$sess_time_model可以知道:
DBtimeDBCPU,13763471375080,02,案例之登录访问,场
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Oracle 数据库 性能 优化 概述