查了挺久的问题了。
用户反应早上第一笔业务，查询缓慢，之后每笔业务均能1S内返回。
从现象上分析，应该是此业务所需的表数据不在SGA内，而采用物理读的方式进行第一次访问，造成效率比较低。由于此库上跑了好几套业务，无法从全局确定问题。但是从statspack还是能看到些迹象的。
首次响应缓慢时 Buffer Hit %: 98.36
之后时间段的查询 Buffer Hit %: 100.00
由于业务分布比较乱，statspack中，无法直接看到用户反应慢的语句，但是可以注意到在用户操作前，其他业务有一语句，物理读高达50W次以上，2G多的数据被读入SGA，造成核心应用需要的数据被挤出了SGA。
联系应用开发商，从应用端捕获了用户操作所触发的语句。将牵涉到的表全部缓存到sga的keep_pool中，使其不被其他大的数据操作刷出。
经测试，第二天第一笔交易1S内返回。
顺便做了个测试，如果放到keep pool的表，增长超过了keeppool的指定大小怎么办。
根据官方文档：
Note:
If an object grows in size, then it might no longer fit in the KEEP buffer pool. You will begin to lose blocks out of the cache.发生这类情况，若表大于keep_pool_size的设置，会被留在buffer_pool中，根据lru法则进行清除。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/7969839/viewspace-695827/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
查看oracle隐含参数脚本
请登录后发表评论
登录
全部评论
