New SPFILE parameters in Oracle Database 12.1.0.2 with July 2016 (and newer) PSU/BP

New Parameters in Oracle Database 12.1.0.2 with July 2016 PSU/BP

By following an internal discussion and checking parameter changes between Patch Set Updates (PSU) and Proactive Bundle Patches (BP) I learned that we introduced two new SPFILE parameters in Oracle Database 12.1.0.2 with the July PSU and BP. One is documented in the patch readme, the other one can be found right now only in the Oracle Database 12.2.0.1 manual:

The Oracle 12.2 documentation about ALLOW_GROUP_ACCESS_TO_SGA, the parameter which appears not in the Oracle 12.1 documentation right now, says:

ALLOW_GROUP_ACCESS_TO_SGA controls group access to shared memory on UNIX platforms.

The default value is FALSE, which means that database shared memory is created with owner access only. In Oracle Database releases prior to Oracle Database 12c Release 2 (12.2.0.1), database shared memory was created with owner and group access.

When this parameter is set to TRUE, database shared memory is created with owner and group access. This behavior grants permissions to DBAs to manage shared memory outside the database, but also allows DBAs to read and write to shared memory, which may not be desirable for certain installations.

So there’s a tiny correction required:
It should say “prior to Oracle Database 12.1.0.2 July 2016 PSU/BP”.

The ENCRYPT_NEW_TABLESPACES parameter came in for the cloud deployments and is documented in the description
of the July Proactive BP
:

12.1.0.2.DBBP:160719 21281607E Transparently encrypt tablespace at creation in Cloud (adds “encrypt_new_tablespaces”)

 

Why does ALLOW_GROUP_ACCESS_TO_SGA appear in Oracle Database 12.1.0.2?

Simple reasons: it will make Oracle Database 12.1.0.2 more secure. Default for this parameter is FALSE – which actually changes behavior but may not affect you at first sight. And that’s why I blog about it.

You will recognize that the Oracle executable runs now with permission “600” – whereas it was “640” before. See my example of an 12.1.0.2 database with the January 2017 BP in place:

$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 23298063   oracle     600        2932736    76                      
0x00000000 23330832   oracle     600        1040187392 38                      
0x00000000 23363601   oracle     600        5455872    38                      
0xc8969114 23396370   oracle     600        20480      38       
...

whereas my 11.2.0.4 database runs with different permissions:

$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status     
0x00000000 22872084   oracle     640        12582912   21                      
0x00000000 22904853   oracle     640        721420288  21                      
0xd41b1c5c 22937622   oracle     640        2097152    21 
...

Does this effect the connection of your applications to the database?
No, of course not.

It has only an effect if you try to access the SGA from the OS level, i.e. attaching to the shared memory segment. In the old behavior an OS user being in the same group can attach and read from the SGA. With the new “600” protection only the OWNER can attach to it – and read out the SGA.

This is the standard behavior in Oracle Database 12.2.0.1 and onward. And it has been backported to the July 2016 PSU and Proactive Bundle Patches which are cumulative, i.e it is in all following PSUs and BPs included as well.

–Mike

7 thoughts on “New SPFILE parameters in Oracle Database 12.1.0.2 with July 2016 (and newer) PSU/BP

  1. Mike,
    Has Oracle addressed all the issues with Automatic Memory Management in this release? In other words, is it OK and recommended to use AMM with systems where memory is greater than 4Gbs? Or are we still in the same boat?

    Thanks,
    Roberto

  2. Roberto,

    I keep my recommendation to NOT SET memory_target. It will not allow you to use hugepages and personally I don’t see a bigger reason for having the database decide the spread between PGA and SGA sizes.

    Cheers
    Mike

  3. How about shifting workloads where nightly jobs are more batch/reporting oriented and daytime transactions are OLTP?

    Also, if the consensus is not to use AMM, why does Oracle insists on recommending it? What Im trying to say is, why not update the documentation (metalink notes, etc) to delete recommending the use of AMM?

    Thanks!

  4. "Also, if the consensus is not to use AMM, why does Oracle insists on recommending it? What Im trying to say is, why not update the documentation (metalink notes, etc) to delete recommending the use of AMM?"

    I understand your point – but this is not in my hands 😉
    Our recommendation is based on experience and learning from the field, from customers – and working with them 🙂

    I see your point with shifting workloads but especially with such scenarios I have seen some limitations with memory_target. And the fact that it does not allow the use of hugepages makes almost every discussion pointless 😉

    Cheers
    Mike

  5. It seems like the encrypt_new_tablespaces parameter is only included in the BP, at least on my on-premises machine (Oracle 12.1.0.2 with October 2016 PSU) it’s not present and the documentation (Doc ID 21281607.8) of the bug about missing encryption in the cloud mentions July 2016 BP and 12.2 as first fixed versions. The other parameter, however, works fine 🙂

  6. Katharina,

    thanks for your input. And you may be right – I stopped applying PSUs to my 12.1. homes since the July 2016 one. The last one I can currently compare with is the April one and there it was not there in either the PSU or BP. And it appeared at first in the July 2016 BP as you recognized.

    Thanks for your comment!

    Cheers
    Mike

Leave a Reply

Your email address will not be published. Required fields are marked *