Re: ASMM question

From: joel garry <joel-garry_at_home.com>
Date: Mon, 7 Apr 2008 10:15:30 -0700 (PDT)
Message-ID: <ffa9a8b4-a93b-4f52-86dd-3c6b85ed1a16@w5g2000prd.googlegroups.com>


On Apr 5, 12:58 am, Ind-dba <oraclear..._at_googlemail.com> wrote:
> On Apr 4, 2:59 am, Chuck <skilover_nos..._at_bluebottle.com> wrote:
>
>
>
>
>
> > Mark D Powell wrote:
> > > On Apr 2, 11:58 am, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
> > >> On Apr 2, 10:56 am, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
>
> > >>> On Apr 2, 10:49 am, Chuck <skilover_nos..._at_bluebottle.com> wrote:
> > >>>> sga_target_size = 4g
> > >>>> sga_max_size = 6g
> > >>>> When the instance starts, how much memory will it try to allocate? 6g or
> > >>>> 4g?
> > >>>> If I run "show sga" on the instance it says total sga size is 6g. If I
> > >>>> run "ipcs -ma" on the o/s (solaris 10) it shows the shared memory
> > >>>> segment as being only 4g.
> > >>>> I'm a little confused as to what's really being allocated as there seems
> > >>>> to be some contradiction here.
> > >>>> TIA.
> > >>> ipcs reports what is actually allocated, which is the
> > >>> sga_target_size.  sga_max_size is your 'wiggle room' for dynamic
> > >>> adjustments.
> > >>> David Fitzjarrell
> > >> To add to my last post, show sga reports the maximum size the SGA can
> > >> attain, not the actual sga allocation.  I expect that if you look at v
> > >> $sgastat you'll find it agrees with the sga_target_size setting, not
> > >> with the sga_max_size value.
>
> > >> David Fitzjarrell- Hide quoted text -
>
> > >> - Show quoted text -
>
> > > Be advised that this feature is platform dependend and on some
> > > platforms the full amount of shared memory still has to be acquired on
> > > startup.  On these platforms the sga_target should = the sga_max.
>
> > > Check your platform specific documentation.
>
> > > HTH -- Mark D Powell --
>
> > Thanks all- Hide quoted text -
>
> > - Show quoted text -
>
> At the time of startup, "always" memory equal to sga_max_size (nearly)
> is acquired. I believe, its not platform dependent.The only platform
> dependency is size of one shared memory segment. On all platforms,
> oracle doesnt transact with OS for memory after startup. It can only
> exchange memory between different caches.. But it can never allocate
> say 4g based on sga_target and expany to 8g (based on sga_max_size).
> That is why sga_max_size is fixed parameter and sga_target is dynamic.
>
> Oracle documentation: The maximum amount of memory usable by the
> instance is determined at instance startup by the initialization
> parameter SGA_MAX_SIZE.
>
> Proof:

Er, saying you believe something across platforms and then showing the proof on one platform is kind of silly. Some platforms handle shared memory quite differently.

I haven't been following the details for recent versions, but in the past Mark was certainly correct, mostly an issue on 32 bit OS's. You can poke about on metalink and see old notes about windowing on hp-ux, changing sgabeg on solaris, pre_page_sga, tech explanation of semaphores and shared memory and how some platforms use them differently. Note:341782.1 for linux, you can't say there is only one answer there. Note:470742.1 for example, shows a difference with dispatchers.

I would recommend reading the tech explanations to anyone not familiar with that stuff (Note:153961.1, Note:15566.1 etc.). The granularization is explained in Note:148495.1.

> bash-3.00$ uname -a
> SunOS oracle-edu 5.10 Generic_125101-02 i86pc i386 i86pc
> SQL> sho sga
>
> Total System Global Area  922746880 bytes
> Fixed Size                  2271688 bytes
> Variable Size             375621176 bytes
> Database Buffers          490733568 bytes
> Redo Buffers               54120448 bytes
>
> bash-3.00$ ipcs -ma
> IPC status from <running system> as of Sat Apr  5 00:52:16 PDT 2008
> T         ID      KEY        MODE        OWNER    GROUP  CREATOR
> CGROUP NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
> Shared Memory:
> m 1912602676   0x5c6c2c28 --rw-r-----   oracle      dba   oracle
> dba     26      12288  3498 13703  0:51:47  0:51:47  2:24:56
> m 1912602675   0          --rw-r-----   oracle      dba   oracle
> dba     26  142606336  3498 13703  0:51:47  0:51:30  2:24:56
> m 1912602674   0          --rw-r-----   oracle      dba   oracle
> dba     26  192937984  3498 13703  0:51:47  0:51:30  2:24:56
> m 1912602673   0          --rw-r-----   oracle      dba   oracle
> dba     26  138412032  3498 13703  0:51:47  0:51:30  2:24:56
> m  637534256   0          --rw-r-----   oracle      dba   oracle
> dba     26  138412032  3498 13703  0:51:47  0:51:30  2:24:55
> m  637534255   0          --rw-r-----   oracle      dba   oracle
> dba     26  310378496  3498 13703  0:51:47  0:51:30  2:24:55
>
> add: 142606336  + 192937984  + 138412032+138412032+310378496 =
> 922746880  (which is = sga_max_size sga_max_size =  880M).
>
> You can test this by extending or shrinking sga_targert and checking
> the size of shared memory segments using ipcs. I believe, it wont
> change.

jg

--
@home.com is bogus.
http://www.darkreading.com/document.asp?doc_id=150292&WT.svl=news1_1
Received on Mon Apr 07 2008 - 12:15:30 CDT

Original text of this message