"Anurag Varma" <avdbi_at_hotmail.com> wrote in message news:<Z0IOa.20$0y6.1_at_news02.roc.ny>...
> "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
Thanks for the reply. We just bounce our systems every other week to
avoid the 04031 errors which occur at around 26 days of operation.
Upgrading from 8.1.7.0 to .2 then .4 did not solve the problem so we
are waiting to see if 9.2 will work come late fall if our schedule
holds. The shared pool was 60M from version 7 - 8 and we had to add
20M (25%) to run under 32 bit 8.1. With the 64 bit version we tried
increasing the pool up to 200M at Oracle request and each increase
just delayed the onset of the problem. The problem might also exist
in the 32 bit version but since we not on it for very long before
converting and were performing a lot of maintenance we may not have
encountered it. We also moved platforms when we went to 64 bit, from
Sequent Dynix to IBM AIX so our specific problem might be platform
specific.
Received on Wed Jul 09 2003 - 09:07:47 CDT
