Re: buffer advisor
- From: "Jaromir D.B.Nemec" <jaromir@xxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 7 Sep 2014 10:55:56 +0200
Hi,
> ... but I dont think experienced DBA should rely on them (AMM and ASMM).
Dont you think so?
I'd say in 80% of cases it's OK. The responsibility of experienced DBA is to
recognise the 20%:)
Jaromir D.B. Nemec
-----Original Message-----
From: FreeLists Mailing List Manager [mailto:ecartis@xxxxxxxxxxxxx]
Sent: Sonntag, 07. September 2014 07:05
To: oracle-l digest users
Subject: oracle-l Digest V11 #250
oracle-l Digest Sat, 06 Sep 2014 Volume: 11 Issue: 250
In This Issue:
Re: buffer advisor
Change VIP name and IP
Re: buffer advisor
Re: buffer advisor
----------------------------------------------------------------------
Date: Sat, 6 Sep 2014 07:13:17 -0700
From: "Yong Huang" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender
"yong321@xxxxxxxxx" for DMARC)
Subject: Re: buffer advisor
I personally never look at the advisor. Neither do my coworkers. So I always
set db_cache_advice to off.
If other advisory related parameters were not underscored, such as
_library_cache_advice, _db_mttr_advice, _smm_advice_enabled, I would disable
them too. (They can be disabled by statistics_level=basic but you lose too
much good stuff with it.) I think they're related to various simulator
activities and SGA memory chunks. The less the better.
------------------------------
Date: Sat, 6 Sep 2014 11:51:45 -0700
Subject: Change VIP name and IP
From: Kumar Madduri <ksmadduri@xxxxxxxxx>
Hello
I have followed 276434.1 (Case IV) for a 11gR2 Grid infrastructure install
and changed the vip name and ip address. No errors were reported and ocrdump
before and after shows that the new vip name is picked up. srvctl config
nodeapps also shows the new vipname and ip address but crsctl stat res -t
shows the old vipname under NAME .
I could not modify it as well
oracle:+ASM1> crsctl modify resource ora.ofdbracdev02.vip -attr
NAME=ora.ofdbracdev2.vip
CRS-2547: Update of an internal or read-only attribute 'NAME (READONLY)'
for resource 'ora.ofdbracdev02.vip' is not allowed Any of you who have done
a similar change noticed the same?
Thank you
Kumar
------------------------------
Date: Sat, 6 Sep 2014 23:15:03 +0200
Subject: Re: buffer advisor
From: Ls Cheng <exriscer@xxxxxxxxx>
Hi Seth
If an app does not use bind variables then no matter how shared pool is
sized (we can set 1TB and hard parsing is still going on) hard parsing will
always occur so have larger shared pool means hard parsing will not be
reduced so I dont think ASMM should favor in such drastic way the shared
pool. AMM and ASMM are features to simplify management so Oracle can tell
customer that the database is easier to manage but I dont think experienced
DBA should rely on them. Dont you think so?
Thanks
On Fri, Sep 5, 2014 at 7:22 PM, Seth Miller <sethmiller.sm@xxxxxxxxx> wrote:
> Chris,
>
> I believe "a few situations" qualify as exceptions. The developers
> have to write these tools to work with the majority of cases, not the
exceptions.
> This is why the DBA still has the ability to set a minimum size for
> each of the managed pools.
>
> Hard parsing is extremely expensive so it doesn't surprise me that
> ASMM would favor the shared pool over the buffer cache, especially
> when you consider that there are alternatives to the buffer cache like
> the keep pool. There is no such in-memory alternative for the library
cache.
>
> Seth Miller
>
>
> On Thu, Sep 4, 2014 at 5:50 PM, Chris Taylor <
> christopherdtaylor1994@xxxxxxxxx> wrote:
>
>> Seth,
>>
>> Really? I have run into a few situations where the advisor
>> undersizes the buffer cache significantly in favor of the shared pool
>> because of the workload of the application.
>> I've got a db right _now_ that has a 128MB buffer cache and a 20GB
>> shared pool that AMM resized because of the workload :)
>>
>> Obviously, the solution to this is to set floor (minimum) values for
>> shared_pool_size and db_cache_size but it still amazes me that
>> ASMM/AMM will significantly undersize the buffer cache when the
>> workload uses a lot of SQL that isn't reuseable.
>>
>> And I clearly recognize that the workload is suboptimal (lots of SQL
>> with literals and a few other things) that favor a large shared pool,
>> and my only point is that it isn't uncommon for the automatic memory
>> resizing to size the buffer cache to an absurd size :)
>>
>> Chris
>>
>>
>> On Thu, Sep 4, 2014 at 4:56 PM, Seth Miller <sethmiller.sm@xxxxxxxxx>
>> wrote:
>>
>>> Ls,
>>>
>>> I have found with very few exceptions that ASMM (SGA_TARGET) is very
>>> good at sizing the buffer cache. Have you tried this?
>>>
>>> Seth Miller
>>> On Sep 4, 2014 3:38 PM, "Ls Cheng" <exriscer@xxxxxxxxx> wrote:
>>>
>>>> Hi all
>>>>
>>>> Has anyone used buffer cache advisory in 10g or 11g to size a
>>>> production buffer cache? If so how good is the advisor recommending
>>>> the cache size? Did the recommended cache size meet the ohysical
>>>> reads reduction goal?
>>>>
>>>> TIA
>>>>
>>>>
>>>>
>>
>
------------------------------
Date: Sat, 6 Sep 2014 23:18:35 +0200
Subject: Re: buffer advisor
From: Ls Cheng <exriscer@xxxxxxxxx>
I dont neither, I only looked a couple of times around 8, 9 years ago.
Guess it is still as "good" as before :-)
On Sat, Sep 6, 2014 at 4:13 PM, Yong Huang <yong321@xxxxxxxxx> wrote:
> I personally never look at the advisor. Neither do my coworkers. So I
> always set db_cache_advice to off.
>
> If other advisory related parameters were not underscored, such as
> _library_cache_advice, _db_mttr_advice, _smm_advice_enabled, I would
> disable them too. (They can be disabled by statistics_level=basic but
> you lose too much good stuff with it.) I think they're related to
> various simulator activities and SGA memory chunks. The less the better.
>
>
------------------------------
End of oracle-l Digest V11 #250
*******************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
