Re: Poor Performance on Oracle9i - 9.2.0.7

Hi,

if your OS allows only 2.78 GB of shared memory, then your OS admin made something wrong in the OS configuration. Solaris 6 is definitely able to provide more than 2.78GB of shared memory if your server has 24GB memory. Please check if you're run in 64bit mode. Is your Oracle instance 64bit? If yes check the shmmax parameter in /etc/system. After setting it to 20GB you should be able to allocate almost 20GB SGA.

Regards
Ralph

"eavanzi" <eavanzi_at_romi.com.br> wrote in message news:1146968486.656701.14300_at_e56g2000cwe.googlegroups.com...
> Hi, Bob.
> I have flushed the shared pool but it is not resolving the problem.
> I have observed the performance is a little better from 07:00am until
> 11:30am. It is more poor from 14:00pm until 17:00pm.
> The system goes being slower, slower, slower, ..., then I shutdown the
> database and start the database again and the performance is better.
> Then the system goes being slower, slower, slower, ....
>
> Hi, Remigiusz.
> My Operating System is Solaris 2.6 and it is not allowing the SGA can
> be greater than 2,78GB. :-(
> We are intending upgrade from Solaris 2.6 to Solaris 9 in the next
> days, then I will be able to set the SGA to another value.
> I have 350 active Oracle Applications users.
> The values that you are suggesting are to 2,000 users or more.
> db_cache_size = 6G
> shared_pool_size = 3G
> pga_aggregate_target = 15G
> It will be that using a SGA too large the performance could be
> improved?
> Why the parameters shared_pool_size and shared_pool_reserved_size are
> noted as N/A to 101-500 users in the Note:216205.1??
> Do I need to remove these parameters in the init.ora ??
> About the filesystems. I use the Veritas Volume Manager and RAID 5 (in
> hardware).
> When it will be Solaris 9 I will use the Solaris Volume Manager and
> RAID 5 (in hardware).
>
> Hi, Vladimir.
>>2) remove event 10235...
> Answer: The event 10235 was recommeded by Oracle Support because we had
> many ORA-0600 errors.
>>3) session_cached_cursors of 4000 seems a bit too much, what was the
>>reason for bumping it so high?
> Answer: It was the value that I used in 8.1.7.4
>>4) How were the pools configured prior to migration? Specifically, what
>>were the shared pool and the buffer cache sizes?
> Answer: I need to check these values. At the moment (Saturday) I am in
> my house. At Monday I will check them for you.
>
> This performance problem is sinking me!!
> I need all help than is possible!!
> Thanks for all.
>
Received on Sun May 07 2006 - 01:28:02 CDT