Fwd: SGA heap latches

Looks like I hit reply instead of reply all

Regards
Jonathan Lewis
(From my iPad mini; please excuse typos and auto-correct)

Begin forwarded message:

> From: Jonathan Lewis <jlewisoracle_at_gmail.com>
> Date: 16 April 2022 at 13:42:04 BST
> To: Willy Klotz <willyk_at_kbi-gmbh.de>
> Subject: Re: SGA heap latches
> 
> 
> If you've set the streams pool size to 256MB and the SGA settings make Oracle use a default granule size of 512M then the streams pool has to take up at least one granule. There may be some algorithm in the granule allocation mechanism that then leads to a calculation of how many sub-pools Oracle will allow because that 512M streams pool either (a) demands too large a fraction of the total SGA, or (b) the size of the streams pool dictates the size of some other pool (e.g. the java pool) which has to allocate a granule in every sub-pool - and this exhausts memory.
> 
> It's the sort of thing you'd have to play around with, using a large sga_size/target with multiple CPUs to see if it's something very specific to particular versions of Oracle. Basically, though, I think it's Oracle trying to trade of concurrency (multiple sub-pools) against some threat of memory starvation that we can't infer.
> 
> (You might check on your system, I can't at present, I think the streams pool is allowed to limit itself to one sub-pool (which would show as one granule)  - but it's possible that it's one of the pools that has to allocate one granule per sub-pool.  Select * from v$sgastat where name = 'free memory' will probably give you the answer you need in the multiple (5 of 7) sub-pool case.
> 
> 
> Regards
> Jonathan Lewis
> 
> 
> 

--
http://www.freelists.org/webpage/oracle-l