RE: v$rowcache outstanding_alerts

From: Walker, Jed S <Jed_Walker_at_cable.comcast.com>
Date: Thu, 15 Nov 2012 19:30:46 +0000
Message-ID: <BAA6E28B6241F046AED1E62D8697516C6F540F75_at_COPDCEXMB08.cable.comcast.com>



Thanks Tanel.
I've modified the application sequences and noticed the overall miss ratio not improving. I discovered this sequence:

SYS.IDGEN1$ It has a cache_size of 1000; however, the last_number is updating by 10,000 values per minute. I also posted this on MOC, but was hoping someone here might know about this sequence -

  1. What is it for?
  2. How to find if there is an issue causing it to update so rapidly
  3. Can one safely increase the cache size on it?

Thanks,

Jed

From: tanel_at_poderc.com [mailto:tanel_at_poderc.com] On Behalf Of Tanel Poder Sent: Wednesday, November 14, 2012 6:17 PM To: Walker, Jed S
Cc: oracle-l_at_freelists.org
Subject: Re: v$rowcache outstanding_alerts

It's used for server alerting infrastructure (metrics thresholds, tablespace space etc)

DESC dba_outstanding_alerts
DESC dbms_server_alert
SELECT * FROM v$alert_types;

I wouldn't worry about the miss ratio as this may be just due to the alerts being read infrequently (after they've been aged out from cache) and this number has accumulated over a long time...

--

Tanel Poder
Blog - http://blog.tanelpoder.com
App - http://voic.ee

On Thu, Nov 15, 2012 at 12:46 AM, Walker, Jed S <Jed_Walker_at_cable.comcast.com<mailto:Jed_Walker_at_cable.comcast.com>> wrote: I am looking in the v$rowcache table and found something that I haven't been able to find out about.

PARAMETER                             COUNT MODIFICATIONS       GETS  GETMISSES   MISS_PCT

-------------------------------- ---------- ------------- ---------- ---------- ----------
... outstanding_alerts 4 739 59443 56431 94.93

Does anyone know what this particular item is, and why it would have such a high miss percentage?

Thanks,

Jed

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Thu Nov 15 2012 - 20:30:46 CET

Original text of this message