一、配景
由于行内某生意体系必要进行版本更新，为包管新版本上线后能够到达最优结果，根据需求，对该体系的Oracle内容库进行了一次深入诊断、阐发和优化。在阐发过程中，果然发现了一些由于SGA设置问题导致的体系运行危害。经由简洁的优化，问题最终得以顺利解决。本文对整个阐发排查过程、解决方案及最终结果进行了简洁的描述和记录。
二、阐发过程
内容库在日常没有发现性能问题时只需进行一些常规搜检，日常进行的常规搜检主要包含以下操纵：
空间查看：
内存查看：
CPU查看：
主灵活态性能查看：
搜检后发现，除主灵活态性能外，其他搜检项均正常，主灵活态性能的问题为输出效果中wa对照高；一般来讲vmstat中wa为0，阐明压力正常；当该值较大时，阐明io守候对照严重，这可能是磁盘大量随机访问造成的，也有可能是磁盘的带宽显现了瓶颈。
该主机上仅运行了该生意体系的内容库，因此造成大量io访问的也只有可能是db。进一步到内容库中进行阐发，查看此时内容库的守候变乱：
此时，并没有发现内容库有严重的守候，看起来较为异常的仅有一个read by other session和gc的守候变乱，对相关变乱的sql进行阐发，能够发现该sql如下：
该sql是应用法式框架直接天生，对该sql进行阐发，发现其执行规划看似合理，但其实并欠好，mct_id固然走了索引范围扫描，然则返回的行数都是在30w以上，也便是说这个前提的筛选率并欠好（这里我个人认为，这个操纵和全表扫描没什么太大区别）。
经由查询，发现该表照样对照大，整个内容有也许2000w。此时，从表的数量、执行规划来看，我们不难判断该sql一定会造成大量的逻辑读，而在Oracle集群中，大量的逻辑读发生read by other session和gc守候的现象并不稀罕。
然则必要注意的是，内容库中除了这个sql，并没有其他的异常守候变乱，而大量的逻辑读，一般是从cache中读取内容，cache中读取内容也不会造成严重的iowait才对。所以，很有可能造成严重的iowait尚有其因。
为了进一步确认问题，天生一个awr对内容库在这个时间段的团体环境进行阐发：
从DB TIME上来看，整个内容库的压力并不大，看起来并没有什么瓶颈。然则继续看load profile和instance efficiency percentages就能够发现有两个明显的问题，即physical read和buffer hit；从awr中明显能够看到，此时内容库的物理读对照大(9000+块/秒)，而buffer hit仅有80%。
很明显，buffer的命中率过低。该值过低则阐明我们必要查询的内容，在buffer中可能并没有。此时，内容库则会到磁盘中对内容进行读取。因此，也会造成此时内容库的物理读非常大。
此时，第一个想法便是看看内容库的内存分配环境是否显现不合理，导致大部门的内容无法缓存到内存中。继续从awr的内存部门进行查看：
发现SGA的巨细为4G。而在最起头搜检该内容库主机分配的内存巨细为16G。能够看出来，SGA分配的比例有确实有点小，仅占整个主机的1/4。
三、原因阐明
根据上述的排查过程，其实能够明显发现，在该体系中眼前有四个个问题对照明显：
本文地址：http://www.wbwb.net/bianchengyuyan/223821.html 转载请注明出处！