Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Bolat.

Asked: March 03, 2017 - 12:30 pm UTC

Last updated: March 07, 2017 - 2:07 am UTC

Version: 11.2.0.4

Viewed 10K+ times! This question is

You Asked

hi Tom,
there is a question

We have DB with following SGA info:
SQL> select * from v$sgainfo;
NAME BYTES RESIZEABLE
-------------------------------- ---------- ----------
Fixed SGA Size 2257520 No
Redo Buffers 16904192 No ---> 16.12109 MB
Buffer Cache Size 1191182336 Yes ---> 1.10938 GB (1136MB)
Shared Pool Size 1912602624 Yes ---> 1.78125 GB (1824MB)
Large Pool Size 33554432 Yes --> 32MB
Java Pool Size 33554432 Yes --> 32MB
Streams Pool Size 16777216 Yes --> 16MB
Shared IO Pool Size 0 Yes
Granule Size 16777216 No --> 16MB
Maximum SGA Size 3206836224 No ---> 2.9866 GB (3058MB)
Startup overhead in Shared Pool 149023672 No ---> 142.12005 MB
Free SGA Memory Available 0

12 rows selected.

SQL> show parameter target
archive_lag_target integer 3600
db_flashback_retention_target integer 1440
fast_start_io_target integer 0
fast_start_mttr_target integer 0
memory_max_target integer 0
memory_target integer 0
parallel_servers_target integer 128
pga_aggregate_target integer 1073741824 ---> 1 GB (1024MB)
sga_target integer 3221225472 ---> 3 GB (3072MB)

I changed the values:
sga_max_size=3600MB
sga_target=3400MB

After restarting the database - I see following picture:

SQL> select * from v$sgainfo;

NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 2258840 No
Redo Buffers 14430208 No ----> 13.76172 MB - changed
Buffer Cache Size 1543503872 Yes ----> 1.4375 GB (1472MB) - changed
Shared Pool Size 1912602624 Yes ----> 1.78125 GB (1824MB) - NOTE: value remained the same as before
Large Pool Size 33554432 Yes ----> 32MB - NOTE: value remained the same as before
Java Pool Size 33554432 Yes ----> 32MB - NOTE: value remained the same as before
Streams Pool Size 16777216 Yes ----> 16MB - NOTE: value remained the same as before
Shared IO Pool Size 0 Yes
Granule Size 16777216 No ----> 16MB - NOTE: value remained the same as before
Maximum SGA Size 3758010368 No ----> 3.49992 GB (3583.91 MB) - changed
Startup overhead in Shared Pool 150970600 No ----> 143.97678 MB - changed
Free SGA Memory Available 201326592 ----> 192 MB - new value

12 rows selected.

SQL> show parameter target
archive_lag_target integer 3600
db_flashback_retention_target integer 1440
fast_start_io_target integer 0
fast_start_mttr_target integer 0
memory_max_target integer 0
memory_target integer 0
parallel_servers_target integer 128
pga_aggregate_target integer 1073741824 ---> 1 GB (1024MB) - NOTE: value remained the same as before
sga_target integer 3573547008 ---> 3.32813 GB (3408) - changed


I know that after SGA_TARGET parameter was set, Oracle tunes all needed SGA memory components dynamically.
But as you see in query result after I changed 2 SGA parameters - some components did not change dynamically.
Why? It is 1st question.

The 2nd question is what should do OR what parameter should I change in order Shared Pool Size, Redo Buffers, PGA Aggregate Target values were changed/increased?

With regards!

and Connor said...

Two things here

1) pga != sga.

Setting sga_target will have no impact on pga settings. Only if you use "memory_target" do we handle sga/pga as one, but in my experience, people use sga_target and pga_agg_target separately.

2) Increasing a target does not mean we "must" re-shuffle all of the memory pools. The concept of 'target' means that we can adjust pools *as needed* during the lifetime of the instance. Furthermore, we will remember what the values were at shutdown, so that when we restart, we have a reasonably intelligent starting point. If we increase the sga_target, then the most *likely* result will be the various pools will stay the same at restart time, but we'll give the memory to the pool that most likely benefits from an increase...and the would be the buffer cache.

Then over the life time of the instance, we may then opt to reshuffle that memory (which you can monitor via V$SGA_RESIZE_OPS






Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Bolat Makhmutov, March 06, 2017 - 5:41 am UTC

Thanks for reply,
let me continue for fully understanding.
I have read the post - https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1724586308922
Name of post: Log buffer size tuning

Reply:
Well, I just look at wait events. If you see lots of log_buffer_space waits, consider making the log_buffer init.ora parameter bigger.

Question:
Taking into account that analysis on wait events must be made. How to change log buffer size?

Because in oradocs it says --->
The size of the redo log buffer is determined by the initialization parameter LOG_BUFFER. You cannot modify the log buffer size after instance startup.

With regards!
Connor McDonald
March 07, 2017 - 2:07 am UTC

If you dont specify log_buffer, it will default to a fairly large size, where by "large" I mean you need to really hammering your system to have it become a problem. If you *do* have log buffer space problems and you are *not* hammering your system, then often it means an I/O or CPU issue.