Re: High Version count in V$SQLAREA

"Mark D Powell" <Mark.Powell_at_eds.com> wrote in message news:2687bb95.0307080510.2c4d671b_at_posting.google.com...
> srivenu_at_hotmail.com (srivenu) wrote in message news:<1a68177.0307072253.60403427_at_posting.google.com>...
> > Hi yong,
> > Thanks for the reply.
> > I dont think the versions are created due to change in bind lengths as
> > they are issued by the same application (same part).
> > As far as changes in optimizer parameters, i have to check it out. But
> > version count of 100 is i think too much. is it not ?
> > As far as i remember, I didn't change any optimizer parameters.
> > regards
> > Srivenu
>
> We have seen the same issue. Actually Oracle support noticed the
> problem while working on trace files filed with an iTAR related to
> 04031 errors that started occuring after we upgraded to 64 bit Oracle
> from 32 bit. Support said the cursors, which are coming from packaged
> code, should be shared but are not. It is very possible what you are
> seeing is the result of coding/logic errors within Oracle's code.
>
> HTH -- Mark D Powell --

That reminds me: We also had the high version count problem in the 8.1.6.3 database and Oracle Support (If i remember correctly) advised setting _sqlexec_progression_cost to 0. I think it had something to do with the view v$longops being populated, resulting in high version counts.

So yes .. search on metalink for "high version counts" and you might see some BUGs which might be causing this. What srivenu reported seems like too high a value, which most probably is a result of a BUG. Sadly sometimes the workaround is to flush the shared pool at an appropriate time (if its getting to be a menace) ....

Anurag Received on Tue Jul 08 2003 - 17:59:05 CDT