Wednesday Feb 01, 2017

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

New Parameters in Oracle Database 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 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 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 (, 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 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: 21281607E Transparently encrypt tablespace at creation in Cloud (adds "encrypt_new_tablespaces";)


Why does ALLOW_GROUP_ACCESS_TO_SGA appear in Oracle Database

Simple reasons: it will make Oracle Database 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 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 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 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.


Tuesday Nov 01, 2016

October 2016 Proactive BP got replaced

Just received a message from Oracle Support this early morning as I did install the Proactive Bundle Patch from October 2016 into my Oracle Database environment saying:

Dear Oracle Customer,

You are receiving this email because our recordsindicate you downloaded the following patch:

Patch number: 24448103
Release: DB Proactive Bundle
Platform: Linux x86-64

This patch has been replaced and is now available for download. Please review section 1.1 of the
following My Oracle Support note for further technical details and instructions:

Note: 2171506.1 - Oracle Database Proactive Patch Known Issues

Issue found:

SCAN Listener or local listener fails to start

The symptom of failed to start SCAN listener resource happens in environments that have been upgraded from 11.2 to 12.1.

The Oct2016 Proactive Bundle Patch Patch 24448103 has been uploaded again with a fix for this issue as of 30-Oct-2016 8am PST.

The My Oracle Support Note: 2166451.1 - "SCAN Listener or local listener fails to start after applying Patch 23273629 - Oracle Grid Infrastructure Patch Set Update (Jul2016) or Oct DB BP patch 24448103" has more information

It didn't affect me as I don't have the SCAN listener in my environments. But you should be aware of this.


Thursday Oct 20, 2016

October 2016 PSU and BP - Database Patching?

What will you get when you download the most recent Oracle Database PSU or BP from October 2016?

MOS Note: 1683799.1 - Patch Set - Availability and Known Issues is not entirely clear. Therefore lets shed some light ...

The Matrix

This matrix in MOS Note: 1683799.1 tells you about the availability of PSUs and BPs for a regular database installation (non-RAC, non-Exadata). But it doesn't clearly tell you what's included - and the names being used aren't very revealing either.

Non Exadata Non RAC

Document Description Rolling RAC Patch Download
Note:24448103.8 Database Proactive Bundle Patch (Oct 2016) Yes Patch:24448103
Note:24436306.8 Combo of OJVM PSU and DBBP (Oct 2016) Part Patch:24436306
Note:24433133.8 Combo of OJVM PSU and DB PSU (Oct 2016) Part Patch:24433133
Note:24315824.8 Oracle JavaVM Component Database PSU (Oct 2016) (OJVM PSU) No Patch:24315824
Note:24006101.8 (Oct 2016) Database Patch Set Update (DB PSU) Yes Patch:24006101

My Matrix

I translate this into:

Non Exadata Non RAC

Document Description Rolling RAC Patch Download DB PSU
Note:24448103.8 Database Proactive Bundle Patch (Oct 2016) Yes Patch:24448103

Note:24436306.8 Combo of OJVM PSU and DBBP (Oct 2016) Part Patch:24436306

Note:24433133.8 Combo of OJVM PSU and DB PSU (Oct 2016) Part Patch:24433133 X

Note:24315824.8 Oracle JavaVM Component Database PSU (Oct 2016) (OJVM PSU) No Patch:24315824

Note:24006101.8 (Oct 2016) Database Patch Set Update (DB PSU) Yes Patch:24006101 X

How to apply a Proactive Bundle Patch?

If you've never done it before, applying a Proactive Bundle Patch to a database-only installation is not very complicated. Please see my own step-by-step instructions here (but don't forget to check the current readme as well please!).

More Information:


Wednesday Oct 19, 2016

October 2016 PSU and Proactive BP are available

When the leafs are falling down ...

... then it's time for the October 2016 Patch Set Update (PSU) and Proactive Bundle Patches (BP). 

Things you need to know:

Interesting information:

  • Newly scheduled final patches:

I'll update you as soon as I applied the BP to my and the PSU to my environment.



Tuesday Oct 04, 2016

Can I apply a BP on top of a PSU? Or vice versa? PART 2

I thought I won't blog about this again:

But then a colleague of mine raised this simple question:

  • "I have a customer that would like to change from patching using PSU to patching using Bundle Patch. I am wondering what happens if my home has had several PSUs installed. Before applying a BP, would I need to rollback one by one all the PSUs that have been installed in reverse order (tedious) OR only the latest PSU (good)?"

Unfortunately the "simple" solution is hidden deep down in the documentation and not mentioned (as far as I could see) in any MOS Note.

The secret is the opatch option "all_subpatches".

And this is the solution

  • All PSU sub-patches have to be rolled back
  • Use the -all_subpatches option - it will roll them all back in the correct sequence.
    • Note: all overlay patches need rolled back 1st
  • Example:
    • % opatch rollback –id <current patch number> -all_subpatches
  • Documentation says:
    "This option is valid ONLY for composite patches. It allows the user to rollback all sub-patches of a composite series in one shot."

Hope this helps here and there ...


Monday Aug 08, 2016

OJVM patch: Standby-First patching, yes or no?

I have blogged in the past more than once about the "wonderful" topic of OJVM patching. And please don't beat me and you can be sure that even our execs are aware of this topic.

Anyhow,  I'd like to summarize a few typical questions sent to me in the past months regarding OJVM patching.

Do I need to apply the OJVM patch every time I apply a PSU or BP?

Unfortunately this is not a one-time-and-then-you-are-set operation. You'll have to do it every time.

How do I find out if OJVM is used in my database?

I tried to nail this down in this blog post here:

But the best solution would be to not install OJVM from the beginning if you have no intention of using it. It's far more simple to install it later on than to remove it.

Can OJVM patch being rolling installable or standby-first applicable?

No, unfortunately the OJVM patch is neither rolling installable in a RAC database nor can it be applied in the Standby-First patching method.
Please see MOS Note:1929745.1
Oracle Recommended Patches -- OJVM PSU Patches


Is the Mitigation Patch a valid workaround to OJVM patching downtime?

Well, I leave this up to you. But if you have never heard of the OJVM Mitigation patch before please see again MOS Note:1929745.1 - Oracle Recommended Patches -- OJVM PSU Patches:

For situations where the latest OJVM PSU cannot be installed immediately there is a "Mitigation Patch" that can be used. The "Mitigation Patch" is an interim solution to protect against all currently known (Jul 2015) Oracle JavaVM security vulnerabilities in the database until such time as the OJVM PSU can be installed. It can also be used to protect database versions no longer covered by error correction support.

The "Mitigation Patch":

  • is applicable only to database homes, not client nor Grid homes

  • is only applicable to databases that have JavaVM installed

  • has no dependency on the DB PSU (or equivalent) level

  • can be installed in a RAC Rolling manner

  • is a SQL only patch that needs to be installed and activated in each database
    • hence it can be installed standby first but it requires SQL steps to be executed to be effective, which cannot be done on a read only standby

  • affects use of Java and Java development in the database

  • has been reviewed for January 2015, April 2015, July 2015, October 2015, January 2016, April 2016 and July 2016 and provides mitigation against all currently known OJVM vulnerabilities

  • can be downloaded here: Patch:19721304

Does OJVM Patching affect the Grid Infrastructure Rolling Patching?

No, it doesn't. Oracle Grid Infrastructure patching is always rolling and does not get affected by the OJVM patch.

I'm pretty sure this does not answer all your questions but please don't hesitate to open SRs with Oracle Support. I will update this FAQ from time to time.


Monday Aug 01, 2016

PDB unplug/plug/patch with PSUs or BPs

This question was posted on the blog a few days ago referring to my previous blog posts describing the two techniques to upgrade in an Oracle Multitenant environment:

We are planning to upgrade from to
The plan is to create new oracle home and
gradually moving PDB from to
Should I follow the same steps?
Is there any document for what we want to do?   

And luckily there is a MOS Note out there describing the steps:

The part this note is not talking about is the unplug/plugin operations in detail.
But this is something you'll find here: 


Thursday Jul 28, 2016

Proactive Bundle Patches - Change reflected now in MOS as well

Now the Known Isuses and Alerts and Recommended Patches Notes in MOS reflect the naming and classification change of the different types of patches as well.

See in:

MOS Note:1683799.1 - Patch Set - Availability and Known Issues

We don't speak about Bundle Patches for Exadata and DBIM anymore making it easier to find the correct patch for your platform.

Just wanted to share this as I'm refreshing our upgrade slide deck at the moment :-)


Wednesday May 04, 2016

Are BPs. PSUs and Proactive BPs cumulative?

Are Bundle Patches (BPs) and Patch Set Updates (PSUs) cumulative?

That is a question sounding trivial to many people but actually it does get asked quite often. And sometimes I forget to mention this during the workshops - and luckily usually somebody asks the question reminding me to explain it.

Yes, Bundle Patches and Patch Set Updates (and of course Proactive Bundle Patches and Critical/Security Patch Updates (CPUs/SPUs) are all cumulative.

You'll find this mentioned in the first paragraph of MOS Note: 854428.1 - Patch Set Updates for Oracle Products:


Interesting note on the side:
I would have expected this important piece of information in MOS Note:1962125.1 - Oracle Database - Overview of Database Patch Delivery Methods but I couldn't find it. So it's no wonder why people ask such a trivial question ... [irony!]  

Two simple examples:

  • You have the October 2015 PSU applied
  • You'd like to apply the April 2016 PSU on top
    • Then you don't need the January 2016 PSU as it is included in the April 2016 PSU already
  • You never applied a Procative Bundle Patch
  • You'd like to apply the April 2016 Proactive Bundle because a guy recommended it on an Oracle blog - and actually MOS notes mention it as well as highly recommended
    • You don't need to apply anything beforehand.
      The April 2016 Proactive BP has all the fixes from all previous BPs included on top of Oracle Database

Further Information?

You'll find recent related postings on this blog here: 


Tuesday May 03, 2016

Can I apply a BP on top of a PSU? Or vice versa?

This question was in my inbox this morning raised by a customer via a colleague. 

Our feeling said:
Yes, but you'll have to deinstall the PSU first before applying the BP.

Having a feeling is one thing, knowing the truth is better. And as I have so much fun by applying PSUs and BPs back and forth since two weeks I thought "let's give it a try". So here we go ...

Apply a BP on top of a PSU

This is my starting point - Oracle Database with PSU October 2015, the last state in my VBox environment since I experiment with parameters and packages at the moment.

And this is the result when trying to apply the BP from April 2016 on top: 

[CDB2] oracle@localhost:/media/sf_CTEMP/22899531/22899531/22806133
$ opatch apply
Oracle Interim Patch Installer version
Copyright (c) 2016, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/
OPatch version    :
OUI version       :
Log file location : /u01/app/oracle/product/

Verifying environment and performing prerequisite checks...

Conflicts/Supersets for each patch are:

Sub-Patch : 20243804

        Bug Conflict with Sub-Patch 21359755
        Conflicting bugs are:
        18966843, 19468991, 19032777, 19587324


Following patches have conflicts: [   21359755   22806133 ]
Refer to My Oracle Support Note 1299688.1 for instructions on resolving patch conflicts.

UtilSession failed: Patch 21359755 is a composite patch which could not be rollback.

Log file location: /u01/app/oracle/product/

OPatch failed with error code 73

Ok, our suspicion was correct.

There are a lot of conflicts - I have to remove the PSU first. And of course the recommended conflict check would have given me the same result. Furthermore I think I have read this a while back in one of the central notes about PSUs and BPs in MOS as well.

Removing the PSU from October 2015 first

Removing a PSU or BP is very simple and straight forward (and well described in the ReadMe.html coming coming with the patch).

[CDB2] oracle@localhost:/media/sf_CTEMP/21359755/21359755
$ opatch rollback -id 21359755
Oracle Interim Patch Installer version
Copyright (c) 2016, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/
OPatch version    :
OUI version       :

Log file location : /u01/app/oracle/product/

Patches will be rolled back in the following order:
   21359755   20831110   20299023   19769480
The following patch(es) will be rolled back: 21359755  20831110  20299023  19769480
Sub-patches of a composite series are being rolled back. The system will be returned to a state where all subpatches are rolled back.


Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/')

Is the local system ready for patching? [y|n]

User Responded with: Y
Rolling back patch 21359755...


RollbackSession removing interim patch '19769480' from inventory Log file location: /u01/app/oracle/product/ OPatch succeeded.

Afterwards please make sure to run ./datapatch -verbose to rollback the SQL changes as explained in section 4 of the README.html (and of course all other steps mentioned there).

Apply the BP from April 2016

I don't want to repeat myself as I wrote already about this positive experience a few days ago:

Oracle Database BP April 2016 applied successfully (Apr 21, 2016)

I continued this blog post on a later occasion here:

Further Information?

You'll find recent related postings on this blog here:


Tuesday Apr 26, 2016

MOS Note 1454618.1: Quick Reference to Database PSUs, CPUs, BPs and Patchsets

Sometimes my mouse arm gets tired by clicking myself through MOS notes just to download a specific PSU or BP - and as I experiment a lot with PSUs and BPs right now I clicked a lot in the past days and nights. 

Usually I'd start with either MOS Note:161818.1 - then click on the release link (e.g. 12.1.0.x) in the left-most column, then into the Availability and Known Issues not (e.g. MOS Note:1683799.1 for Oracle Database and then select the most recent patch from the list of Current Recommended Patches.

Even though we all agree that you should be ideally always on the most recent BP (or at least PSU) there may be situations where you need to access an older PSU or BP or just the CPU.
So what if you need for instance the October 2015 PSU?
This is obviously not linked from the above note.

My usual click routine guides me via the Critical Patch Updates and Security Alerts page, from there via the particular release date (e.g. October 2015) to the Database Server Version (e.g. linked from here is MOS Note:2037108.1) and then to the patch number I'm searching for.

Just learned a few days ago by accident that there's a MOS Note which I have on my favorites since then:

containing all this information - even for patches if you still need them ;-)

After listing the base release first followed by the available patch sets it offers you the links to the PSUs, CPUs and BPs - and if you are looking for the patches containing the OJVM you'll find them by scrolling down towards the end of the note as well in a separate section. 

*** Don't get puzzled by the note's title - it lists the Bundle Patches for Windows only inside, not the general link to all BPs. Myself and a colleague left already feedback for the note owner to add the BP links (or Proactive Bundle Patch links) as well *** 

MOS Note Patches PSUs CPUs SPUs BPs

In fact a very useful MOS Note.


Thursday Apr 21, 2016

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" luckily got renamed into "Proactive Bundle Patch". 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

  • Database Proactive Bundle Patch (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 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



Tuesday Feb 02, 2016

How to find out if a PSU has been applied? DBMS_QOPATCH

pflaster.jpgSince we change the PSU and BP patch numbering from Oracle Database to 12,1,0,2,160119 it is almost impossible to distinguish from the patch name only if you have applied a PSU or a BP.

In Oracle Database 12c there's a package available which is very useful to query plenty of information about patches from within the database: DBMS_QOPATCH.

Here are a few helpful examples which I created by checking in our DBaaS Cloud database.

Which patches have been applied (or rolled back)?

SQL> set serverout on

SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 20415564
        Action : APPLY
        Action Time : 24-JUN-2015 06:19:23
        Description : Database PSU, Oracle JavaVM Component (Apr2015)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20415564/18617752/
        Status : SUCCESS

Patch Id : 20299023
        Action : APPLY
        Action Time : 24-JUN-2015 06:19:23
        Description : Database Patch Set Update : (20299023)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20299023/18703022/
        Status : SUCCESS

Patch Id : 20848415
        Action : APPLY
        Action Time : 24-JUN-2015 06:19:23
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20848415/18918227/
        Status : SUCCESS

Patch Id : 20848415
        Action : ROLLBACK
        Action Time : 24-JUN-2015 06:52:31
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20848415/18918227/
        Status : SUCCESS

Patch Id : 20618595
        Action : APPLY
        Action Time : 24-JUN-2015 13:52:13
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20618595/18956621/
        Status : SUCCESS

Patch Id : 20618595
        Action : ROLLBACK
        Action Time : 24-JUN-2015 14:37:11
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20618595/18956621/
        Status : SUCCESS

Patch Id : 20415564
        Action : ROLLBACK
        Action Time : 27-JAN-2016 17:43:18
        Description : Database PSU, Oracle JavaVM Component (Apr2015)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20415564/18617752/
        Status : SUCCESS

Patch Id : 21555660
        Action : APPLY
        Action Time : 27-JAN-2016 17:43:18
        Description : Database PSU, Oracle JavaVM Component (Oct2015)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/21555660/19361790/
        Status : SUCCESS

Patch Id : 21359755
        Action : APPLY
        Action Time : 27-JAN-2016 17:43:18
        Description : Database Patch Set Update : (21359755)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/21359755/19194568/
        Status : SUCCESS

Patch Id : 21962590
        Action : APPLY
        Action Time : 27-JAN-2016 17:43:18
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/21962590/19426224/
        Status : SUCCESS

PL/SQL procedure successfully completed.

Where's my home and inventory?

SQL> set pagesize 0

SQL> set long 1000000 

SQL> select xmltransform(dbms_qopatch.get_opatch_install_info, dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual;

Home and Inventory

Oracle Home     : /u01/app/oracle/product/12.1.0/dbhome_1

Has a specific patch been applied?

Lets check for the latest PSU. 

SQL> select xmltransform(dbms_qopatch.is_patch_installed('21359755'), dbms_qopatch.get_opatch_xslt) "Patch installed?" from dual;

Patch installed?

Patch Information:
         21359755:   applied on 2015-10-22T21:48:17Z


What's tracked in my inventory?

The equivalent of opatch lsinventory -detail ...

SQL> select xmltransform(dbms_qopatch.get_opatch_lsinventory, dbms_qopatch.get_opatch_xslt) from dual; 

Oracle Querayable Patch Interface 1.0
Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1
Inventory         : /u01/app/oraInventory

Installed Top-level Products (1):
Installed Products ( 135)


Additional Information and Patches

If you need more helpful examples you may check this excellent blog post by Simon Pane (Pythian):

And credits to Martin Berger for sending me this important information:

Just in case there are multiple DBs running from the same O_H, and someone      
queries dbms_qopatch.get_opatch_lsinventory automated from all DBs (as in       
automated monitoring/reporting scripts) I'd recommend Patch 20599273 -          
otherwise there might be strange XM errors due to race conditions. 


DBMS_QOPATCH does not work in PDBs

Finally, as you can see from the comments section, some people commented that using DBMS_QOPATCH in a PDB does not work. But there's a solution coming:


Wednesday Jan 20, 2016

Oracle January 2016 CPU PSU BP available now - BE AWARE OF CHANGES IN PATCH NUMBERING

Last night the PSUs and BPs for January 2016 have been made available for download on

Oracle Critical Patch Update Advisory - January 2016 

It contains 248 security fixes across all products and platforms. And of course important non-security fixes - and that's why we recommend to apply the PSUs (or the BPs in case you are on Exadata or an Oracle In-Memory user) as soon as possible. 

Change in Patch Numbering

Please be aware that as of November 2015 there's been a change in patch numbering introduced which most of you may not be aware of. A database PSU was named before (or I used to call it before to make clear that a PSU and not a BP has been applied). But the new notation will change the 5th digit to a 6-digit-number to include the date. See MOS Note:2061926.1 for details.


  • Before: Oracle Database 12c PSU October 2015 ...
  • Now: Oracle Database 12c PSU January 2016 ... 

More Information? 


Thursday Oct 22, 2015

PSU (and CPU/SPU) October 2015 got released

October 21, 2015 - Oracle released the October 2015 SPU/CPU, PSU and BPs. 


For Oracle Database and Oracle Grid Infrastructure access the PSUs from here - if you have only a single instance database you can safely take the Combo patch as you'll get downtime anyways - but for customers running RAC you need to evaluate the OJVM component as this will incur downtime which the database-only patch does not require as it can be applied rolling.

Patch Set Updates

Document Description Rolling RAC Patch Download
Note:21555660.8 Oracle JavaVM Component Database PSU (Oct 2015) (OJVM PSU) No Patch:21555660
Note:21520444.8 Combo of OJVM PSU and DB PSU (Oct 2015) Part Patch:21520444

No patch found at the moment [Mike]
Note:21359755.8 (Oct 2015) Database Patch Set Update (DB PSU) Yes Patch:21359755

Grid Infrastructure

Document Description Rolling RAC Patch Download
Note:21523260.8 Combo of OJVM PSU and GI PSU (Oct 2015) Part Patch:21523260
Note:21523234.8 (Oct 2015) Grid Infrastructure Patch Set Update (GI PSU) Yes Patch:21523234

And be aware to patch your DBaaS Cloud databases as well - this is not done automatically ;-)



Monday Aug 17, 2015

DBCA 12c and "" - things to know

A few weeks ago I did blog about the DBUA (Database Upgrade Assistant) not executing 'datapatch' (i.e. not applying the SQL changes involved with a SPU/PSU/BP) automatically:

Again, please note that this behavior DOES NOT APPLY to command line upgrades done with - as you can see from this somewhat disturbing messages during the upgrade in phase 65 and phase 69 (which are not errors but just informational messages for datapatch's execution):

Datapatch phases command line upgrade

But afterwards I have learned that things are worse.
The same behavior is true when you create a database.

Not a typo.
You create a fresh database with DBCA (Database Configuration Assistant), you are a honest customer, you have followed our advice and applied the most recent PSU (or SPU or BP) into your Oracle Home. You don't even deploy one of the preconfigured databases but use the CREATE CUSTOM DATABASE option of DBCA. And the database will run from the patched home - but the SQL changes haven't been applied to it


DBCA does not call 'datapatch' for database changes.

I consider this even worse than the DBUA behavior as the person who upgrades a database in most cases is aware of the future home. But the person who either deploys a new database or asks for one to be deployed is often not identical with the person who did patch the homes.

And there's no warning displayed yet nor (afaik) is there a MOS note available talking about it.

How do you fix the issue?

After creating a new database make sure to run:

./datapatch -verbose

and double check with DBA_REGISTRY_SQLPATCH view:


Actually to be 100% you may find some patch information in DBA_REGISTRY_SQLPATCH showing that the JAVAVM patch has been applied in case you've installed the Combo version of the PSU. But you'll miss the database changes.

Related Blog Posts


Addition - Sept 18, 2015:

Please be aware that the same thing happens on ODA (Oracle Database Appliance) with the oakcli. This will be fixed in the version (ODA/oakcli)

Monday Mar 09, 2015

Applying a PSU or BP to a Single-/Multitenant Environment

I have already explained in broad details a while ago how to:

But one may miss the steps for applying a PSU (Patch Set Update) or BP (Bundled Patch) to a Single-/Multitenant Environment. At first everything will work just the same if you choose the Everything-at-Once strategy as datapatch will adjust all the required things regardless of being executed in a stand-alone or a singe/Multitenant environment.

But what happens if you apply a PSU or a BP to one of your Multitenant environments and want to move PDBs one after another (or a few at the same time) to the new environment?
Or revert a PSU by plugging out from a CDB with the PSU inside - and plug it back into a CDB with a lower version or no PSU at all? 

First step - Check Plug In Compatibility 

Before you can even start your unplug/plug operation you should always perform the plugin check. This is divided in two simple steps:

  1. Create the XML description file for your PDB in CDB_SOURCE
    exec DBMS_PDB.DESCRIBE ('/home/oracle/PDB1_unplug.xml', 'PDB1');
  2. Run the plug in check in CDB_DEST
      if DBMS_PDB.CHECK_PLUG_COMPATIBILITY('/home/oracle/PDB1_unplug.xml','PDB1') then  
      DBMS_OUTPUT.PUT_LINE('No violations found - you can relax');
      DBMS_OUTPUT.PUT_LINE('Violations found - check PDB_PLUG_IN_VIOLATIONS');
    end if;

No Plugin Violations?

Then please follow the procedure described in:
without the upgrade part as you don't need to upgrade anything in this case of course. 

Higher patch in CDB_DEST than in CDB_SOURCE?

Then run this query:


It will tell you to execute datapatch:

------  ----------------------------------------------------------------------------
ERROR   PSU bundle patch 1 (PSU Patch 4711): Installed in the CDB but not in the PDB

Call datapatch to install in the PDB or the CDB

Lower patch in CDB_DEST than in CDB_SOURCE?

Now this becomes a bit more tricky. See the output of PDB_PLUG_IN_VIOLATIONS:

----- ----------------------------------------------------------------------------
ERROR PSU bundle patch 1 (PSU Patch 4711): Installed in the PDB but not in the CDB

Call datapatch to install in the PDB or the CDB

Huh? Install???
What does this mean? Should I install now the current CDB/PDB's PSU into my target environment before being able to step down? 

Actually I think this message is misleading. And when you look into the MyOracle Support Note describing this under scenario 3 (MOS Note:1935365.1 - Multitenant Unplug/Plug Best Practices) you'll see that the author silently assumed as well that is is more likely that you'll remove the patch from the PDB. 

But how do you remove changes which came in with datapatch from within a PDB only?

You will need to run datapatch -rollback on the affected PDBs only:

$> datapatch -rollback <patch id> –force [–bundle_series] -pdbs <pdb1,pdb2,...,pdbn>

For further information see:



Mike Dietrich - Oracle Mike Dietrich
Master Product Manager - Database Upgrade & Migrations - Oracle

Based in Germany. Interlink between customers/partners and the Upgrade Development. Running workshops between Arctic and Antartica. Assisting customers in their reference projects onsite and remotely. Connect via:

- -


« February 2017
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Viewlets and Videos
Workshop Map
x Oracle related Tech Blogs
This week on my Rega & Pono
Upgrade Reference Papers