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 12.1.0.2 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 12.1.0.2.161018
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 12.1.0.2.161018 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 12.1.0.2.161018 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 12.1.0.2.160719 (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.

--Mike
.

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 - 12.1.0.2 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 12.1.0.2.161018 Database Proactive Bundle Patch (Oct 2016) Yes Patch:24448103
Note:24436306.8 Combo of 12.1.0.2.161018 OJVM PSU and 12.1.0.2.161018 DBBP (Oct 2016) Part Patch:24436306
Note:24433133.8 Combo of 12.1.0.2.161018 OJVM PSU and 12.1.0.2.161018 DB PSU (Oct 2016) Part Patch:24433133
Note:24315824.8 Oracle JavaVM Component 12.1.0.2.161018 Database PSU (Oct 2016) (OJVM PSU) No Patch:24315824
Note:24006101.8 12.1.0.2.161018 (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
DB BP
GI PSU
OJVM
Note:24448103.8 12.1.0.2.161018 Database Proactive Bundle Patch (Oct 2016) Yes Patch:24448103
X
X

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

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


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


X
Note:24006101.8 12.1.0.2.161018 (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:

--Mike

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 12.1.0.2 and the PSU to my 11.2.0.4 environment.

.

--Mike

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 ...

--Mike
.

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.

--Mike

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:

Question: 
We are planning to upgrade from 12.1.0.2.1 to 12.1.0.2.5.
The plan is to create new 12.1.0.2.5 oracle home and
gradually moving PDB from 12.1.0.2.1 to 12.1.0.2.5.
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: 

--Mike

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 - 12.1.0.2 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 :-)

--Mike

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 12.1.0.2.0
      .

Further Information?

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

 --Mike
.

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 12.1.0.2 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 12.1.0.1.10
Copyright (c) 2016, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/12.1.0.2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0.2/oraInst.loc
OPatch version    : 12.1.0.1.10
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2016-05-03_10-26-37AM_1.log

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/12.1.0.2/cfgtoollogs/opatch/opatch2016-05-03_10-26-37AM_1.log

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 12.1.0.1.10
Copyright (c) 2016, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/12.1.0.2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0.2/oraInst.loc
OPatch version    : 12.1.0.1.10
OUI version       : 12.1.0.2.0

Log file location : /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/21359755_May_03_2016_10_41_54/rollback2016-05-03_10-41-54AM_1.log

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/12.1.0.2')

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

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

[..]

RollbackSession removing interim patch '19769480' from inventory Log file location: /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/21359755_May_03_2016_10_41_54/rollback2016-05-03_10-41-54AM_1.log OPatch succeeded.

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)
https://blogs.oracle.com/UPGRADE/entry/oracle_database_bp_april16_applied

I continued this blog post on a later occasion here:

Further Information?

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

--Mike

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 12.1.0.2.0) 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 8.1.7.4 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.
.

--Mike

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 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 
.


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 12.1.0.2.PSU6 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.

But:
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 12.1.0.2.3, Oracle JavaVM Component (Apr2015)
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/20415564/18617752/
                  20415564_apply_ORCL_CDBRO
OT_2015Jun24_06_18_09.log
        Status : SUCCESS

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

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

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

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

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

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

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

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

Patch Id : 21962590
        Action : APPLY
        Action Time : 27-JAN-2016 17:43:18
        Description :
        Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/21962590/19426224/
                  21962590_apply_MIKEDB_CDB
ROOT_2016Jan27_17_42_21.log
        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
Inventory    
    : 
/u01/app/oraInventory


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):
                                    12.1.0.2.0
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. 

.

--Mike 

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 support.oracle.com.

Oracle Critical Patch Update Advisory - January 2016

http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html 

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 12.1.0.2.5 before (or I used to call it 12.1.0.2.PSU5 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.

Example:

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

More Information? 

--Mike

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. 

See:

For Oracle Database 12.1.0.2 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 12.1.0.2.5 Database PSU (Oct 2015) (OJVM PSU) No Patch:21555660
Note:21520444.8 Combo of 12.1.0.2.5 OJVM PSU and 12.1.0.2.5 DB PSU (Oct 2015) Part Patch:21520444

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

Grid Infrastructure

Document Description Rolling RAC Patch Download
Note:21523260.8 Combo of 12.1.0.2.5 OJVM PSU and 12.1.0.2.5 GI PSU (Oct 2015) Part Patch:21523260
Note:21523234.8 12.1.0.2.5 (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 ;-)

--Mike

.

Monday Aug 17, 2015

DBCA 12c and "datapatch.pl" - 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 catctl.pl - 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 catctl.pl

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

Reason?

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:

cd $ORACLE_HOME/OPatch
./datapatch -verbose

and double check with DBA_REGISTRY_SQLPATCH view:

select  PATCH_ID, PATCH_UID, VERSION, STATUS, DESCRIPTION
from DBA_REGISTRY_SQLPATCH
order by BUNDLE_SERIES;

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 datapatch.pl:

--Mike


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 12.1.2.5 (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
    begin
      if DBMS_PDB.CHECK_PLUG_COMPATIBILITY('/home/oracle/PDB1_unplug.xml','PDB1') then  
      DBMS_OUTPUT.PUT_LINE('No violations found - you can relax');
    else
      DBMS_OUTPUT.PUT_LINE('Violations found - check PDB_PLUG_IN_VIOLATIONS');
    end if;
    end;
    /

No Plugin Violations?

Then please follow the procedure described in:
http://blogs.oracle.com/UPGRADE/entry/upgrade_pdbs_one_at_a
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:

select TYPE,MESSAGE,ACTION from PDB_PLUG_IN_VIOLATIONS where NAME='PDB1';

It will tell you to execute datapatch:

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

ACTION
------------------------------------------------
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:

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

ACTION
------------------------------------------------
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 

About

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:

- -

Search

Archives
« January 2017
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Workshops
Viewlets and Videos
Workshop Map
x Oracle related Tech Blogs
This week on my Rega & Pono
Upgrade Reference Papers