Sga_max_size dynamic?

Hi
we are using oracle std edition
how can we enable sga_max_size to be dynamic
thanx
kedar

Hi,
sga_max_size is a static parameter.You can increase the shared pool and buffer cache dynamic until sga_max_size.

Similar Messages

(9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE

제품 : ORACLE SERVER
작성날짜 : 2005-01-05
(9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE
==================================================================
PURPOSE
Oracle 9i의 새 기능인 동적으로 SGA 파라미터들을 변경하는 방법에
대하여 알아보기로 한다.
Explanation
Oracle 8i까지는 Buffer Cache, Shared Pool, Large Pool 등과 같은 SGA
파라미터들에 대해 그 크기를 동적으로, db가 운영 중인 상태에서는 변경할
수가 없었다.
즉, 이러한 파라미터들을 변경하려면 db를 shutdown하고 initSID.ora 화일에
서 그 크기를 다시 설정하고, 이 파라미터를 이용해서 db 인스턴스를 restart
해야만 했었다.
Oracle 9i에서는 DBA가 ALTER SYSTEM 명령을 이용해서 SGA 파라미터의 크기
를 동적으로 변경할 수 있게 되었다. 이 특정을 'Dynamic SGA'라고 부른다.
SGA 전체의 최대 크기(SGA_MAX_SIZE)를 정의하고 그 한도 내에서 파라미터의
크기를 변경할 수 있는 것이다. 데이타베이스를 shutdown/startup 없이 작업
이 가능하기 때문에 'Planned Downtime'을 줄이는 한 방법으로도 이해할 수
있다.
이 글에서는 SGA에 할당할 수 있는 최소 단위인 'Granule'의 개념을 살펴보
고, 이 granule이 어떠한 방법에 의해 동적으로 할당되는지에 대해 알아보고
자 한다.
또한 Buffer Cache 파라미터 중 새로운 것과 이전 버전에 비해 달라진 내용
을 소개하기로 한다.
1. Granule
Granule은 가상 메모리 상의 연속된 공간으로, dynamic SGA 모델에서 할당할
수 있는 최소 단위이다. 이 granule의 크기는 SGA 전체의 추정값
(SGA_MAX_SIZE)에 따라 다음과 같이 구분된다.
4MB if estimated SGA size is < 128M
16MB otherwise
SGA의 Buffer Cache, Shared Pool, Large Pool 등의 파라미터는 이 granule
단위로 늘어나거나 줄어들 수 있다. (현재 dynamic SGA를 사용할 수 있는
SGA 관련 파라미터는 Buffer Cache, Shared Pool, Large Pool 세 가지이다.)
2. Dynamic SGA(DB_CACHE_SIZE, SHARED_POOL_SIZE)
DBA는 ALTER SYSTEM 명령을 통해 initSID.ora 화일에 정의된 SGA 관련 파라미
터 값을 동적으로 변경할 수 있다. SGA 파라미터의 크기를 늘려주기 위해서
는 필요한 만큼의 free granule이 존재해야만 하며, 현재 사용하고 있는 SGA
의 크기가 SGA_MAX_SIZE보다 작아야 한다. Free granule이 없다고 해서 다른
파라미터로부터 granule을 free시켜서 그 granule을 이용할 수 있는 것은 아
니다.
반드시 DBA가 명시적으로 free/allocate해야 한다.
다음의 예를 살펴보자. 설명을 단순화하기 위해 이 경우는 SGA가 Buffer
Cache와 Shared Pool로만 구성되었다고만 하자.
예) initSID.ora
SGA_MAX_SIZE = 128M
DB_CACHE_SIZE = 96M
SHARED_POOL_SIZE = 32M
Note : DB_CACHE_SIZE는 Oracle 9i에 새롭게 도입된 파라미터이다.
위와 같은 상태일 때 동적으로 SHARED_POOL_SIZE를 64M로 늘리면 에러가 발생
한다.
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
(insufficient memory error message)
이 에러는 SHARED_POOL_SIZE를 늘림으로써 전체 SGA의 크기가 SGA_MAX_SIZE
보다 커지기 때문에 발생한다. (96M + 64M > 128M)
이를 해결하기 위해서는 DB_CACHE_SIZE를 줄인 후, SHARED_POOL_SIZE를 늘린다.
SQL> ALTER SYSTEM SET DB_CACHE_SIZE=64M;
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
Note : DB_CACHE_SIZE가 shrink되는 동안에
ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
를 하면 insufficient error가 발생할 수도 있다.
이 경우는 DB_CACHE_SIZE가 shrink된 후 다시 수행하면 정상적으로
수행이 된다.
Note : 위 예제의 경우 estimated SGA 크기가 128M 이상이므로, granule의
단위는 16M이다. 따라서 SGA 파라미터의 크기를 16M의 정수배로 했다.
16M의 정수배가 아닌 경우는 지정한 값보다 큰 값에 대해 16M의
정수배 중 가장 가까운 값을 택하게 된다.
즉, 아래 두 문장의 결과는 똑같다.
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=49M;
Note : LARGE_POOL_SIZE 와 JAVA_POOL_SIZE 파라미터는 동적으로 변경하는
것이 불가능하다.
1) Dynamic Shared Pool
인스턴스 start 후, Shared Pool의 크기는 다음과 같은 명령에 의해 동적으
로 변경(grow or shrink)될 수 있다.
ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
다음과 같은 제약 사항이 있다.
- 실제 할당되는 크기는 16M의 정수배가 된다.
- 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
2) Dynamic Buffer Cache
인스턴스 start 후, Buffer Cache의 크기는 다음과 같은 명령에 의해 동적으
로 변경(grow or shrink)될 수 있다.
ALTER SYSTEM SET DB_CACHE_SIZE=96M;
다음과 같은 제약 사항이 있다.
- 실제 할당되는 크기는 16M의 정수배가 된다.
- 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
- DB_CACHE_SIZE는 0이 될 수 없다.
3. Buffer Cache 파라미터의 변경된 내용
여기서는 Buffer Cache 파라미터와 관련하여 Oracle 9i에 의미가 없어진 파라
미터와 새롭게 추가된 파라미터, 그리고 dynamic SGA 중 Buffer Cache와 관련
이 있는 부분에 대해 기술하고자 한다.
1) Deprecated Buffer Cache Parameters
다음의 세 가지 파라미터는 backward compatibility를 위해 존재하는 것으
로, 차후 의미가 없어진다.
- DB_BLOCK_BUFFERS
- BUFFER_POOL_KEEP
- BUFFER_POOL_RECYCLE
위의 파라미터들이 정의되어 있으면 이 값들을 사용하게 될 것이다. 하지만,
다음에 나올 새로운 파라미터들을 사용하는 것이 좋으며, 만일 위 파라미터
(DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE) 값들을 사용
한다면 이 글에서 설명한 dynamic SGA 특징을 사용할 수는 없다. 또한
initSID.ora 화일에 위 파라미터들과 새로운 파라미터를 동시에 기술한다면
에러가 발생한다.
2) New Buffer Cache Sizing Parameters
다음의 세 파라미터가 추가되었다. 이 파라미터들은 primary block size에
대한 buffer cache 정보를 다루고 있다.
- DB_CACHE_SIZE
- DB_KEEP_CACHE_SIZE
- DB_RECYCLE_CACHE_SIZE
DB_CACHE_SIZE 파라미터에 지정된 값은 primary block size에 대한 default
Buffer Pool의 크기를 의미한다. 또한 이전 버전과 마찬가지로 KEEP과
RECYCLE buffer pool을 둘 수 있는데, 이는 DB_KEEP_CACHE_SIZE,
DB_RECYCLE_CACHE_SIZE 라는 파라미터를 이용한다.
이전 버전과 다른 점은 이전 버전의 경우 각각의 파라미터
(DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP,BUFFER_POOL_RECYCLE)에 정의된 값들
이 buffer 갯수(즉, 실제 메모리 크기를 구하려면 db_block_size를 곱했어야
했다. )였는데 반해 이제는 구체적인 메모리 크기이다.
또한 이전에는 DB_BLOCK_BUFFERS가 BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE
의 값을 포함하고 있었지만, 이제는 DB_CACHE_SIZE가 DB_KEEP_CACHE_SIZE,
DB_RECYCLE_CACHE_SIZE를 포함하고 있지 않다.
즉, 각각의 파라미터들은 독립적이다.
Note : Oracle 9i부터는 multiple block size(2K, 4K, 8K, 16K, 32K)를 지원한다.
위에서 언급한 primary block size는 DB_BLOCK_SIZE에 의해 정해진 block
size를 의미한다. (SYSTEM tablespace는 이 block size를 이용한다.)
3) Dynamic Buffer Cache Size Parameters
바로 위에서 언급한 세 파라미터는 아래와 같이 ALTER SYSTEM 명령에 의해
동적으로 변경 가능하다.
SQL> ALTER SYSTEM SET DB_CACHE_SIZE=96M;
SQL> ALTER SYSTEM SET DB_KEEP_CACHE_SIZE=16M;
SQL> ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE=16M;
Example
none
Reference Documents
<Note:148495.1>

Hello Martin,
Can I execute by ORA-27102 the following commandos in order to set and use the values of sga_max_size immediately?
Variant 1)
>sqlplus /nolog
>connect / as sysdba
> startup nomout
> ALTER SYSTEM SET SGA_MAX_SIZE= value SCOPE=pfile;
> shutdown immediate
> startup
Variant 2)
Changing the values of sga_max_size, etc. in init<DBSID>.ora
>sqlplus /nolog
>connect / as sysdba
> startup from pfile = /oracle/<SID>/dbs/ init<DBSID>.ora;
Thank you very much!
regards
Thom

Sga_max_size

Hi,
I have a question about the parameter sga-max-size.
When starting the instance, oracle9i r2 on linux redhat, it seems that the total sga comes near to that sga-max-size parameter. As far as I understand is this used for dynamic sga, so you can increase db_cache_size etc on the fly. But does it also mean that the size of the SGA is already completely in the memory of the system? How can you see on Linux Redhat 9 how much memory Oracle is using, if it is really using the completely SGA (for example 1GB)?
thanks
greets

it seems that the total sga comes near to that sga-max-size parameter
r.- Explanation about this point: if the SGA components exceed the SGA_MAX_SIZE value the instance is not going to start.
As far as I understand is this used for dynamic sga, so you can increase db_cache_size etc on the fly
r.- It is true
But does it also mean that the size of the SGA is already completely in the memory of the system?
r.- Part of them. While the SGA is higher the memory in your machine is more used. But it does not mean that if you have 1GB in SGA it means that 1GB it is need of RAM. Really as far as I know Oracle software does not inform us in what proportion it uses the memory and so on. Oracle software and documentation learn us how the SGA must be handle.
How can you see on Linux Redhat 9 how much memory Oracle is using
r.- You have several ways to find out those values.
1.- command : "top"
2.- Create a script using "ps" command
Joel Pérez
http://otn.oracle.com/experts

Sga_max_size vs sga_target

Whats the difference between SGA_MAX_SIZE and SGA_TARGET? I am bit confused.
As per Oracle® Database Reference 10g Release 1 (10.1)
SGA_MAX_SIZE specifies the maximum size of the SGA for the lifetime of the instance
Then why SGA_TARGET is used.
I am missing something here. Kindly clarify.
Thanks in Advance
SID.

Max_size is what the SGA can grow to if it has to.
SGA_Target is what you'd like the SGA to be.
Then why SGA_TARGET is used.
Because you might want to dynamically grow your SGA, above the target. Suppose someone gives you a transportable tablespace and it comes from a 4K-blocksize database, and you're using 8K blocks. You have to 'alter system set db_4k_cache_size=something', but if you try that when your TARGET already equals your MAX_SIZE, you'll be told there's no room to grow the SGA, so the only way to achieve what you want is to shrink some other part of the SGA or to set the parameter in your init.ora and bounce. Either could be problematic on a production box. That's just one example: remember that 'SGA_TARGET' is indeed only a target: Oracle is allowed to exceed the target if thinks the workload makes it necessary to do so.
So the difference between MAX_SIZE and TARGET is 'slack space': memory that's not in use, but could be if you (or Oracle) determined a need for it.
On a lot of operating systems, this difference is paged out and thus doesn't mean you're wasting real, physical memory.
But on others (and I think this is true of Windows and Linux), you would indeed be 'consuming' that memory difference -which would thus amount to wasted physical memory.

SGA_MAX_SIZE & SGA_TARGET

If anyone can explain to me the relationship of these 2 parameters? Chapter 8 Database Concepts doesn't clearly define how and if they are used in tandem.
Matt

Let me simplify it a bit ...
From the links I provided:
SGA_MAX_SIZE has a default. Therefore it does not need to be set.
SGA_TARGET has a default. it does not need to be set. The default is 0, meaning NOTHING is automatically handled.
In the Reference manual description for SGA_TARGET, it provides a link to the Concepts manual. That link is there to provide more detailed information, so we follow it ...
The SGA_MAX_SIZE and SGA_TARGET are in the table of contents of the Concepts manual. Following that, we find
It is significant that SGA_TARGET includes the entire memory for the SGA, in contrast to earlier releases in which memory for the internal and fixed SGA was added to the sum of the configured SGA memory parameters. Thus, SGA_TARGET gives you precise control over the size of the shared memory region allocated by the database. If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup, then the latter is bumped up to accommodate SGA_TARGET.
Note:
Do not dynamically set or unset the SGA_TARGET parameter. This should be set only at startup.
There is a lot of additional supporting information in the Concepts manual as well.
Message was edited by: Hans Forbrich
Corrected the interpretation of SGA_TARGET default.

SGA_MAX_SIZE != SGA_TARGET when?

Just curious... under what circumstances, when using ASMM, would I not want SGA_TARGET to equal SGA_MAX_TARGET?
Bob

Just to clarify things up,
Oracle will allocate SGA size equal to SGA_MAX_SIZE from system initially.
SGA_TARGE can be smaller than SGA_MAX_SIZE because they are buffer caches, such as KEEP, RECYCLE, and other block sizes, not affected by SGA_TARGET.
See the result below,
SYS@etest> show sga
Total System Global Area 264241152 bytes
Fixed Size                  1301408 bytes
Variable Size             216540256 bytes
Database Buffers           46137344 bytes
Redo Buffers                 262144 bytes
SYS@etest> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     TRUE
sga_max_size                         big integer 252M
sga_target                           big integer 200MOracle SGA size is 264241152/1024/1024=252M equal to SGA_MAX_SIZE while SGA_TARGET is 200M
Since I don't have other buffers set, Where the 50M goes ?
SYS@etest> select * from v$sgainfo
2 /
NAME                                  BYTES RES
Fixed SGA Size                      1301408 No
Redo Buffers                         262144 No
Buffer Cache Size                  46137344 Yes
Shared Pool Size                  150994944 Yes
Large Pool Size                     4194304 Yes
Java Pool Size                      4194304 Yes
Streams Pool Size                         0 Yes
Granule Size                        4194304 No
Maximum SGA Size                  264241152 No
Startup overhead in Shared Pool    37748736 No
Free SGA Memory Available 54525952
11 rows selected.It went to Free SGA Memory Available. Hence you can dynamically increase SGA_TARGET without reboot instance.

Sga_max_size in 9i

Hi
Sorry about this simple question but little bit confused.
If I set "sga_max_size" parameter in 9i, Does the sga compenents change (increase/decrease) dynamically while the database is up?
or
This is parameter only necessary if I want to increase the sga components manuelly while the database is up?

so, option2.
Is that right?
In oracle 9i,
this parameter is only necessary if I want to increase the sga components manuelly while the database is up.
The sga compenents doesnt increase automatically while the db is up.

Oracle Parameter (SGA_MAX_SIZE / SGA_TARGET)

Hello together,
since yesterday we have a new oracle database on X64 (64BIT on Windows) with SAP R/3 4.7.
The server have 24GB ram and 2x quad Core CPU.
How can give me a good value for this parameters (for oracle)
SGA_MAX_SIZE
SGA_TARGET
I don't know what is a good size for such a hugh physikal memory!
Thank you
Christian

Hello Christian,
the parameter SGA_TARGET is "not longer" supported by SAP.
Take a look at sapnote #828268
At the beginning of oracle 10g we have activated the ASMM ... but there is still a bug with oracle 10g which results in a hang situation (solved in 11g ... no backport planned)
For more information regarding to the bug... take a look at bugnotes on metalink 4466399/4472338
SGA_MAX_SIZE should be a little bit higher than the sum of all your memory pools (SGA), because of you can extend some areas dynamically on the fly (if you are using a spfile).
Regards
Stefan

Increase SGA_MAX_SIZE and SGA_TARGET

Hi all,
I want to increase SGA_MAX_SIZE and SGA_TARGET in 10g. Currently we have
SQL> sho parameter sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2384M
sga_target big integer 2384M
And we have 16GB RAM in redhat linux 4(32 bit).Oracle 10.2.0.3 DB.
Because of 32 bit OS, I was not able to increase shmmax more than 4GB.
In this situation how and how much SGA_MAX_SIZE and SGA_TARGET I can increase?
Thanks in Advance,
Sunil

Hi sunilgln,
Given the present state of things, you have to take a meassure of how many RAM is used with nothing running but the OS, that will give you the Linux footprint.
Take note of the amount of physical free memory (using top command)
Later you have to estimate how much swapping are you willing to accept, the SGA you define may be within the ranges of
FREE MEM*90% and FREE MEM*90+(OS FOOTPRINT*%SWAP MEMORY WILLING TO USE)
This is a proposal for setting this up, you need to tune and balance load depending on usage.
Another recommendation, SGA_TARGET is dynamic, SGA_MAX_SIZE is not...but you may set SGA_MAX_SIZE to a full allocation and set SGA_TARGET to a percentage that allocation and gradually use it.
What happens is: the OS will "allocate" a chunk(or chunks) the size given by SGA_MAX_SIZE, but the real usage by the database will be determined by SGA_TARGET.
Hope this helps you
Ignacio
Regards
http://oracledisect.blogspot.com

Sga_max_size and sga_target values

I have an 11g database on windows with 4GB RAM, I have set the MEMORY_MAX_TARGET and MEMORY_TARGET, what should I do with the pre-existing sga_max_size and sga_target values

memory_target = sga_target + max(pga_aggregate_target, maximum PGA allocated)
MEMORY_MAX_TARGET = sum of the SGA and instance PGA sizes.
For Automatic memory management
set
ALTER SYSTEM SET SGA_TARGET = 0;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 0;
Note:
In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a nonzero value, provided that it does not exceed the value of MEMORY_MAX_TARGET.
Note:
The preceding steps instruct you to set SGA_TARGET and PGA_AGGREGATE_TARGET to zero so that the sizes of the SGA and instance PGA are tuned up and down as required, without restrictions. You can omit the statements that set these parameter values to zero and leave either or both of the values as positive numbers. In this case, the values act as minimum values for the sizes of the SGA or instance PGA.
Reference

[SOLVED] SGA_MAX_SIZE pre-allocated with Solaris 10?

Hi all,
I'm about to build a new production database to migrate an existing 8.1.7 database to 10.2.0.3. I'm in the enviable position of having a good chunk of memory to play with on the new system (compared with the existing one) so was looking at a suitable size for the SGA... when something pinged in my memory about SGA_MAX_SIZE and memory allocation in the OS where some platforms will allocate the entire amount of SGA_MAX_SIZE rather than just SGA_TARGET.
So I did a little test. Using Solaris 10 and Oracle 10.2.0.3 I've created a basic database with SGA_MAX_SIZE set to 400MB and SGA_TARGET 280MB
$ sqlplus
SQL*Plus: Release 10.2.0.3.0 - Production on Wed Jan 30 18:31:21 2008
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Enter user-name: / as sysdba
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> show parameter sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 400M
sga_target big integer 280MSo I was expecting to see the OS pre-allocate 280MB of memory but when I checked the segment is actually the 400MB (i.e. SGA_MAX_SIZE) (my database owner is 'ora10g'):
$ ipcs -a
IPC status from <running system> as of Wed Jan 30 18:31:36 GMT 2008
T ID KEY MODE OWNER GROUP CREATOR
CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME
Message Queues:
T ID KEY MODE OWNER GROUP CREATOR
CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 22 0x2394e4 rw-r--- ora10g 10gdba ora10g
10gdba 20 419438592 2386 2542 18:31:22 18:31:28 18:28:18
T ID KEY MODE OWNER GROUP CREATOR
CGROUP NSEMS OTIME CTIME
Semaphores:
s 23 0x89a070e8 ra-r--- ora10g 10gdba ora10g
10gdba 154 18:31:31 18:28:18
$ I wasn't sure whether Solaris 10 was one of the OSs with truly dynamic memory for the SGA but had hoped it was... this seems to say different. Really I'm just after some confirmation that I'm reading this correctly.
Thanks.
Joseph
Message was edited by:
Joseph Crofts
Edited for clarity

I don't want to get bogged down in too many details, as the links provided in previous posts have many details of SGA tests and the results of what happened. I just want to add a bit of explanation about the Oracle SGA and shared memory on UNIX and Solaris in particular.
As you know Oracle's SGA is generally a single segment of shared memory. Historically this was 'normal' memory and could be paged out to the swap device. So a 500 MB SGA on a 1 GB physical memory system, would allocate 500 MB from the swap device for paging purposes, but might not use 500 MB of physical memory i.e. free memory might not decrease by 500 MB. How much physical memory depended on what pages in the SGA were accessed, and how frequently.
At some point some people realised that this paging of the SGA was actually slowing performance of Oracle, as now some 'memory' accesses by Oracle could actually cause 'disk' accesses by paging in saved pages from the swap device. So some operating systems introduced a 'lock' option when creating a shared memory segment (shmat system call if memory serves me). And this was often enabled by a corresponding Oracle initialisation parameter, such as lock_sga.
Now a 'locked' SGA did use up the full physical memory, and was guaranteed not to be paged out to disk. So Oracle SGA access was now always at memory speed, and consistent.
Some operating systems took advantage of this 'lock' flag to shared memory segment creation to implement some other performance optimisations. One is not to allocate paging storage from swap space anyway, as it cannot be used by this shared memory segment. Another is to share the secondary page tables within the virtual memory sub-system for this segment over all processes attached to it i.e. one shared page table for the segment, not one page table per process. This can lead to massive memory savings on large SGAs with many attached shadow server processes. Another optimisation on this non-paged, contiguous memory segment is to use large memory pages instead of standard small ones. On Solaris instead of one page entry covering 8 KB of physical memory, it covers 8 MB of physical memory. This reduces the size of the virtual memory page table by a factor of 1,000 - another major memory saving.
These were some of the optimisations that the original Red Hat Enterprise Linux had to introduce, to play catch up with Solaris, and to not waste memory on large page tables.
Due to these extra optimisations, Solaris chose to call this 'locking' of shared memory segments 'initimate shared memory' or ISM for short. And I think there was a corresponding Oracle parameter 'use_ism'. This is now the default setting in Oracle ports to Solaris.
As a result, this is why when Oracle grabs its shared memory segment up front (SGA_MAX_SIZE), it results in that amount of real physical memory being allocated and used.
With Oracle 9i and 10g when Oracle introduced the SGA_TARGET and other settings and could dynamically resize the SGA, this messed things up for Solaris. Because the shared memory segment was 'Intimate' by default, and was not backed up by paging space on the swap device, it could never shrink in size, or release memory as it could not be paged out.
Eventually Sun wrote a work around for this problem, and called it Dynamic Intimate Shared Memory (DISM). This is not on by default in Oracle, hence you are seeing all your shared memory segments using the same amount of physical memory. DISM allows the 'lock' flag to be turned on and off on a shared memory segment, and to be done over various memory sizes.
I am not sure of the details, and so am beginning to get vague here. But I remember that this was a workaround on Sun's part to still get the benefits of ISM and the memory savings from large virtual memory pages and shared secondary page tables, while allowing Oracle to manage the SGA size dynamically and be able to release memory back for use by other things. I'm not sure if DISM allows Oracle to mark memory areas as pageable or locked, or whether it allows Oracle to really grow and shrink the size of a single shared memory segment. I presumed it added yet more flags to the various shared memory system calls.
Although DISM should work on normal, single Solaris systems, as you know it is not enabled by default, and requires a special initialisation parameter. Also be aware that there are issues with DISM on high end Solaris systems that support Domains (F15K, F25K, etc.) and in Solaris Zones or Containers. Domains have problems when you want to dynamically remove a CPU/Memory board from the system, and the allocations of memory on that board must be reallocated to other memory boards. This can break the rule that a locked shared memory segment must occupy contiguous physical memory. It took Sun another couple of releases of Solaris (or patches or quarterly releases) before they got DISM to work properly in a system with domains.
I hope I am not trying to teach my granny to suck eggs, if you know what I mean. I just thought I'd provide a bit more background details.
John

Dynamic SGA_TARGET

Hello, all.
I reduced the dynamic parameter SGA_TARGET in Oracle 10.2.0.4 with the 2500M to 500M.
The operation completed successfully.
At the same time consumption of physical memory in the system has not decreased.
Operating system AIX 5.3.
Utility svmon:
sga_target = 2500MB, svmon.inuse = 3161MB
reduced sga_target to 500MB, svmon.inuse = 5094, memory usage has grown!
Why dynamic reduction of memory in Oracle does not dynamically reduces the use of physical memory in the system?
Because of this I cannot dynamically reallocate memory on another lpar.
And is contrary to article [Using the IBM AIX 5L dynamic LPAR feature with Oracle Database|http://www-03.ibm.com/servers/enable/site/peducation/wp/a696/page_2.html]
Best ragards,
Sudarev Gleb

What is the value of SGA_MAX_SIZE ? Did you also change its value ?
In general, SGA is allocated under Unix using shared memory segments. What happens where SGA parameters are changed depends on the way Unix is dynamically able to change or not shared memory segments.
From http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/create.htm#sthref390
>
The change in the amount of physical memory consumed when SGA_TARGET is modified depends on the operating system. On some UNIX platforms that do not support dynamic shared memory, the physical memory in use by the SGA is equal to the value of the SGA_MAX_SIZE parameter. On such platforms, there is no real benefit in setting SGA_TARGET to a value smaller than SGA_MAX_SIZE. Therefore, setting SGA_MAX_SIZE on those platforms is not recommended.

Dynamic sga

Hi All,
I enabled 10g dynamic SGA by just keeping sga_target and sga_max_size...
now when i see the dbcache_size...it doesn't show any value ..
How do i know the amount of db_cache_cache, shared_pool size which is being used...
Thanks in advance ...

when u set sga_target its automatically sizes
dbbc,shared_pool and other memory areas, this all areJust a gentle clarification - ASMM sizes SOME memory areas in the SGA.
1) Only sizes the basic 5 (shared pool, Java pool, large pool, buffer cache, Streams pool)
2) Of those, it only sizes those the DBA has set to 0
There are a bunch that still need the DBA's watchful eye. http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/memory.htm#sthref1258

Altering SGA_MAX_SIZE

i have a Oracle 10g in a server XEON with two processores and 4 Gb RAM. My SGA_MAX_SIZE have 900 Mg, but i think that this is very little. How can i do for resize mi SGA_MAX_SIZE?

If you use spfile
SQL> show parameter spfile
SQL> alter system set SGA_MAX_SIZE=xxx scope=spfile;If not use spfile, you must modify pfile ... init<SID>.ora
and then
SQL> shutdown immediate;
SQL> startup;Anyway you should increase SGA_TARGET initialization parameter as well...
If you use spfile , SGA_TARGET(dynamic) ... can change.. (not more SGA_MAX_SIZE) no shutdown database
SQL> alter system set sga_target=xxx;So, your Step ... if you use spfile
SQL> show parameter sga
SQL> alter system set SGA_MAX_SIZE=xxxx scope=spfile;
SQL> alter system set SGA_TARGET=xxxx scope=spfile;
SQL> shutdown immediate;
SQL> startup;good Luck

Delete sga_max_size parameter.

Hi,
How do I delete the sga_max_size parameter, currently I have
SQL> show parameter sga_max_size
NAME TYPE VALUE
sga_max_size big integer 260641504
I want to delete this entry from the init.ora parameter and create a new spfile, but I don't see this entry in the init.ora file. Any help is appreciated.
Thanks.

Why do you want to 'get rid' of this parameter? Any particular problem with this?
Well, bad news, you cannot get rid of this parameter, even if you are able to 'delete' this parameter its value is dynamically computed at instance startup time. Now let's assume, since you haven't specified so, that you have manually set this value. Assuming that you have started your instance with spfile (not specified either) you need to issue the ALTER SYSTEM comand.
Check which initialization parameter file you are using, most probably, (if configured by default) you are using spfile, so from a command prompt issue the command:
show parameter spfile
This will let you know the path to this file.
Once you have found the file, just issue a CREATE PFILE FROM SPFILE; command, this will create a text parameter file you can modify, if you don't feel comfortable with the ALTER SYSTEM command. You can take it back to spfile by issuing CREATE SPFILE FROM PFILE;
~ Madrid
http://hrivera99.blogspot.com/

Sga_max_size dynamic?

Similar Messages

Maybe you are looking for