Venu,

this does help and this is what the guys on metalink said.

What I do not understand - what a waste.

If I have  to grab 100M initially on the OS side I may aswell use it.

In my metalink tar I quoted many references in the documentation:

E.G.
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
 In the Database Administration guide:                                      
 Chapter 2: 'The size of the SGA is dynamic, and can grow or shrink by      
 dynamically altering  these parameters.'                                   
                                                                            
 Now I would say grabing the SGA_MAX_SIZE for the entire uptime of the      
 database is not what I would call dynamic.                                 
                                                                            
 I can't see any growing or shrinking in SGA size.                          
                                                                            
                                                                            




Stephen Hodgkinson
Oracle DBA
TotalFina Elf Gas & Power Ltd


Phone:     01737 27 5564
[EMAIL PROTECTED]


                                                                                       
                                                       
                    "Venu Gopal"                                                       
                                                       
                    <[EMAIL PROTECTED]       To:     Multiple recipients of list 
ORACLE-L <[EMAIL PROTECTED]>                                  
                    pro.com>             cc:                                           
                                                       
                    Sent by:             Subject:     RE: 9i - Dynamic SGA - 
SGA_MAX_SIZE                                                     
                    [EMAIL PROTECTED]                                                  
                                                          
                    ity.com                                                            
                                                       
                                                                                       
                                                       
                                                                                       
                                                       
                    01/08/03 12:14                                                     
                                                       
                    Please respond                                                     
                                                       
                    to ORACLE-L                                                        
                                                       
                                                                                       
                                                       
                                                                                       
                                                       





Stephen,

That's the way it's meant to work.
This is how Oracle guarantees that you can grow upto the value of
SGA_MAX_SIZE. Look at the case below:

DAY 1: you have your sga_max set to 100m but you are currently using
only 50m of it.
DAY 2: you want to use all 100m and you try to increase the sga size,
but some other app has used rest of the physical memory and there is no
sufficient memory available, at this stage oracle has to error out
saying 'insufficient memory', but in reality it does not!!

In reality: On DAY 1, Oracle tries to occupy all 100m in the memory so
that it doesn't have any issues in future... this way you have 100m
reserved for oracle, use it whenever you want to use it.

Hope this helps you...

~Venu


-----Original Message-----
[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 3:24 PM
To: Multiple recipients of list ORACLE-L



Hi,

does anybody have any experience with setting the SGA_MAX_SIZE in 9i.

I assumed the purpose of this parameter was that SGA would grow as
requested to that limit.

Example:
You could configure your SGA to be 80M
Set the SGA_MAX_SIZE to be 250M.

I would have expected oracle to acquire 80M of memory from the UNIX
machine.

In fact using ipcs you can see  that oracle will always acquire the
value
of SGA_MAX_SIZE.

It acquires the extra space in the Variable Size of the SGA










 Sga_max_size=75m.



 Show sga:

 Total System Global Area 77041728 bytes

 Fixed Size 733248 bytes

 Variable Size 41943040 bytes

 Database Buffers 33554432 bytes

 Redo Buffers 811008 bytes





 sga_max_size=110M and keep everything  else the same.



 show sga:

 Total System Global Area 114790680 bytes

 Fixed Size 733464 bytes

 Variable Size 79691776 bytes

 Database Buffers 33554432 bytes

 Redo Buffers 811008 bytes

 Database mounted.

 Database opened.








I have raised a lengthy call on Metalink and the consultants are
convinced
this is normal behaviour and what you would expect.

Do people agree with the metalink consultants?

Maybe my expectations were to high but I thought a dynamic sga would
mean I
could change the amount of memory acquired by the UNIX box.

All opinions welcome. I am on tru64 platform -  9.2.0.3.0

Thanks, Stephen



**********************************************************************
This email contains information which is confidential. It is for the
exclusive use of the addressee. If you are not an addressee please
contact us immediately on 01737 275500. Please note that any
distribution, copying or use of this communication or its contents is
prohibited.

This footnote also confirms that this email message and all associated
attachments have been swept by Network Associates VirusScan for the
presence of computer viruses.
**********************************************************************

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).


**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying

or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.

***************************************************************************
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Venu Gopal
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).


******************************************************
This insert confirms that this email message
and all associated attachments have been
swept by TotalFinaElf using Network Associates
VirusScan for the presence of computer
viruses during the receipt of this message.
******************************************************





-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to