Re: How to troubleshoot heavy RAM consumption
- From: Neil Kodner <nkodner@xxxxxxxxx>
- To: Jared Still <jkstill@xxxxxxxxx>
- Date: Wed, 10 Mar 2010 17:10:04 -0700
As the business day draws to a close, we're sitting at 1.19gb free in
v$sgastat, out of a 12gb sga_max_size/target.
On Wed, Mar 10, 2010 at 5:03 PM, Neil Kodner <nkodner@xxxxxxxxx> wrote:
> Thanks Jared. I'm trying to figure out if we are in need of more tuning,
> or if its a case of outgrowing our hardware. I'm leaning 98% toward the
> latter. Without giving up too much information, the economic and employment
> situation has caused our db use to grow at a VERY large level. We built
> this server 5-6 years ago before. We used to sit at about 700-800
> connections, we now push about 1700, all from internal and external facing
> applications.
>
>
> On Wed, Mar 10, 2010 at 4:57 PM, Jared Still <jkstill@xxxxxxxxx> wrote:
>
>>
>> On Wed, Mar 10, 2010 at 2:09 PM, Neil Kodner <nkodner@xxxxxxxxx> wrote:
>>
>>> Thanks. As an aside, while we're having memory/paging issues, is there a
>>> good way to tell if our SGA is in fact too large? One of the challenges
>>> that we face is that one of the heavier-used applications does not use
>>> prepared statements and that has the potential to pollute the shared pool.
>>> We enable cursor-sharing at the session level for these users.
>>>
>>>
>> In general I would think the SGA too large if there were more
>> free memory available at peak periods than need be.
>>
>> select *
>> from v$sgastat
>> where name = 'free memory'
>> order by upper(name)
>> /
>>
>> The 'need be' is the hard part. I personally don't have to go
>> through this kind of exercise very often.
>>
>> If I had allocated 12 gig for an SGA and consistently had 2 gig
>> free I would certainly consider distributing some of that elsewhere.
>>
>> Jared Still
>> Certifiable Oracle DBA and Part Time Perl Evangelist
>> Oracle Blog: http://jkstill.blogspot.com
>> Home Page: http://jaredstill.com
>>
>>
>>
>
Other related posts:
