cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle 12c memory usage

former_member391782
Discoverer
0 Kudos

Hello!

We can see that the new oracle version (12.1.0.2.0) is significantly more main memory consumed than under the old oracle version (11.2.0.4.0).

Is there a fundamental statement regarding  the memory usage under oracle 12?

The oracle in memory option is not in use, enclosed you will see the current SBP.

13.08.2016 01:32:11 APPLY SERVER 12.1.0.2 SAP SBP 12.1.0.2.160119 201602 containing CPUJan2016

Thanks

Michael

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Michael,

how your SGA/PGA are configured ? What does that mean "significantly more main memory consumed"
can you provide details ?

Thanks, Sergo.

former_member391782
Discoverer
0 Kudos

Hi,

find enclosed our configuration.

Sometimes - mostly at the BTC processing phase – the DB/CI Server (2TB RAM Suse Linux ES 11 SP2) starts to swap.

BR

Michael

Former Member
0 Kudos

Hi,

I see you have a lot of free space inside the SGA at least.
As you have DB/CI installed on your server, and you have upgraded the DB to 12c
I assume you have upgraded kernel as well (721_EXT is the minimum).
So there are possible some memory leaks in DBSL and in other areas in SAP memory management
as well, I'm not sure that  Oracle is responsible for memory problems on your server.

How do you have configured oracle memory management, SAP doesn't reccomend to use automatic memory management parameters (sga_target, memory_target).
Could you provide information how you have that part configured?
Also pga_aggregate_target and pga_aggregate_limit parameters are feasible to check, and the PGA usage (you can check it form ST04 as well).

You can try to have a look inside the shared memory segments using "ipcs" command to see how your oracle DB and SAP application share the memory.

One more question, as you have so big amount of memory configured for Oracle and you are using Linux, do you have Huge Pages configured there?

Thanks, Sergo.