pga 占有内存太大

juniper

最初由 risepp 发布
[B]ORACLE不会有那么多BUG吧  可以说说你那些过程都做了些什么操作么?? [/B]

ORACLE的bug还真不少，你到metalink上看看就知道了。

jametong

并行性怎么样啊..

每个进程最多使用两倍的sort_area_size,  pga其他方面的内存使用变化不会很大啊..

dream_looker

这确实是oracle :9201的bug，升级到9204应该可以解决

itpub110

pga过大的问题我这也碰到过，我这里的情况是长时间运行的后台应用程序写的不是很好，内存越用越多，最后的症状就是os级的监控程序发现大量的swap in/out。我这边好办，程序里的小问题揪一揪就好了。
不知道楼主的问题解决了没有，关注中。。。

juniper

最初由 itpub110 发布
[B]pga过大的问题我这也碰到过，我这里的情况是长时间运行的后台应用程序写的不是很好，内存越用越多，最后的症状就是os级的监控程序发现大量的swap in/out。我这边好办，程序里的小问题揪一揪就好了。
不知道楼主的问题解决了没有，关注中。。。 [/B]

还是没有解决，还好memory够大，硬撑。

juniper

最初由 dream_looker 发布
[B]这确实是oracle :9201的bug，升级到9204应该可以解决 [/B]

我也怀疑是bug，不过现在跑生产，还不敢升。
9201这个版本问题多多。

funnyok

最初由 juniper 发布
[B]
还是没有解决，还好memory够大，硬撑。 [/B]

呵呵，软件不行的，硬件解决。
如果限制一下pga的target是解决还是报错？——至少目前来看pga上200的都是有问题的。

itpub110

最初由 juniper 发布
[B]
还是没有解决，还好memory够大，硬撑。 [/B]

JOB_QUEUE_PROCESSES这个参数是dynamic的，是不是可以做点文章？或者干脆直接起个SQL/PLUS执行一下那个job，看要耗掉多少PGA

WL_ZCJ

要看你写的程序，有次我们的同事写了这么一个语句：
update t112_card  a set addr= (select addr from custom b where a.num=b.num);
因为我们这两个表都是将近1G，因为这一个语句我的回滚段和内存都被大量的消耗，数据库几近不动作

wangdows

怀疑它是oracle的bug一点都不为过，因为在9206和10.1.0.3前确实存在关于jxxx内存泄漏的bug。

建议您作如下追踪：
1. oracle方式
  select a.sid, a.statistic#, b.name, a.value   from v$sesstat a, v$statname b   where a.sid in (select /*+ rule */ sid from dba_jobs_running where  job=<your job id>   and b.statistic# in (20,21)   and a.statistic# = b.statistic#
过一段时间，不一定mv被刷新，再运行一次，比较pga大小变化。

2.hp方式
命令kmeminfo用于分析hpux上的内存泄漏问题，当然这个工具不被HP官方支持（并使不说工具会影响您的生产系统，只是hp不对这种无法收费的行为负责）。工具和使用方法可以向800要。

讨论回复：
samsondows@yahoo.com.cn