Tunning Sga Oracle 10g

8/14/2019 Tunning Sga Oracle 10g

1/14

Oracle 10g, dynamic SGA and automatic memory management.

http://www.insight-tec.com/en/mailmagazine/vol194.html

This dynamic SGA, as a new feature since Oracle 9i, allows changing the SGA configuration without

stopping the instance.

Expansion and shrinkage

# Default buffer cache, shared pool, large pool and process private memory can be changeddynamically.

Expansion: up to SGA_MAX_SIZE

Shrinkage: down to the minimum size defined by Oracle (the limit suggested according to the O/S)

It can be altered by ALTER SYSTEM SET statement.

# The expansion and the shrinkage ofbuffer pool and SGA pool are executed by Oracle internal

management.

If the component takes memory, the internal automatic tuning will transmit memory from othercomponents.

Note: The buffer pool will be shrinked and the shared pool will be expanded.

Some points that look different in Oracle 10g

# Java pool and streams pool can be changed dynamically.

Note: The SGA component Streams pool is available since Oracle 10g.

# The memory managament method has changed very much.Initial parameters are simplified, SGA_TARGET is added, and we do not have to specify SGA memory

parameters anymore.

SGA configuration can be determined without specifying SHARED_POOL_SIZE,

LARGE_POOL_SIZE,

JAVA_POOL_SIZE,DB_CACHE_SIZE, etc.

They can still be defined seperately, but automatic management will not be executed then.

# Be carefule that STATISTICS_LEVEL parameter must be eitherTYPICAL orALL.

# The SGA configuration memory parameters are organized and can be checked in the newly added V$SGAINFO dynamic view. Granule size and other information are included in this view.

# Changes in SGA size are reflected synchronously in Oracle 9i but with some delay in Oracle 10g.

Therefore, a new flag value is defined in the dynamic view.

Ex jValues added or deleted in V$SGA_RESIZE_OPSOPER_TYPE: Operation typeSTATIC (ADDED)INITIALIZING (ADDED)DISABLED (ADDED)SHRINK_CANCEL (ADDED)

OPER_MODE:Operation modeDISABLED (ADDED)IMMEDIATE (ADDED)AUTO (DELETED)

STATUS:Job-end statusINACTIVE (ADDED)PENDING (ADDED)COMPLETE (ADDED)


2/14

CANCELLED (ADDED)NORMAL (DELETED)CANCEL (DELETED)

Let's expand and shrink the memory dynamically. We will expand the shared pool, and the default buffer

pool will shrink or expand accordingly. In Oracle 10g, SGA_TARGET is also an important value as the

trigger of expansion or shrinkage.

Environment

Linux RAC10g1 2.4.9-e.40smp

Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod

SGA is defined as 176MB.

NAME TYPE VALUE------------------------------------ ----------- -----------sga_max_size big integer 176Msga_target big integer 176M

We can see the size of SGA by referring to the newly added dynamic view. One granule is 4MB in this

environment.

SQL> select * from V$SGAINFO;NAME BYTES RES-------------------------------- ---------- ---Fixed SGA Size 778016 NoRedo Buffers 524288 NoBuffer Cache Size 117440512 YesShared Pool Size 54525952 YesLarge Pool Size 4194304 YesJava Pool Size 4194304 Yes

Streams Pool Size 0 YesGranule Size 4194304 No ->PgranuleMaximum SGA Size 184549376 NoStartup overhead in Shared Pool 33554432 NoFree SGA Memory Available 011 rows are selected.

Expansion of shared pool

We will expand the shared pool from 52MB to 56MB.

NAME TYPE VALUE------------------------------------ ----------- -----------__shared_pool_size big integer 52Mstreams_pool_size big integer 0__db_cache_size big integer 112M

SQL> ALTER SYSTEM SET shared_pool_size ='56M' SCOPE=MEMORY SID='ora101';System is changed.

The time this process takes depends on the specified size. Let's confirm that the size is expanded.


3/14

NAME TYPE VALUE------------------------------------ ----------- -----------__shared_pool_size big integer 56Mshared_pool_size big integer 56M__db_cache_size big integer 108M

The expansion size ofshared pool is equal to the shrinkage size ofdefault buffer cache.

Let's check the dynamic view that is related with SGA.It is shown that

db_cache_size SHRINKS to 113246208 (108MB) and

shared_pool_size GROWS to 58720256 (56MB).

Note: FINAL_SIZE shows the final size.

SQL> select COMPONENT,OPER_TYPE,OPER_MODE,PARAMETER,INITIAL_SIZE,TARGET_SIZE,FINAL_SIZE,STATUS,to_char(START_TIME,'YYYY/MM/DD HH24:MI:SS')as START_TIME,to_char(END_TIME, 'YYYY/MM/DD HH24:MI:SS')as END_TIMEfrom V$SGA_RESIZE_OPS ;

COMPONENT OPER_TYPE OPER_MODE PARAMETER------------------------ ------------- ------------------------DEFAULT buffer cache SHRINK MANUALdb_cache_sizeshared pool GROW MANUALshared_pool_size

INITIAL_SIZE TARGET_SIZE FINAL_SIZE STATUS------------ ----------- ---------- ---------

117440512 113246208 113246208 COMPLETE^^^(108MB)

54525952 58720256 58720256 COMPLETE^^(56MB)

START_TIME END_TIME------------------- -------------------2004/07/11 15:32:13 2004/07/11 15:32:132004/07/11 15:32:13 2004/07/11 15:32:13

Although it seems easy this time, sometimes it takes long forALTERstatement to get response after we

execute the same process several times. Be carefule when you want to apply it to the real system

We examined the expansion of the shared pool last week. Next, let's check how the shrinkage changes the

SGA component.

Environment

Linux RAC10g1 2.4.9-e.40smp


4/14

Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod

Expansion of shared pool

The shared pool is expanded from 52MB to 56MB.

NAME TYPE VALUE------------------------------------ ----------- -----------__shared_pool_size big integer 52Mstreams_pool_size big integer 0__db_cache_size big integer 112M


NAME TYPE VALUE------------------------------------ ----------- -----------__shared_pool_size big integer 56Mshared_pool_size big integer 56M__db_cache_size big integer 108M

shared_pool_size GROWS to 58720256 (56MB).

db_cache_size SHRINKS to 113246208 (108MB) and

In Oracle 9i, when memory size is changed dynamically, the size changes will be reflected synchronously

in MANUAL mode. However, in Oracle 10g, such changes are reflected with some delay in INTERNAL

mode. SGA_TARGET is an important value as the trigger of expansion or shrinkage.

Shrinkgae of the shared pool

The shared pool was once expanded to 56MB, and we now want to shrink it to 52MB.


Even if the shared pool parameter seems to be back, the buffer cache does not change. When will resizing

start?NAME TYPE VALUE------------------------------------ ----------- -----------__shared_pool_size big integer 56Mshared_pool_size big integer 52M

__db_cache_size big integer 108M @db_cache_size big integer 0

In the dynamic view, it is not recognized as SGA blank space.

SQL> select * from V$SGA_DYNAMIC_FREE_MEMORY;

CURRENT_SIZE------------

0

Nothing is different in V$SGA_RESIZE_OPS. We don't really feel like waiting anymore....

Push the button.....


5/14

By changing SGA_TARGET, which is newly added in Orcle 10g, recounting will be executed due to

automatic memory management. Since it is 176MB, as large as SGA_MAX_SIZE, let's change it to

168MB. Be carefule it can not exceed SGA_MAX_SIZE.

NAME TYPE VALUE------------------------------------ ----------- -----------lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 176Msga_target big integer 176M

SQL> ALTER SYSTEM SET sga_target ='168M' SCOPE=MEMORY SID='ora101';System is changed.

NAME TYPE VALUE------------------------------------ ----------- -----------sga_max_size big integer 176Msga_target big integer 168M

176MB-168MB=8MB blank space is recognized.

SQL> select * from V$SGA_DYNAMIC_FREE_MEMORY;

CURRENT_SIZE------------

8388608

The result of resizing is shown in V$SGA_RESIZE_OPS. Default buffer cache is adjusted to 100MB

according to SGA_TARGET. Moreover, DEFERRED mode, which is not available in Oracle 9i, is

displayed now.

COMPONENT OPER_TYPE OPER_MODE PARAMETER------------------------ ------------- ---------------------DEFAULT buffer cache SHRINK DEFERREDdb_cache_size

^^^^^^^^


113246208 104857600 104857600 COMPLETE^^^^^^^^^

START_TIME END_TIME------------------- -------------------2004/07/11 15:35:23 2004/07/11 15:35:23

NAME TYPE VALUE------------------------------------ ----------- -----------


6/14

__db_cache_size big integer 100Mdb_cache_size big integer 0

After a while...

NAME TYPE VALUE

------------------------------------ ----------- -----------__db_cache_size big integer 96Mdb_cache_size big integer 0

The buffer cache is shrinked.

In V$SGA_RESIZE_OPS, IMMEDIATE is shown, Java pool is expanded, and the default buffer pool

is shrinked from 100MB to 96MB.

COMPONENT OPER_TYPE OPER_MODE PARAMETER------------------------ ------------- --------- --------------java pool GROW IMMEDIATE java_pool_sizeDEFAULT buffer cache SHRINK IMMEDIATE db_cache_size

^^^^^^^^^


4194304 8388608 8388608 COMPLETE104857600 100663296 100663296 COMPLETE

^^^^^^^^^

START_TIME END_TIME------------------- -------------------2004/07/11 16:00:17 2004/07/11 16:00:172004/07/11 16:00:17 2004/07/11 16:00:17

As we have shown above, once SGA_TARGET parameter is changed, the optimal size will be determined

to fit the workload according to internal tuning algorithm. SGA component size will be changeddynamically.

Memory expansion and shrinkage of SGA components

In Oracle 10g, it is not required anymore to set up the sizes of all SGA components, which include shared

pool, Java pool, large pool and default buffer cache. By specifying only the total size of SGA with the

initial parametersga_target, the size of each component will be modified automatically. (Even if we do not

set up the initial parameter, the size of each component will still be modified automatically according to the

system load. In fact, the initial parameter assigns the minimum size of each component.

The shared pool, Java pool, large pool and default buffer cache work as source of memory; therefore,

whenever the system detects insufficiency of space after modifying the components automatically, the

expansion of the space will be executed automatically. Furthermore, the memory space will not move

among the components such as shared pool, Java pool and large pool.

Let's start the examination. In order to make the system recognize the insufficiency ofshared pool size is

insufficient, we executed a lot of SQL statements to decrease the library cache hit rate. (After creating atable, we execute a lot of SQL statements in PL/SQL without using any bind variable. This time we execute

3000 rows ofinsert statements.)

BEGININSERT INTO TBL1(t1,t2,t3,t4) VALUES (i,(i*100),(i*100),(i*100));


7/14

INSERT INTO TBL1(t1,t2,t3,t4) VALUES (i,(i*100),(i*100),(i*101));INSERT INTO TBL1(t1,t2,t3,t4) VALUES (i,(i*100),(i*100),(i*102));

@@ idetails unwritten.... jEND;/

Confirm the expansion or shrinkage of the components.

SQL>select to_char(START_TIME,'YYYY/MM/DD HH24:MI:SS') as "ProcessTime",COMPONENT as "Component",OPER_TYPE as "Operation",(FINAL_SIZE-INITIAL_SIZE)/1024/1024 as "Difference(MB)",FINAL_SIZE/1024/1024 as "Size(MB)"from V$SGA_RESIZE_OPS;

ProcessTime Component Operation Difference(MB)Size(MB)------------------- -------------------- ------------ -----------------------

2004/08/10 23:00:04 DEFAULT buffer cache SHRINK -4762004/08/10 23:00:04 shared pool GROW 4402004/08/10 23:23:03 DEFAULT buffer cache SHRINK -4722004/08/10 23:23:03 shared pool GROW 444

It looks like the memory space allocation to the shared pool is reflected and the space is always allocated

from buffer cache. The size increases or decreases by the unit of 4KB (1 granule).

When the space is allocated from the default buffer cache

If the default buffer cache shrinks to its lower limit, what will happen?Confirm the expansion or shrinkage of the components.

SQL>select to_char(START_TIME,'YYYY/MM/DD HH24:MI:SS') as "ProcessTime",COMPONENT as "Component",OPER_TYPE as "Operation",(FINAL_SIZE-INITIAL_SIZE)/1024/1024 as "Difference(MB)",FINAL_SIZE/1024/1024 as "Size(MB)"from V$SGA_RESIZE_OPS;

ProcessTime Component Operation Difference(MB)Size(MB)------------------- -------------------- ------------ -----------------------2004/08/10 23:00:04 DEFAULT buffer cache SHRINK -4762004/08/10 23:00:04 shared pool GROW 4402004/08/10 23:23:03 DEFAULT buffer cache SHRINK -4722004/08/10 23:23:03 shared pool GROW 444


8/14

It looks like the memory space allocation to the shared pool is reflected here and the space is always

allocated from buffer cache. The size increases or decreases by the unit of SKB (1 granule).

When the space is allocated from the default buffer cache

If the default buffer cache shrinks to its lower limit, what will happen?

Current parameters (Specified by the initial parameter)NAME TYPE VALUE------------------------------------ ----------- -------sga_max_size big integer 140Msga_target big integer 128M

db_cache_size big integer 68M The lower limit

Current value of buffer poolSQL> select name,bytes/1024/1024 as "Byte(MB)"from v$SGASTAT where name = 'buffer_cache';NAME Byte(MB)-------------------------- ----------buffer_cache 80

We executed a lot of SQL statements to decrease the library cache hit rate. This is the result of shrinkage.

ProcessTime Component Operation Difference(MB)Size(MB)------------------- -------------------- ---------- ------------------------2004/08/11 16:22:42 DEFAULT buffer cache SHRINK -4 762004/08/11 16:22:42 shared pool GROW 4 402004/08/11 16:22:49 DEFAULT buffer cache SHRINK -4 722004/08/11 16:22:49 shared pool GROW 4 442004/08/11 16:24:14 DEFAULT buffer cache SHRINK -4

68 @*

2004/08/11 16:24:14 shared pool GROW 4 48

RELOADS of the library cache increased 6 times.

NAMESPACE GETS GETHIT PINS PINHIT RELOADS-------------- ------ ------ ------ ------ -------SQL AREA 18471 0.50 74567 0.61 6091

The size ofbuffer cache shrinked to 68MB.

SQL> select name,bytes/1024/1024 as "Byte(MB)"2 from v$SGASTAT where name = 'buffer_cache';

NAME Byte(MB)

-------------------------- ----------buffer_cache 68

Let's alter it dynamically. We will increase the shared pool.

SQL> alter system set shared_pool_size=49M;alter system set shared_pool_size=49M*Errors occurred at row 1.ORA-02097: parameter cannot be modified because specified value is


9/14

invalidORA-04033: Insufficient memory to grow pool

It does not work. It seems like the lower limit is taken as the stopper. The key point is the upper limit of

sga_target.

SQL> select trunc(sum(bytes)/1024/1024) from v$SGASTAT ;TRUNC(SUM(BYTES)/1024/1024)---------------------------

128

Increase sga_target to sga_max_size.

SQL> alter system set sga_target=140M;System changed.

NAME TYPE VALUE------------------------------------ ----------- ----------sga_max_size big integer 140Msga_target big integer 140M

Expand the shared pool again.

SQL> alter system set shared_pool_size=49M;System changed.

It worked well this time. Judging from the result of expansion, the size ofdefault buffer cache has been

expanded. Due to the automatic modification, the lower limit ofdefault buffer cache is always the upper

limit ofsga_target (maximum sga_max_size).

ProcessTime Component Operation Difference(MB)Size(MB)------------------- -------------------- ---------- --------------

----------2004/08/11 16:22:42 DEFAULT buffer cache SHRINK -4 762004/08/11 16:22:42 shared pool GROW 4 402004/08/11 16:22:49 DEFAULT buffer cache SHRINK -4 722004/08/11 16:22:49 shared pool GROW 4 442004/08/11 16:24:14 DEFAULT buffer cache SHRINK -4 682004/08/11 16:24:14 shared pool GROW 4 482004/08/11 16:26:10 DEFAULT buffer cache SHRINK -4 76*2004/08/11 16:26:10 shared pool GROW 4 52

Moreover, even if the size ofdefault buffer cache is insufficient, the system does not shrink the shared

pool or other components to expand the default buffer cache.

We guess that

# when the size ofbuffer cache is insufficient, the status becomes standby and errors do not occur.

# insufficiency ofshared pool or other components is a more serious problem than buffer cache standby.Allocating space from the shared pool or other components might deteriorate the situation.

# when the size ofshared pool, large pool and Java pool is insufficient,

ORA-4031(unable to allocate string bytes of shared memory) and

ORA-29554(Unhanded Java out of memory condition) occur and user processing will fail.

Review

We have confirmed a dynamic SGA action. When the size of shared pool, Java pool orlarge pool is


10/14

insufficient, the default buffer cache will shrink automatically;on the other hand, the shared pool, Java

pool and large pool will expand. Moreover, memory space will not be adjusted among these three

components. (shared pool, large pool, java pool)

After the sizes of components are modified automatically, will the space return back to the default buffercache? (1)shared pool-< default buffer cache (2) Java pool-< default buffer cache (3) large pool- desc v$shared_pool_adviceNAME NULL? PATTERN----------------------------- ----- ------SHARED_POOL_SIZE_FOR_ESTIMATE NUMBERSHARED_POOL_SIZE_FACTOR NUMBERESTD_LC_SIZE NUMBERESTD_LC_MEMORY_OBJECTS NUMBERESTD_LC_TIME_SAVED NUMBERESTD_LC_TIME_SAVED_FACTOR NUMBER

ESTD_LC_LOAD_TIME NUMBER @*Added since Oracle 10gESTD_LC_LOAD_TIME_FACTOR NUMBER @*Added since Oracle 10gESTD_LC_MEMORY_OBJECT_HITS NUMBER

Titles are organized in the order from A to I.

(Initial status: shared pool 36MB)A B C D E F G H I

---- ------- ---- ----- ---- ------ ---- ------- ------32 .8889 4 780 6 1 6 1 1444

* 36 1 4 780 6 1 6 1 144440 1.1111 4 780 6 1 6 1 144444 1.2222 4 780 6 1 6 1 1444

48 1.3333 4 780 6 1 6 1 144452 1.4444 4 780 6 1 6 1 144456 1.5556 4 780 6 1 6 1 144460 1.6667 4 780 6 1 6 1 144464 1.7778 4 780 6 1 6 1 144468 1.8889 4 780 6 1 6 1 144472 2 4 780 6 1 6 1 1444

(First expansion: shared pool 40MB)A B C D E F G H I

---- ------- ---- ----- ---- ------ ---- ------- ------32 .8 4 1067 7 1 8 1 164636 .9 7 1788 7 1 8 1 1658

* 40 1 8 2145 7 1 8 1 165844 1.1 8 2145 7 1 8 1 165848 1.2 8 2145 7 1 8 1 165852 1.3 8 2145 7 1 8 1 165856 1.4 8 2145 7 1 8 1 165860 1.5 8 2145 7 1 8 1 165864 1.6 8 2145 7 1 8 1 165868 1.7 8 2145 7 1 8 1 165872 1.8 8 2145 7 1 8 1 165876 1.9 8 2145 7 1 8 1 1658


14/14

80 2 8 2145 7 1 8 1 1658

(Second expansion: shared pool 44MB)A B C D E F G H I

---- ------- ---- ----- ---- ------ ---- ------- ------36 .8182 8 2544 13 .9286 25 1.0417 30467

* 44 1 15 4693 14 1 24 1 3403252 1.1818 22 6761 14 1 24 1 3415060 1.3636 22 6810 14 1 24 1 3415068 1.5455 22 6810 14 1 24 1 3415076 1.7273 22 6810 14 1 24 1 3415084 1.9091 22 6810 14 1 24 1 3415092 2.0909 22 6810 14 1 24 1 34150

The number and interval of record depend on the size ofshared pool.

(A) is the estimated size of shared pool. For the record whose estimated shared pool size matches the

current size, its size factor.

(B) will become 1. Other distribution records will be created according to that record. These are itemswhich have increased obviously.

(C) is the estimated occupied memory size in library cache;

(D) is the estimated number of library cache memory object;(E) is the estimated required time (in second) for the object deleted from the memory to reload;

(G) is the estimated elapsed time (in second) to execute analysis in shared pool; and

(I) is the estimated number of time that library cache memory object is detected.

The dynamic view is really helpful to have a grasp ofshared pool.

Documents

Tunning Sga Oracle 10g