Re: 4031 errors in 19.7

  • From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
  • To: Jeffrey Beckstrom <jbeckstrom@xxxxxxxxx>
  • Date: Mon, 1 Mar 2021 17:41:20 -0500

KGH: NO ACCESS is buffer cache inside the shared pool (yes, it's a thing
since Oracle 10.2 :-)

https://tanelpoder.com/2009/09/09/kgh-no-access-allocations-in-vsgastat-buffer-cache-within-shared-pool/

For some reason the automatic SGA memory manager (SGA_TARGET or
MEMORY_TARGET) decided that it wanted to use more buffer cache at the
expense of shared pool, but couldn't completely clean a granule from shared
pool chunks (some were pinned), so it flushed out what it could and put the
KGH: NO ACCESS reservations in there, for buffer cache usage.

I've written about
https://tanelpoder.com/2009/09/13/kgl-simulator-shared-pool-simulator-and-buffer-cache-simulator-what-are-these/

You can set the *shared_pool_size* parameter to a bigger value, so it will
act as the minimum size for shared pool, even if your SGA is otherwise
dynamic thanks to ASMM. Btw, a total 3G shared_pool for E-Business Suite
(and 19c) doesn't seem like that much (of course depends on how many
concurrent users you have + how many EBS modules are in use too).

--
Tanel Poder
https://tanelpoder.com/events


On Mon, Mar 1, 2021 at 11:03 AM Beckstrom, Jeffrey <jbeckstrom@xxxxxxxxx>
wrote:

From the trace file. What could cause the KGH area to be so large?

TOP 10 MEMORY USES FOR SGA HEAP
----------------------------------------------
"KGH: NO ACCESS 0001" 1195 MB 40%
"SQLA 0003" 507 MB 17%
"free memory " 356 MB 12%
"KGLH0 0003" 270 MB 9%
"KGLS 0003" 70 MB 2%
"KGLHD 0003" 47 MB 2%
"PLMCD 0003" 40 MB 1%
"KQR X PO 0003" 38 MB 1%
"KGLH0 0001" 34 MB 1%
"SO private sga 0001" 32 MB 1%
TOTALS ---------------------------------------
Total free memory 356 MB
Total memory alloc. 2668 MB
Grand total 3024 MB

-----Original Message-----
From: Petr Novak <Petr.Novak@xxxxxxxxxxxx>
Sent: Monday, March 01, 2021 8:22 AM
To: oracle-l@xxxxxxxxxxxxx; Beckstrom, Jeffrey <jbeckstrom@xxxxxxxxx>
Subject: AW: 4031 errors in 19.7

Hallo Jeff,

I had similar experience . After upgrade from 12.2 single tenant to 19c
multitenant the  SQLArea was much smaller for same shared pool size.
In  AWR  the difference between shared pool size in
DBA_HIST_MEM_DYNAMIC_COMP  - sum( Shared Pool components) from
DBA_HIST_SGASTAT increased  after upgrade for the DB with 400G sga_target
from 6G to 35G.   May be some internal memory structures related to
multitenant ? For 19c single tenant this difference was almost same as
under 12c

Best Regards
Petr



________________________________________
Von: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> im
Auftrag von Beckstrom, Jeffrey <jbeckstrom@xxxxxxxxx>
Gesendet: Montag, 1. März 2021 14:01
An: oracle-l@xxxxxxxxxxxxx
Betreff: 4031 errors in 19.7

Since upgrading our Oracle EBS 12.1.3 IT Test system to 19.7 mutltenant
from 11.2.0.4. We have been experiencing shared pool errors. After the last
one, we increased sga_target to 1 G larger than we had in 11g. However, we
just experienced another 4031 error. The IT database only has the EBS
concurrent managers running and very other light activity. The error
occurred on Saturday when only thing else running was stats. Does 19c
multitenant require a much larger sga_target?

Jeffrey Beckstrom
Greater Cleveland Regional Transit Authority
1240 W. 6th Street
Cleveland, Ohio 44113

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



Other related posts: