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
controlsgroup
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 withowner
andgroup
access.When this parameter is set to TRUE, database shared memory is created with
owner
andgroup
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
Very nice…
Thanks!
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
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
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!
"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
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 🙂
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