Re: v$rowcache outstanding_alerts
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: Jed_Walker@xxxxxxxxxxxxxxxxx
- Date: Sat, 17 Nov 2012 12:16:09 +0200
You should worry about sequence settings only when either the "sequence
load elapsed time" shows up in session time model (as a significant portion
of the response time) or "enq: SQ - contention" shows up in waits (again
taking a significant portion of response time).
--
*Tanel Poder*
Enkitec Europe
+372 56 956 181
http://www.enkitec.com/
Expert Oracle Exadata book:
http://www.apress.com/9781430233923
On Thu, Nov 15, 2012 at 9:30 PM, Walker, Jed S <Jed_Walker@xxxxxxxxxxxxxxxxx
> wrote:
> 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@xxxxxxxxxx [mailto:tanel@xxxxxxxxxx] On Behalf Of Tanel Poder
> Sent: Wednesday, November 14, 2012 6:17 PM
> To: Walker, Jed S
> Cc: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxx<mailto:Jed_Walker@xxxxxxxxxxxxxxxxx>> 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
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
