The danger of memory target in Oracle 11g - request for discussion.

Question

Hello, everyone.
This is not a question, but kind of request for discussion.
I believe that many of you heard something about automatic memory management in Oracle 11g.
The concept is that Oracle manages the target size of SGA and PGA. Yes, believe it or not, all we have to do is just to tell Oracle how much memory it can use.
But I have a big concern on this. The optimizer takes the PGA size into consideration when calculating the cost of sort-related operations.
So what would happen when Oracle dynamically changes the target size of PGA? Following is a simple demonstration of my concern.
UKJA@ukja116> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
-- Configuration
*.memory_target=350m
*.memory_max_target=350m
create table t1(c1 int, c2 char(100));
create table t2(c1 int, c2 char(100));
insert into t1 select level, level from dual connect by level <= 10000;
insert into t2 select level, level from dual connect by level <= 10000;
-- First 10053 trace
alter session set events '10053 trace name context forever, level 1';
select /*+ use_hash(t1 t2) */ count(*)
from t1, t2
where t1.c1 = t2.c1 and t1.c2 = t2.c2
alter session set events '10053 trace name context off';
-- Do aggressive hard parse to make Oracle dynamically change the size of memory segments.
declare
  pat1     varchar2(1000);
  pat2     varchar2(1000);
  va       number;
  vc       sys_refcursor;
  vs        varchar2(1000);
begin
  select ksppstvl into pat1
    from sys.xm$ksppi i, sys.xm$ksppcv v   -- views for x$ table
    where i.indx = v.indx
    and i.ksppinm = '__pga_aggregate_target';
  for idx in 1 .. 10000000 loop
    execute immediate 'select count(*) from t1 where rownum = ' || (idx+1)
          into va;
    if mod(idx, 1000) = 0 then
      sys.dbms_system.ksdwrt(2, idx || 'th execution');
      select ksppstvl into pat2
      from sys.xm$ksppi i, sys.xm$ksppcv v   -- views for x$ table
      where i.indx = v.indx
      and i.ksppinm = '__pga_aggregate_target';
      if pat1 <> pat2 then
        sys.dbms_system.ksdwrt(2, 'yep, I got it!');
        exit;
      end if;
    end if;
  end loop;
end;
-- As to alert log file,
25000th execution
26000th execution
27000th execution
28000th execution
29000th execution
30000th execution
yep, I got it! <-- the pga target changed with 30000th hard parse
-- Second 10053 trace for same query
alter session set events '10053 trace name context forever, level 1';
select /*+ use_hash(t1 t2) */ count(*)
from t1, t2
where t1.c1 = t2.c1 and t1.c2 = t2.c2
alter session set events '10053 trace name context off';With above test case, I found that
1. Oracle invalidates the query when internal pga aggregate size changes, which is quite natural.
2. With changed pga aggregate size, Oracle recalculates the cost. These are excerpts from the both of the 10053 trace files.
-- First 10053 trace file
PARAMETERS USED BY THE OPTIMIZER
  PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
_smm_max_size                       = 11468 KB
_smm_px_max_size                    = 28672 KB
optimizer_use_sql_plan_baselines    = false
optimizer_use_invisible_indexes     = true
-- Second 10053 trace file
PARAMETERS USED BY THE OPTIMIZER
  PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
_smm_max_size                       = 13107 KB
_smm_px_max_size                    = 32768 KB
optimizer_use_sql_plan_baselines    = false
optimizer_use_invisible_indexes     = true
Bug Fix Control Environment10053 trace file clearly says that Oracle recalculates the cost of the query with the change of internal pga aggregate target size. So, there is a great danger of unexpected plan change while Oracle dynamically controls the memory segments.
I believe that this is a desinged behavior, but the negative side effect is not negligible.
I just like to hear your opinions on this behavior.
Do you think that this is acceptable? Or is this another great feature that nobody wants to use like automatic tuning advisor?
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================

Answer 1

I made a slight modification with my test case to have mixed workloads of hard parse and logical reads.
*.memory_target=200m
*.memory_max_target=200m
create table t3(c1 int, c2 char(1000));
insert into t3 select level, level from dual connect by level <= 50000;
declare
  pat1     varchar2(1000);
  pat2     varchar2(1000);
  va       number;
begin
  select ksppstvl into pat1
    from sys.xm$ksppi i, sys.xm$ksppcv v
    where i.indx = v.indx
    and i.ksppinm = '__pga_aggregate_target';
  for idx in 1 .. 1000000 loop
    -- try many patterns here!
    execute immediate 'select count(*) from t3 where 10 = mod('||idx||',10)+1' into va;
    if mod(idx, 100) = 0 then
      sys.dbms_system.ksdwrt(2, idx || 'th execution');
      for p in (select ksppinm, ksppstvl
          from sys.xm$ksppi i, sys.xm$ksppcv v
          where i.indx = v.indx
          and i.ksppinm in ('__shared_pool_size', '__db_cache_size', '__pga_aggregate_target')) loop
          sys.dbms_system.ksdwrt(2, p.ksppinm || ' = ' || p.ksppstvl);
      end loop;
      select ksppstvl into pat2
      from sys.xm$ksppi i, sys.xm$ksppcv v
      where i.indx = v.indx
      and i.ksppinm = '__pga_aggregate_target';
      if pat1 <> pat2 then
        sys.dbms_system.ksdwrt(2, 'yep, I got it! pat1=' || pat1 ||', pat2='||pat2);
        exit;
      end if;
    end if;
  end loop;
end;
/This test case showed expected and reasonable result, like following:
100th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
200th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
300th execution
__shared_pool_size = 88080384
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
400th execution
__shared_pool_size = 92274688
__db_cache_size = 16777216
__pga_aggregate_target = 83886080
500th execution
__shared_pool_size = 88080384
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
1100th execution
__shared_pool_size = 92274688
__db_cache_size = 20971520
__pga_aggregate_target = 83886080
1200th execution
__shared_pool_size = 92274688
__db_cache_size = 37748736
__pga_aggregate_target = 58720256
yep, I got it! pat1=83886080, pat2=58720256Oracle continued being bounced between shared pool and buffer cache size, and about 1200th execution Oracle suddenly stole some memory from PGA target area to increase db cache size.
(I'm still in dark age on this automatic memory target management of 11g. More research in need!)
I think that this is very clear and natural behavior. I just want to point out that this would result in unwanted catastrophe under special cases, especially with some logic holes and bugs.
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================