[oaktable] Re: 10 gallons into a 5 gallon hat

  • From: John Beresniewicz <john.beresniewicz@xxxxxxxxx>
  • To: oaktable@xxxxxxxxxxxxx
  • Date: Thu, 4 Feb 2021 20:49:16 -0800

Init parameters values should be in the AWR report

On Thu, Feb 4, 2021 at 7:06 PM Tim Gorman <tim.evdbt@xxxxxxxxx> wrote:

Mighty dames and knights!

Has anyone seen anything like the following situation, excerpted from AWR
on a 12.1.0.2.0 database on Linux x86-64?



Yup, that's a 120 GB SGA in a 64 GB server.

Of course, I don't have access to the customer environment.  They sent the
AWR demanding to know what's wrong.

When I use my Oracle19c kit to try to set SGA_TARGET to 33G on a server
with 32G of RAM, SQL*Plus tells me...

SQL> startup force
ORA-27104: system-defined limits for shared memory was misconfigure


...while the alert.log shows...

Starting ORACLE instance (normal) (OS id: 15713)
2021-02-05T01:20:36.871142+00:00
System cannot support SGA size of 33 GB.
2021-02-05T01:20:36.871200+00:00
Total system memory configured is 31 GB.
2021-02-05T01:20:36.871252+00:00
Instance maximum shared memory size should be less than 28 GB.


...all of which is what one would expect.

When I search MOS, I find notes like Doc ID #2136920.1
<https://support.oracle.com/epmos/faces/DocumentDisplay?id=2136920.1>
(entitled "*SGA_MAX_SIZE And SGA_TARGET Allocation On Oracle Linux Server*")
which explains...


*It's somewhat OS dependent, but in general sga_max_size does not allocate
physical memory - it's held in swap or virtual space, and the amount of
physical memory allocated is only the amount being currently used.*

*SWAP comes into picture when there is no physical memory available,
inactive pages move to swap to make space in RAM for the space to be
utilized for active resources.*


...which certainly explains how it could happen.  Their database instance
isn't all that busy, but I think I can understand why it is so slow.

The ORA-27104 error exists in the documentation for 12.1
<https://docs.oracle.com/database/121/ERRMG/ORA-24280.htm#ERRMG-GUID-7B2814DB-F946-4EB1-80B5-219B256E90C0>,
but it doesn't exist in the documentation for 11.2
<https://docs.oracle.com/cd/E11882_01/server.112/e17766/e24280.htm>, so
it seems probable that it was added somewhere in that timeframe, which
explains why I couldn't reproduce the problem on 19c.

Even so, I'm guessing that ORA-27102 should have resulted as the "shmat()"
call would returns something like ENOMEM?  According to StackOverflow
<https://stackoverflow.com/questions/55927865/logical-address-space-is-larger-than-physical-and-backing-store-combined>,
it appears all this might be possible.

Just wondering if anyone here has seen this?  If so, then mystery resolved.

I'm going to keep after the customer, as clearly the solution is obvious
(i.e. "*Doctor, doctor, it hurts when I do this*").

But you never know, they may have figured out to convert water to wine.
See?  2021 is already so much better than 2020...

Thoughts?

Thanks!


-Tim

PNG image

Other related posts:

  1. Home
  2. oaktable
  3. Archive
  4. 02-2021