RE: v$rowcache outstanding_alerts

-----Original Message-----

From: Sweetser, Joe [mailto:JSweetser_at_icat.com] Sent: Thursday, November 15, 2012 1:30 PM To: Walker, Jed S; oracle-l_at_freelists.org Subject: RE: v$rowcache outstanding_alerts

Also found this:

The sequence IDGEN1$ is a sequence in SYS dealing with Transportable tablespace, therefore you should under no circumstances touch it.

Here: http://www.orafaq.com/forum/t/91174/2/

The thread is around someone using idgen1$.nextval. (no comment) And I have no idea if the information above is accurate but maybe it's something to look at if you use TTs.

-joe

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Walker, Jed S Sent: Thursday, November 15, 2012 12:45 PM To: oracle-l_at_freelists.org
Subject: RE: v$rowcache outstanding_alerts

Thanks Joe, I'm not sure why I didn't find that one.

So, it would appear that I'll have to leave it and accept that dc_sequences will have a high miss ratio. I checked another system (non-RAC) and the sequence has never been used.

" it is an internal sequence created at database creation that we use internally for various things." It'd sure be nice to have more info than that.

-----Original Message-----

From: Sweetser, Joe [mailto:JSweetser_at_icat.com] Sent: Thursday, November 15, 2012 12:35 PM To: Walker, Jed S; oracle-l_at_freelists.org Subject: RE: v$rowcache outstanding_alerts

This has some info on it: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3303121200346990096

hth,
-joe

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Walker, Jed S Sent: Thursday, November 15, 2012 12:31 PM To: oracle-l_at_freelists.org
Subject: RE: v$rowcache outstanding_alerts

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

Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.

--

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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Nov 15 2012 - 21:33:12 CET