Re: Performance issue
From: Hugo.Contreras <hugo.e.contreras_at_gmail.com>
Date: Fri, 20 Mar 2009 12:06:29 -0700 (PDT)
Message-ID: <85bc4984-8df9-4302-ad72-10423ccec79e_at_v5g2000prm.googlegroups.com>
On Mar 20, 12:32 pm, "SEJ" <sej..._at_hotmail.com> wrote:
> "Jenny" <jjohni..._at_gmail.com> skrev i en meddelelsenews:ef2c918c-051c-46f6-af10-41b0774a9f18_at_v18g2000pro.googlegroups.com...
>
> > our database oracle 9i is running on tru64. Db's performance degrades
> > as the time goes on, later we bounce the DB and also restarts the
> > machine. after restart the performance increases drastically and as
> > time goes performance degrade.
> > Can anyone tell what the problem is and also a solution 4 it
>
> Hi Jenny
>
> I have observed similar on a windows box where your statements get aged out
> over time, but it was on 10g. the problem was not on 9i but whe observed
> longer parse time in 10g, the solution was cursor_sharing=similar, the
> application di not have bind in all statements
>
> regards
>
> SEJ
I agree with Mladen Gogala, How many concurrent users are accessing your database when your performance problem starts?. What is the size of your SGA?, Total RAM on your server?
Date: Fri, 20 Mar 2009 12:06:29 -0700 (PDT)
Message-ID: <85bc4984-8df9-4302-ad72-10423ccec79e_at_v5g2000prm.googlegroups.com>
On Mar 20, 12:32 pm, "SEJ" <sej..._at_hotmail.com> wrote:
> "Jenny" <jjohni..._at_gmail.com> skrev i en meddelelsenews:ef2c918c-051c-46f6-af10-41b0774a9f18_at_v18g2000pro.googlegroups.com...
>
> > our database oracle 9i is running on tru64. Db's performance degrades
> > as the time goes on, later we bounce the DB and also restarts the
> > machine. after restart the performance increases drastically and as
> > time goes performance degrade.
> > Can anyone tell what the problem is and also a solution 4 it
>
> Hi Jenny
>
> I have observed similar on a windows box where your statements get aged out
> over time, but it was on 10g. the problem was not on 9i but whe observed
> longer parse time in 10g, the solution was cursor_sharing=similar, the
> application di not have bind in all statements
>
> regards
>
> SEJ
I agree with Mladen Gogala, How many concurrent users are accessing your database when your performance problem starts?. What is the size of your SGA?, Total RAM on your server?
Remember that (depending on the size of the sga) each process created on the database can consume ~20Mb of memory. So, if you have 200 concurrent users, make sure that you have at least 4 GB of free memory after starting your instance, otherwise you will experience performance problems as more users connect.
Regards,
Hugo Received on Fri Mar 20 2009 - 14:06:29 CDT