RE: large sga or not,your experience--Re: buffer cache -once agai

And then there is the database that started out a OLTP. But some manager(s) figure that, as long as the data was there, it might well be used for running reports ..... and we might want to go back three years on those reports. Then you're damned if you have big SGA, and damned if you don't. So what do you do? THROW MORE HARDWARE AT IT.

It's all about reports. Reports Reports Reports. Gotta have those reports. The world revolves around reports. Keep those printers running. Kill some trees.

> -----Original Message-----
> From: Stephane Faroult [mailto:sfaroult_at_oriolecorp.com]
> Sent: Wednesday, May 07, 2003 4:47 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: large sga or not,your experience--Re: buffer cache -once
> again,
>
>
> The ultimate question is 'Is it faster?'. It widely depends
> on what you are doing, and how you are doing it. In your
> case, I presume that the activity is mainly batch programs -
> because I wouldn't leave 5 Gigs out of 16 to the system plus
> the users on a big OLTP system. If you had a number of users
> doing massive sorts at once, you could expect things to be
> really bad. Configurations such as MTS, in which huge part of
> memory requirements are moved from PGA to SGA would
> proportionally need a larger SGA. Also, a DSS system where
> (bar those nightly loads) most queries are SELECT is more
> appropriate for a very large SGA. Otherwise, if a huge number
> of blocks are modified, DBWR and its underlings may have to
> work like crazy trying to catch up when there is a
> checkpoint, which can cause trouble with the redo logs ...
> If your configuration works well and users are satisfied, no
> need to worry ...
>
> SF
>
>
> >----- ------- Original Message ------- -----
> >From: "zhu chao" <chao_ping_at_vip.163.com>
> >To: Multiple recipients of list ORACLE-L
> ><ORACLE-L_at_fatcity.com>
> >Sent: Tue, 06 May 2003 20:55:30
> >
> >Hi,
> > Many professionals like Jonathan Lewis(From
> >metalink note, sorry I forget that link)
> >quote
> > It __IS__ possible to make things worse by
> >increasing the
> > buffer to extreme levels. For example, you may
> >allow
> > Oracle to keep more CR copies of blocks that
> >have been
> > updated - this will tend to make the hash
> >chains that
> > need to be searched much longer, and therefore
> >increase
> > the contention on the cache buffers chains
> >latch.
> >
> > And Craig A. Shallahamer's
> > So , according your experience, what about
> >your sga size with huge amount of physical memory?
> >My personal experience of setup a 13G sga on 16G
> >memory machine is pretty good till now.Physical
> >reads dropped to 1/2 compared to the physical reads
> >when sga is 8G.
> >
> >Regards
> >zhu chao
> >msn:chao_ping_at_163.com
> >www.cnoug.org(China Oracle User Group)
> >----- Original Message -----
> >To: "Multiple recipients of list ORACLE-L"
> ><ORACLE-L_at_fatcity.com>
> >Sent: Tuesday, May 06, 2003 10:12 PM
> >
> >
> >> Arvind
> >> What makes you suspect you've configured your
> >buffer cache too large? A
> >> better question might be "how can I tell if my
> >buffer cache is properly
> >> sized?". Start by checking your wait times. What
> >are your top 3 waits? Also,
> >> what is your (cough, cough) average buffer hit
> >ratio?
> >>
> >> Dennis Williams
> >> DBA, 60%OCP, 100% DBA
> >> Lifetouch, Inc.
> >> dwilliams_at_lifetouch.com
> >>
> >>
> >> -----Original Message-----
> >> Sent: Tuesday, May 06, 2003 4:37 AM
> >> To: Multiple recipients of list ORACLE-L
> >>
> >>
> >> Dear All,
> >>
> >> how can i check if my buffer cache is bigger
> >than necessary ?oracle db
> >> version is 8.1.7.
> >>
> >>
> >> Thanks
> >>
> >>
> >> Arvind
> >>
> >>
> >> --
> >> Please see the official ORACLE-L FAQ:
> >http://www.orafaq.net
> >> --
> >> Author: Arvind Kumar
> >> INET: arvindk_at_sqlstarintl.com
> >>
> >
> >>
> >
> >>
> >>
> >--
> >Please see the official ORACLE-L FAQ:
> >http://www.orafaq.net
> >--
> >Author: zhu chao
> > INET: chao_ping_at_vip.163.com
> >
> >Fat City Network Services -- 858-538-5051
> >http://www.fatcity.com
> >San Diego, California -- Mailing list and
> >web hosting services
> >To REMOVE yourself from this mailing list, send an
> >E-Mail message
> >to: ListGuru_at_fatcity.com (note EXACT spelling of
> >'ListGuru') and in
> >the message BODY, include a line containing: UNSUB
> >ORACLE-L
> >(or the name of mailing list you want to be removed
> >from). You may
> >also send the HELP command for other information
> >(like subscribing).
> >paper:http://www.orapub.com/cgi/genesis.cgi?p1=sub&
> >p2=abs136, it also says large sga can give bad
> >performance.
> >---------------------------------------------------
> >------------------
>
> Regards,
>
> Stephane Faroult
> Oriole
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Stephane Faroult
> INET: sfaroult_at_oriolecorp.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephen Lee
  INET: Stephen.Lee_at_DTAG.Com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).