Oracle 12.2.0.1 Bundle Patch 12.2.0.1.170516 DBBP on Linux x86-64 is available

All credits go to Ricardo Maeda as I knew that we’ll release a Bundle Patch for Oracle 12.2.0.1 sometime this week – but I couldn’t find it linked from the usual MOS notes. And please don’t ask my why that is.

Anyhow, with patch 2579308 you’ll get access to the first BP for Oracle Database 12.2.0.1. There will be a first bigger Proactive Bundle Patch in July at the usual schedule – but this one is at least a start.

12.2.0.1.170516BP

Patch 2579308 – Oracle 12.2.0.1.170516BP

Plus in addition get the OPatch version 12.2.0.1.7 via patch 6880880.

The BP contains:

12.2.0.1.170516BP

First 12.2.0.1 Bundle Patch – Contents: Database BP and GI PSU

Obrigado, Ricardo!

–Mike

PSU or BP? Patch Set Update or Bundle Patch?

Well, in my new role as unofficial Junior Product Manager for Patching (just kidding) I get asked once a day (at least!) via email or in customer meetings or workshops: Should we take the PSUs or the BPs?

Should we take the PSUs or the BPs ?

PSUs are Patch Set Updates, BPs are (sometimes called: Proactive) Bundle Patches.

And the answer is very simple:

  • If you have an Oracle Engineered System: Take the Bundle Patches for Engineered Systems
  • In all other cases:
    • If you are on Oracle Database 12.1.0.x or newer: Take the Bundle Patches
    • If you are on Oracle Database 11.2.0.4: Take the Patch Set Updates
    • If you are on a release below Oracle Database 11.2.0.4: Upgrade!

Is there an official recommendation or guideline?

Yes, of course, there’s one. Very well explained in MOS Note: 1962125.1 – Overview of Database Patch Delivery Methods:

Bundle Patch Recommendation

Recommendation for Oracle 12c: Bundle Patches

What else do you need to know?

  1. Q: Is there a difference between “Bundle Patch” and “Proactive Bundle Patch“.
    A: It’s the same thing.
  2. Q: Can I apply Exadata Bundle Patches on non-Exadata Systems in Oracle 11g?
    A: Even though this is technically possible for Linux, there are certain restrictions. This is only supported in a standby configuration where one part is operated on an Exadata. See the FAQ at the end of MOS Note: 1962125.1 – Overview of Database Patch Delivery Methods
  3. Q: Can I flip from PSUs to BPs?
    A: When you approach a release or patch set upgrade (i.e. Oracle Database 11.2.0.3 to Oracle Database 12.1.0.2, or Oracle Database 12.1.0.1 to Oracle Database 12.1.0.2) you will start from scratch and have the full choice. But in-between a release you’ll have to deinstall at least the sql changes and roll in the new sql changes when you change between PSUs and BPs or vice versa. See my previous blog posts about switching from PSUs to BPs: https://mikedietrichde.com/2016/05/03/can-i-apply-a-bp-on-top-of-a-psu-or-vice-versa/
  4. Q: Why does Oracle still deliver PSUs in Oracle 12c even though it recommends to use the BPs?
    A: I don’t know. I can just assume that some customers insist to get the PSUs having a smaller number of fixes meaning potentially lower effect on their systems. But personally I totally disagree. When you look up the current issues list for Oracle 12.1.0.2 you will find out that many of the fixes are included in the BPs but not in the PSUs. If it would be my choice, I can perfectly (and better) live without PSUs but only getting BPs instead.
  5. Q: I have issues with the patches’ readme – can you explain it to me?
    A: No. Please log an SR. I get the “readme complaint” from almost every customer I see. And I see all the points and agree in most of them. Still, I’m not the owner of patching nor the owner of the readme’s. Telling it me is good – but telling it Oracle Support via an SR, and force a bug to be logged is the much better solution. Please please please, do log SRs when you are not happy with the patches’ readme, when things are unclear or wrongly carried over or whatever. The readmes get written by humans and they will need your feedback to improve the readmes.

–Mike

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

DBA_REGISTRY_HISTORY vs DBA_REGISTRY_SQLPATCH

At the DOAG Conference in November in Nürnberg in November 2016 a customer asked me right after my talk about “Upgrade to Oracle Database 12.2. – Live and Uncensored” why the DBA_REGISTRY_HISTORY does not get updated when he applies a Bundle Patch and follows all instructions including the “./datapatch -verbose” call.

I was wondering as well and asked him to open an SR. Which he did. And he received the message from Support that it is not supposed to appear in Oracle 12c anymore this way but only in DBA_REGISTRY_SQLPATCH. Now I dug a bit deeper internally to get a clear statement (thanks to Carol (my boss) and Rae (my teammate) and Scott (the man who owns datapatch) for following up!).

Patch Query in Oracle Database 11g

Tim Hall has published this simple and quite helpful script to query applied PSUs and BPs in Oracle Database 11g:
Script to monitor DBA_REGISTRY_HISTORY

And the output in my environment looked like this:

ACTION_TIME           ACTION  NAMESPE VERSION  ID      COMMENTS             BUN
 -------------------- ------- ------- -------- ------- -------------------- ---
 01-JUL-2016 15:24:56 APPLY   SERVER  11.2.0.4 160419  PSU 11.2.0.4.160419  PSU
 21-OCT-2016 17:40:32 APPLY   SERVER  11.2.0.4 161018  PSU 11.2.0.4.161018  PSU

But running the same script on Oracle Database 12.1.0.2 returnes (as for the customer) “no rows selected“.

Patch Query for Oracle Database 12c

Since Oracle Database 12.1.0.1 we use DBA_REGISTRY_SQLPATCH instead of DBA_REGISTRY_HISTORY to track PSUs and BPs applied to the database. I used this script: check_patches.sql.

My output in Oracle Database 12.1.0.2 looks like this:

ACTION_TIME          ACTION  STATUS   DESCRIPTION          VERSION  PATCH_ID BUND
-------------------- ------- -------- -------------------- -------- -------- ----
21-OCT-2016 17:29:36 APPLY   SUCCESS  DBP: 12.1.0.2.161018 12.1.0.2 24340679 DBBP

when using this tiny script:

SET LINESIZE 400
SET PAGESIZE 100
COLUMN action_time FORMAT A20
COLUMN action FORMAT A10
COLUMN status FORMAT A10
COLUMN description FORMAT A40
COLUMN version FORMAT A10
COLUMN bundle_series FORMAT A10

SELECT TO_CHAR(action_time, 'DD-MON-YYYY HH24:MI:SS') AS action_time,
 action,
 status,
 description,
 version,
 patch_id,
 bundle_series
 FROM   sys.dba_registry_sqlpatch
 ORDER by action_time;

But the question remains if – as in Oracle Database 12.1.0.1 – both views should get updated.

Explanation

In 11.2.0.4, we used the script catbundle.sql to apply bundle patches.  It uses DBA_REGISTRY_HISTORY only.  For 12.1.0.1 with the introduction of datapatch, we now have the (much better) DBA_REGISTRY_SQLPATCH.  This is used for both, bundle and non-bundle patches.  In Oracle Database 12.1.0.1. for bundle patches we actually called catbundle internally, so in 12.1.0.1 both registries were updated for bundle patches.
Starting in 12.1.0.2, however, only DBA_REGISTRY_SQLPATCH is queried and updated for bundle and non
bundle patches.

Update [Dec 23, 2016]

After discussing this and other issues with the owners of datapatch my teammate Rae logged a bug for this issue as we believe both views should be updated as it happened in 12.1.0.1. Bug# 25269268 tracks the issue.

–Mike

July 2016 – Proactive BPs and PSUs are available

Last night the July 2016 patches got released

Not all of them actually. In case you miss AIX, Intel Solaris and zLinux versions those should be available by Friday, July 22, 2016.

See the Oracle Critical Patch Update Advisory July 2016 for further details, and especially the Database announcement on MOS.

What’s new, what’s important?

First of all the renaming of DBIM and Exadata Bundle Patches into PROACTIVE BUNDLE PATCHES is now settled in more MOS notes.

2.1 Database patch for Engineered Systems and Database In-Memory 12.1.0.2 renamed to “Proactive Bundle Patch 12.1.0.2”

Starting from Apr2016 onwards the prior Database Bundle that was called “Database patch for Engineered Systems and Database In-Memory 12.1.0.2” will now be called “Proactive Bundle Patch 12.1.0.2”. This patch will continue be a cummulative patch and will include all prior fixes. The Apr2016 Proactive BP can also be applied on top the Jan2016 “Database patch for Engineered Systems and Database In-Memory 12.1.0.2”.

Does Oracle really recommend the Proactive Bundle Patches?

Well, I blogged about it almost 3 months ago and received several emails and comments from customer and colleagues sending me either complaints or SRs where somebody in Oracle Support gave them a hard time as one has applied a Proactive Bundle patch on a non-Exadata system. Hm … the fact the Proactive BPs were available in Solaris, AIX and HP-UX as well got simply ignored. Sorry for the inconvenience – but Oracle is a big ship and sometimes it takes a while until the message reaches really everybody.

Anyhow, in case you get into discussion with Oracle Support people in an SR please direct them to MOS Note: 1962125.1 – Oracle Database – Overview of Database Patch
Delivery Methods
:

Oracle makes the following recommendation for which patch method to use for Database related installations:

  • Every customer should at least install PSUs. Minimal testing required.
  • 12.1.0.2 Customers wanting a more comprehensive set of fixes should install the Database Proactive Bundle patch. This requires a bit more testing than a Patch Set Update (PSU), but delivers a larger set of fixes

1 The “Database Proactive Bundle Patch” requires a bit more testing than a Patch Set Update (PSU) as it delivers a larger set of fixes. 

[above table and text is taken from MOS Note:1962125.1 as of July 20, 2016]

Other changes you should be aware of?

And you’ll find also significant changes in the naming in MOS Note:1683799.1 – 12.1.0.2 Patch Set – Availability and Known Issues. The Recommended Patches section differentiates now between Exadata, RAC and non-RAC systems making your choice much easier, and removes the misleading naming for DBIM:

Non Exadata Non RAC

Document Description Rolling RAC Patch Download
Note:23615334.8 Combo of 12.1.0.2.160719 OJVM PSU and 12.1.0.2.160719 DBBP (Jul 2016) Part Patch:23615334
Note:23615289.8 Combo of 12.1.0.2.160719 OJVM PSU and 12.1.0.2.160719 DB PSU (Jul 2016) Part Patch:23615289
Note:23273686.8 12.1.0.2.160719 Database Proactive Bundle Patch (Jul 2016) Yes Patch:23273686
Note:23177536.8 Oracle JavaVM Component 12.1.0.2.160719 Database PSU (Apr 2016) (OJVM PSU) No Patch:23177536
Note:23054246.8 12.1.0.2.160719 (Jul 2016) Database Patch Set Update (DB PSU) Yes Patch:23054246

I’d recommend you the one in BOLD letters unless you use OJVM and require the OJVM patch in addition.

And finally … the summary!

For those who have no time to read such a lengthy blog post here’s the important facts:

–Mike

[Addition/Update] 

Please be aware of:

  • BUG 24332805 – OUI-67124:RE-LINK FAILS ON TARGET “ISQORA” DURING JUL 2016 PSU APPLY”
  • Two workarounds:
    • Addition of UnixODBC package to server
      • Install the “unixODBC” packages:
        yum install unixODBC
      • Re-run the ins_odbc.mk
        • cd $ORACLE_HOME/odbc/lib/
        • make -f ins_odbc.mk isqora
    • Removing the sqora relinking from ‘actions.xml’ file of Linux x86-64 12.1.0.2.160719 DBPSU
      • It is already removed from all the other platforms

 

Oracle April 2016 PSU and Proactive BPs are there

Hurray, it’s Patching Day!

Sounds a bit like D-Day 😉 But April 19, 2016 the most recent April PSUs (Patch Set Updates) and BPs (Bundle Patches) got released.

Find all the necessary information with the below links:

The important change in the April PSU/BP release:
The database patch for “Engineered Systems and Database In-Memory 12.1.0.2” luckily got renamed into “Proactive Bundle Patch 12.1.0.2”. That is not only a rebranding but it should express that we would like to encourage you to apply the Bundle Patches
instead of the PSUs. Simple reason is that the BPs will contain optimizer fixes.

In the MOS Note: 2102148.1 (Patch Set Update and Critical Patch
Update April 2016 Availability Document)
you’ll find a section 3.1.4 linking to the database patches.

This is the recommended one for Oracle Database 12.1.0.2:

  • Database Proactive Bundle Patch 12.1.0.2.160419 (Apr2016) Patch 22899531,

But right now it is available for Linux-x86-64, zLinux and Intel Solaris only. Not sure when the others will get released. Please find links to the regular PSUs and other ports and releases such as 11.2.0.4 and Windows etc in the above MOS Note: 2102148.1.

This is the list of fixes included in this Bundle Patch:

And don’t worry about the name – I found out yesterday that not all MOS Notes have adopted the new naming convention to rename “Bundle Patches for Engineeered Systems and DB In-Memory” which was very misleading anyway into the new “Proactive Bundle Patches” naming. This may take a few additional days I’d guess …

I will download it right now and patch my HOL environment.

And as usual don’t forget the most recent version of opatch (Patch 6880880).

opatch download MOS

–Mike