• 博客访问: 68352
  • 博文数量: 59
  • 用 户 组: 普通用户
  • 注册时间: 2010-03-27 17:24
个人简介

暂无介绍

文章分类

全部博文(59)

文章存档

2011年(21)

2010年(38)

我的朋友

分类: Linux操作系统

2011-05-20 13:06:50

查了挺久的问题了。

用户反应早上第一笔业务,查询缓慢,之后每笔业务均能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法则进行清除。
阅读(899) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册