Oracle October 2015 CPU – quick and dirty install on 11.2.0.4 and 12.1.0.2 4


[Update 17.11.2015 – Thanks Lars Johan Ulveseth for the extra testing and comment – see below. In fact I’ve only tested the PSU installation on a non-CDB 12c database. There is a missing step, added now, when you are in a multitenant configuration with pluggable databases. Script updated based on Lars comments.]

Following my January post, here are basic instructions to install the latest Oracle security patch. While one should always read the documentation, below you can find how to install CPU Oct 2015  on single instance. Please count about 5 minutes downtime on your database (a bit more if it is the first time you are doing this).

If you are single instance database (no RAC) and either 11.2.0.4 or 12.1.0.2 here are the quick summary of the installation. Tested on Linux and AIX:

Oracle 12.1.0.2 – October 2015 CPU installation

OPatch: You need to update the OPatch tool, minimum version is 12.1.0.1.7. Direct download from Oracle support.

Bundle 12.1.0.2 – Patch 21520444 – Combo OJVM PSU 12.1.0.2.5 and Database PSU 12.1.0.2.5 for UNIX

  • Patch 21359755 – Database Patch Set Update 12.1.0.2.5 (Oct2015) –> RAC-Rolling Installable
  • Patch 21555660 – Oracle JavaVM Component 12.1.0.2.5 Database PSU (OCT2015) –> Non RAC-Rolling Installable
export PATCH_LOC="/tmp"

1. Download + Upgrade OPatch (Opatch download direct link)

unzip ${PATCH_LOC}/p6880880_121010_Linux-x86-64.zip -d $ORACLE_HOME

2. Stop database+listeners+agent

3. Apply DB PSU (21359755 ) but do NOT run DB PSU post install steps

cd ${PATCH_LOC}
unzip p2*
cd 2*
cd 21359755/
$ORACLE_HOME/OPatch/opatch apply

3. Apply OJVM PSU patch

cd ../21555660/
$ORACLE_HOME/OPatch/opatch apply

4. Restart database [and open pluggable databases] in upgrade mode

SQL> startup upgrade;
SQL> alter pluggable database all open upgrade;

5. Run post install steps

cd $ORACLE_HOME/OPatch
./datapatch -verbose

6. Restart database [and open pluggable databases] in normal mode

SQL> shutdown;
SQL> startup;
SQL> alter pluggable database all open;


Oracle 11.2.0.4 – October 2015 CPU installation

Bundle 11.2.0.4 – Patch 21744335 – Combo OJVM PSU 11.2.0.4.5 and Database SPU 11.2.0.4 (CPUOct2015)

  • Patch 21352646 – Database Security Patch Update 11.2.0.4.0 (CPUOCT2015) –> RAC-Rolling Installable
  • Patch 21555791 – Oracle JavaVM Component 11.2.0.4.5 Database PSU (OCT2015) –> Non RAC-Rolling Installable
export PATCH_LOC="/tmp"
cd ${PATCH_LOC}
unzip p2*.zip
cd 2*

1. Shutdown databases and services
2. Apply DB PSU (21352646) but do NOT run DB PSU post install steps

cd 21352646
$ORACLE_HOME/OPatch/opatch napply -skip_subset -skip_duplicate

3. Apply OJVM PSU patch

cd ../21555791/
$ORACLE_HOME/OPatch/opatch apply

4. Run the OJVM PSU post install steps followed by the DB PSU (or equivalent) post install steps.

cd $ORACLE_HOME/sqlpatch/21555791
sqlplus / as sysdba 
SQL> startup upgrade
SQL> @postinstall.sql
SQL> shutdown immediate
SQL> exit;
cd $ORACLE_HOME/rdbms/admin
$ sqlplus / as sysdba
SQL> startup
SQL> @catbundle.sql cpu apply
SQL> @utlrp.sql
SQL> exit;

 


Leave a comment

Your email address will not be published.

4 thoughts on “Oracle October 2015 CPU – quick and dirty install on 11.2.0.4 and 12.1.0.2

  • Lars Johan Ulveseth

    Are you sure this quick and dirty install does the job?
    I have not tested your procedure for 11.2.0.4, but I have tested the procedure for 12.1.0.2.

    You are rigth that one can postpone the DB PSU post install steps until the JavaVM Component is applied.
    But the database has to be opened in UPGRADE mode, and the PDB’s has to be opened in UPGRADE mode.
    (You will find this described in the README.html for patch 21555660)

    If you examine the output from your step 5, I think you will find this:
    “…
    Error: prereq checks failed!
    patch 21555660: The pluggable databases that need to be patched must be in upgrade mode
    Prereq check failed, exiting without installing any patches.
    …”

    “SELECT * FROM sys.dba_registry_sqlpatch WHERE patch_id IN (‘21555660’, ‘21359755’);” will NOT show the two patches as installed.

    The correct procedure for step 4 is to start the database with: startup upgrade
    And then execute this for the PDB’s:
    alter pluggable database all close immediate;
    alter pluggable database all open upgrade;

    The output from step 5 will then show:
    “…
    Installing patches…
    Patch installation complete. Total patches installed: 6
    …”
    And “SELECT * FROM sys.dba_registry_sqlpatch WHERE patch_id IN (‘21555660’, ‘21359755’);” will return two rows.

    After this, restart the database in normal mode.

    Regards from Lars Johan Ulveseth

    • anjo Post author

      Hi Lars,

      I’m fully aware of the Oracle sentence. But that is not linked to the subjet of this post. Even though the non-CDB architecture is marked as deprecated, it will continue to exist normally even on Oracle 12.2. That represents at least the next 5 years. Looking at the existing limitations, bugs and overhead of the CDB architecture, I still recommend most of my clients to keep a non-CDB architecture (at least for production environments), unless there are specific advantages of migrating to a CDB architecture.

      Cheers,
      Miguel Anjo

      • Lars Johan Ulveseth

        Hi Miguel.

        I know my last comment was off topic, I didn’t mean to hijack the post. 🙂

        Since this blog-entry may have a lot of hits and you tested on a non-CDB, I wanted to inform any readers about non-CDB beeing depricated.
        And I agree with you, that for a lot of people, the non-CDB solution still can be the best/only choice.

        Best regards from Lars Johan.