☰

SQL 区域意外扩展

tag-icon • tag-icon oracle-11g
SQL 区域意外扩展

我们在 Oracle 11.1.0.7 上使用自动内存管理。上周五，共享池意外地从约 600MB 增加到约 850MB。内存来自缓冲区缓存，从约 400 增加到约 150。不用说，系统执行的磁盘读取次数比以前多得多。到目前为止，我还无法证明这是一个不正确的更改，但在我看来这肯定不对。我想知道是什么原因造成的，这样我就可以扭转它。

我做了一个前后的 AWR 比较，发现共享池的增加几乎全部发生在 SQL 区域。我使用如下查询查看了存储在那里的 SQL，但没有发现最近发生的任何变化：

--Replace anything in quotes and numbers with % so that statements not using
--bind variables group together.
SELECT count(*), Trunc(sum(sharable_mem)/1024/1024) SharableMemory, 
   regexp_replace(regexp_replace(
      sql_text,'.\''.+\''','''%'''),'[0-9]+','%') || ''';' sql
FROM v$sql
GROUP BY regexp_replace(regexp_replace(
   sql_text,'.\''.+\''','''%'''),'[0-9]+','%')
HAVING sum(sharable_mem) > 2*1024*1024
ORDER BY Trunc(sum(sharable_mem)/1024/1024) DESC;

我也尝试过刷新共享池。系统不会将任何共享池交给缓冲区缓存，可能是因为刷新后大小增加得太快了。

我还尝试设置缓冲区缓存的最小大小，以强制它放弃共享池中的内存。在我的测试系统上，这种方法允许我将缓冲区缓存增加约 100MB，但在我的实时系统上，它甚至不会增加 3MB，然后就会出现错误，指示没有足够的内存来执行操作。

警报日志在发生更改时显示“Sweep Incident[77273]: done”。我在 metalink 上找不到太多相关信息。它还显示 DIA0 在那个时间附近重新启动，但我看不出这两者之间有什么关联。

以下是一些可能不相关的说明。AWR 显示，库缓存中所有命名空间的 pin 请求数量几乎是问题发生前的两倍。大约一个月前，数据库从 10.2.0.4 升级。在问题发生前大约一周，会话数量从约 200 个增加到约 250 个。

我将重启实例作为最后的手段，因为我不知道它是否有帮助。

任何建议，将不胜感激。

答案1

重启！

相关内容