Re: 9i - Dynamic SGA - SGA_MAX_SIZE

Hi!

I made a simple C program and tested shmget in linux using strace, the test didn't show any malloc() or brk() call, while when using malloc explicitly, brk() was called. This was on linux, I am too lazy to install a compiler on my test solaris machine, if anyone is interested, just run this with truss and check output.

#include <sys/ipc.h>
#include <sys/shm.h>
int i;
char c;
main() {
//c = malloc(555);
i = shmget(0, 1000, 511+IPC_CREAT+IPC_EXCL); }

Tanel.

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, August 08, 2003 11:39 PM

> Mladen,
> But then again, shmget and shmat use malloc/calloc internally, it just
> differs in that shmget/shmat create the memory space and then make a
"public
> handle" so that multiple processes can access the memory allocated. (Very
> simplisticly put)
> So in a certain sense it is more than just a similar mechanism.
>
> What was this discussion about anyway ;)
>
>
> -----Mensaje original-----
> De: Mladen Gogala [mailto:mladen_at_wangtrading.com]
> Enviado el: viernes, 08 de agosto de 2003 16:09
> Para: Multiple recipients of list ORACLE-L
> Asunto: RE: 9i - Dynamic SGA - SGA_MAX_SIZE
>
> BTW, my debate of this issue was completely incorrect. As a colleague from
> This list has noted, SGA is created using shmget and shmat, not malloc and
> calloc.
> The only explanation might be that the mechanism is similar to the one of
> malloc.
>
> --
> Mladen Gogala
> Oracle DBA
>
>
>
> -----Original Message-----
> Jessica Mao
> Sent: Tuesday, August 05, 2003 6:34 PM
> To: Multiple recipients of list ORACLE-L
>
>
> don't know if it's still true, i played with sga_max_size and
db_cache_size
> a year ago on 9.0 & Solaris8 & F15k w/o much luck.
>
> when sga_max_size = 64G and db_cache_size = 32G, db started impressingly
> fast. but db server cpu sys% jumped up to 90+ during warming-up tests,
> leaving usr% close to 0. tests never finished. reduced sga_max_size = 40G
> and db_cache_size = 32G, db cpu still around 50% sys. sga_max_size = 18G
and
> db_cache_size = 16G, db performing ok.
> after that gave up sga_max_size, increased db_cache_size to 24G
> (sga_max_size was then auto set to 24G). db performing ok. db_cache_size =
> 32G (= sga_max_size). took 32 min to start db. db performing ok.
> db_cache_size = 40G (just curious), took 40min to start db. db performing
> ok.
>
> -Jessica
>
> --- Mohammed Shakir <mshakir08816_at_yahoo.com> wrote:
> > Kirti
> >
> > Thanks for the info.
> >
> > I could not raise dynamically the size of db_cache_size and did not
> > know why, until I noticed the new parameter sga_max_size. Anyway, I
> > tried to lower the size of db_cache_size dynamically and I did not
> > have a problem. So sgma_max_size does play its role in
> > db_cache_sizing.
> >
> > I have not tested where I increase the size of sga_max_size using
> > init.ora and then try to increase the size of db_cache_size
> > dynamically by the same size as the increase in sga_max_size. That is
> > the test for coming weekend.
> >
> >
> > --- Kirtikumar Deshpande <kirtikumar_deshpande_at_yahoo.com> wrote:
> > > SGA_MAX_SIZE was introduced in 9i to allow dynamic sizing of SGA
> > > (Dynamic Sizing feature) components such as, shared pool, large
> > > pool, buffer cache etc. In versions up to 8i, such changes
> > > required bouncing the instance.
> > > This parameter assumes the value of the SGA at instance startup.
> > > Various components of the SGA can
> > > then be increased/reduced as and when needed. The total SGA, thus,
> > > can reach a maximum value set
> > > by SGA_MAX_SIZE (if set in the init.ora file). That's the idea.
> > > However, the implementation is
> > > different on various platforms. With ISM, and DISM, on Solaris, there
> > > are other issues when it
> > > comes to using Dynamic SGA. You may want to search Metalink for
> > > specific notes/articles for
> > > Solaris.
> > > On AIX 5L as I found out, Oracle uses SGA_MAX_SIZE, if set in
> > > init.ora, at the instanace startup,
> > > and allocates the excess (difference in computed SGA value and set
> > > SGA_MAX_SIZE) to 'variable
> > > size'. Hence there is no room for any dynamic sizing (upward) of any
> > > SGA component. I did not try
> > > to downsize shared pool first, and 'upsize' buffer cache later. May
> > > be that would work, but that
> > > is not the intention of using this parameter.
> > >
> > > PGA_AGRREGATE_TARGET is completely different from this parameter. It
> > > sets an instance-wide upper limit for the memory used by sorting,
> > > hashing processes.
> > >
> > > Hope this helps..
> > >
> > > - Kirti
> > >
> > >
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Kirtikumar Deshpande
> INET: kirtikumar_deshpande_at_yahoo.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).
>
>
> --------------------------------------------------------
> Note:
> This message is for the named person's use only. It may
> contain confidential, proprietary or legally privileged
> information. No confidentiality or privilege is waived
> or lost by any mistransmission. If you receive this
> message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies
> of it and notify the sender. You must not, directly or
> indirectly, use, disclose, distribute, print, or copy
> any part of this message if you are not the intended
> recipient. Wang Trading LLC and any of its subsidiaries
> each reserve the right to monitor all e-mail
> communications through its networks.
>
> Any views expressed in this message are those of the
> individual sender, except where the message states
> otherwise and the sender is authorized to state them
> to be the views of any such entity.
> ---------------------------------------------------------
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mladen Gogala
> INET: mladen_at_wangtrading.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: Jessica Mao
> INET: jmao_at_portal.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).
>
> --------------------------------------------------------
> Note:
> This message is for the named person's use only. It may
> contain confidential, proprietary or legally privileged
> information. No confidentiality or privilege is waived
> or lost by any mistransmission. If you receive this
> message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies
> of it and notify the sender. You must not, directly or
> indirectly, use, disclose, distribute, print, or copy
> any part of this message if you are not the intended
> recipient. Wang Trading LLC and any of its subsidiaries
> each reserve the right to monitor all e-mail
> communications through its networks.
>
> Any views expressed in this message are those of the
> individual sender, except where the message states
> otherwise and the sender is authorized to state them
> to be the views of any such entity.
> ---------------------------------------------------------
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mladen Gogala
> INET: mladen_at_wangtrading.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: Nelson Flores
> INET: nflores_at_intec.cl
>
> 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: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

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).