Manual operations in an automatic SGA database

Oracle 10g introduced the nifty feature of automatic SGA, simply set the parameter sga_target and sga_max_size to the maximum size you can afford and Oracle will do the rest. But we still have a few manual settings, say you want a tablespace with a non-default block size (also a new feature) than the database default and you create, say a 4k block size, tablespace in a 8k database and you allocate a db_4k_cache_size for that. How do Oracle allocate that memory?

Test:

SQL> select name,value from v$parameter
       where name like 'sga_target'
     /

NAME            VALUE
--------------- --------------------
sga_target      599785472

SQL> select name,round(bytes/1024/1024) M from v$sgainfo;

NAME                                              M
---------------------------------------- ----------
Fixed SGA Size                                    2
Redo Buffers                                      6
Buffer Cache Size                               416
Shared Pool Size                                140
Large Pool Size                                   4
Java Pool Size                                    4
Streams Pool Size                                 0
Granule Size                                      4
Maximum SGA Size                                572
Startup overhead in Shared Pool                  68
Free SGA Memory Available                         0

11 rows selected.

SQL> alter system set db_4k_cache_size=4M;

System altered.

SQL>  alter system set db_4k_cache_size=0;

System altered.

-- What actually happend here, from what 
-- did Oracle steal those 4Mb
-- Let's query the v$sga_resize_ops view to see that was done.

SQL> select parameter,oper_type,initial_size,target_size 
       from v$sga_resize_ops 
       where start_time>sysdate-1
     /

PARAMETER        OPER_TYPE     INITIAL_SIZE TARGET_SIZE
---------------- ------------- ------------ -----------
db_cache_size    SHRINK           436207616   427819008
db_4k_cache_size GROW                     0     8388608
db_4k_cache_size SHRINK             8388608           0
db_cache_size    GROW             427819008   436207616

SQL>

Ok, we can see that Oracle shrank the db_cache_size with the requested size and allowed the db_4k_cache_size to grow and when reset back to zero it freed the memory and grew the db_cache_size. Oracle could just as well have allocated the memory to the large_pool if the automatic SGA engine thought that would make more sense.
I've got the last 7 days worth for resize ops in my weekly database report that is e-mailed to me every Monday morning, it's definitely worth keeping an eye on whats going on. Sometimes it's just easier to configure the SGA manually.