-- MOS: Bug 13250244 : ORA-4031 ERRORS SEEN WHEN PARAMETER _KGHDSIDX_COUNT IS SET TO >1 DUE TO MEM LEAK

--  ~~~~~~~~~~~~~
--  Testcase 
--  ~~~~~~~~~~~~~~~~~
--   
--    Files:  BDETC.tar.Z (containing init.ora, setup.sql, tc.sql)
--   
--    Steps:  
--      ** IMPORTANT ** Merge init.ora into the pfile used to start the instance.
--   
--      ie: Ensure the instance has _kghdsidx_count=4 set
--   
--   
--      sqlplus /nolog @setup
--        Creates a user TC with table FOO and a few stored outlines.
--        eg:
--          create table foo ( a number );
--          insert into foo values(10);
--          commit;
--          create index ifoo on foo(a);
--          analyze table foo compute statistics;
--          create sequence seq;
--          alter session set create_stored_outlines=true;
--          declare n number; 
--          begin
--            for i in 1 .. 10 loop
--              execute immediate 'select count(*) from foo where a='||i INTO n;
--            end loop;
--          end;
--          /
--   
--      sqlplus /nolog @tc
--        Sets USE_STORED_OUTLINES=TRUE and runs a load of literal selects.
--        eg:
--          alter session set use_stored_outlines=true;
--          declare n number; 
--          begin
--            for i in 1 .. 40000
--            loop
--              select seq.nextval into n from dual;
--              execute immediate 'select count(*) from foo where a='||n INTO n;
--            end loop;
--          end;
--          /
--   
--        Then flushes the shared pool and shows the number of 'STORED OUTLINE'
--        objects in V$DB_OBJECT_CACHE (ie: In the library cache).
--        eg:
--          select count(*) from v$db_object_cache 
--           where namespace='STORED OUTLINE';
--   
--          ^
--          After one run of tc.sql you will see there are many thousand
--          STORED OUTLINE objects in the library cache even after a flush
--          of the shared pool. These objects are not in use by anyone
--          but are not on the shared pool LRU so just accumulate "KGLHD"
--          space.
--   
--          If you run tc.sql several times then eventually you will get 
--          ORA-4031 errors as all free space is taken by the STORED OUTLINE
--          KGLHD handles.
--   
--   
--  Reproduced
--  ~~~~~~~~~~
--    Reproduced in 11.2.0.2
--    Reproduced in 11.2.0.3
--    Reproduced in RDBMS_MAIN_LINUX.X64_111025
--   
--   
--  Workaround/s
--  ~~~~~~~~~~~~
--   Use plan baselines and related 11g options to control the execution
--    plans instead of using stored outlines.
--   OR
--   The problem does not seem to occur if there is only one SGA subpool.
--   ie: Instance runs with "_kghdsidx_count"=1 
--   (but setting this to 1 may affect shared pool concurrency on some systems)
--   
--   The problem is aggravated by having USE_STORED_OUTLINES set for sessions
--    running literal SQL as each literal statement gets a STORED OUTLINE
--    handle , even if there is no matching outline (this is expected).
--    Hence avoiding literal SQL in sessions with USE_STORED_OUTLINES 
--    can help reduce/eliminate any impact from this problem
--    eg: If the DB has CURSOR_SHARING=FORCE then the example test above
--        leaks no KGLHD STORED OUTLINE handles
--   
--   
--  Diagnostic Notes
--  ~~~~~~~~~~~~~~~~
--   If a session has USE_STORED_OUTLINES set then any SQL issued by the
--   session gets an outline handle, even if there is no actual outline.
--   This is normal and expected.
--   
--   However,
--   It seems that if there is more than one shared pool subpool then
--   we somehow manage to get some stored outline handles left off of 
--   the LRU list leading to a leak of KGLHD STORED OUTLINE handles over 
