Re: buffer advisor

From: Ls Cheng <exriscer_at_gmail.com>
Date: Sun, 7 Sep 2014 23:17:10 +0200
Message-ID: <CAJ2-Qb99TJrxsKaeCo_U8XChQ3ym7+--T8onvqrZLLAKnBgqLA_at_mail.gmail.com>

AMM and ASMM are ok only if we set some minimum values IMHO. We cannot rely on them 100%

On Sun, Sep 7, 2014 at 10:55 AM, Jaromir D.B.Nemec <jaromir_at_db-nemec.com> wrote:

> 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_at_freelists.org]
> 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_at_freelists.org> (Redacted sender
> "yong321_at_yahoo.com" 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_at_gmail.com>
>
> 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_at_gmail.com>
>
> 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_at_gmail.com>
> 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_at_gmail.com> 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_at_gmail.com>
> >> 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_at_gmail.com> 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_at_gmail.com>
>
> 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_at_yahoo.com> 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
> *******************************
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Sun Sep 07 2014 - 23:17:10 CEST