Patching to Oracle 18.2.0 in the Oracle Cloud (OCI Classic)

I was quite surprised when I spotted the Update (RU) Oracle 18.2.0 mid of April in my OCI Classic (DBCS, DBaaS) account. Of course I was thrilled immediately and started the patching to Oracle 18.2.0 in the Oracle Cloud (OCI Classic).

Patching to Oracle 18.2.0 in the Oracle Cloud (OCI Classic)

The April 2018 Updates (and Bundle Patches and Patch Set Updates for Oracle releases below 12.2) got released on April 17, 2018. You can read more here on how I applied all of them to my Oracle 11.2.0.4, 12.1.0.2 and 12.2.0.1 databases. But I was positively surprised when I spotted also Oracle 18.2.0 in my cloud deployment the same day.

Oracle 18.2.0 Update (not PSU!) is available in the Oracle OCI Classic Cloud

The only thing which struck me at first: There is for sure no PSU for Oracle 18c available. PSUs don’t exist luckily anymore since Oracle Database 12.2.0.1. I’d consider this a typo. And it says “Update” – which is correct.

Attempt 1 – Failed!

You know, I’m naive. Quite a bit at least. I just clicked the “stack” icon and chose “Precheck“.

Cool! It doesn’t tell me why it has failed. My first assumption: Maybe a patch conflict?

I tried to drill down to the logfiles – and this wasn’t helpful either. Even when I tried to apply the patch it failed. To me it looked as the patch wasn’t stored on my deployment or I don’t have a connection to the patch stage location:

2018-04-24 15:15:47 - INFO: space available is 45.9460220336914 GB
2018-04-24 15:15:47 - INFO : prereq_check : Entered non ASYNC case. psu_zip_loc does not exist. Downloading it

Lesson 1 learned: Don’t try to patch when the precheck failed!

Good that I have skilled colleagues – I asked them for guidance. My friend Robert Pastijn, the guy in Oracle I know with the most practical database+cloud experience, mentioned that I should update my cloud tools first but had no online connection to send me the link to his notes.

No problem: I’m old enough and can read documentation. Or search on MOS. And Bingo! I found MOS Note: 2350471.1 – How to upgrade DBAAS Cloud Tooling using dbaascli.

In brief – it’s important to connect with the opc user, not the oracle user:

ssh -i ./myOracleCloudKey opc@123.123.123.123

sudo -s

Then check the version of the cloud tools:

rpm -qa|grep -i dbaastools

In my case it gave: dbaastools-1.0-1+18.1.4.1.0_180420.0000.x86_64
But when I used dbaascli dbpatchm to update my tools to the newest version I was surprised as it hit an error after seconds – and then seemed to hang.

dbaascli dbpatchm --run -toolsinst 18.1.4.1.0_180425.0000

"Use of uninitialized value in concatenation (.) or string at /var/opt/oracle/patch/dbpatchm line 4737."

Well, this doesn’t look good. I mailed Robert again and I could see him smiling via email 😉 He hit the same error and knew already that I had to be patient for 10-15 minutes. I’m not patient. Especially not when it comes to patching. I did CTRL+C and my cloud tools where in an unknown state.

Bravo!

Attempt 2 – Success!

Of course I don’t write this blog post to blame anybody. As usual I write for myself as a reminder – and of course for you so that others can avoid this trap.

Gowri, a colleague from the US, had the right steps for me to solve my situation.

ssh -i ./myOracleCloudKey opc@123.123.123.123

sudo -s

rpm -qa|grep dbaastools

/var/opt/oracle/patch/dbpatchmsm -toolsinst_async 18.1.4.1.0_180425.0000

Then I had to wait 10-15 minutes – the process went into the background. And magically I could proceed afterwards.

Lesson 2 learned: Always upgrade the cloud tooling first

Once I checked on the command line with:

rpm -qa|grep -i dbaastools

the correct version got returned (18.1.4.1.0_180425.0000).

Lesson 3 learned: Be patient and ignore PERL errors and just trust …

Well,I confess: Patience is not my biggest strength.

Afterwards I went back to the GUI and tried the precheck first:

That’s good.

So finally I tried to apply Oracle 18.2.0 to my cloud environment. Do it!

And Hurray!!! The environment got patched successfully.

Never trust a stranger … ah … GUI!

Ok, besides not being patient in many cases, I don’t trust GUIs 😉 Hence I had to double check on the command line.

SQL> set serveroutput on
SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 27676517
    Action : APPLY
    Action Time : 27-APR-2018 07:23:27
    Description : Database Release Update : 18.2.0.0.180417 (27676517)
    Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/27676517/22097537/27676517_apply_MIKECDB
ROOT_2018Apr27_07_23_27.log
    Status : SUCCESS

Patch Id : 27636900
    Action : APPLY
    Action Time : 27-APR-2018 07:23:27
    Description : OJVM RELEASE UPDATE: 18.2.0.0.180417 (27636900)
    Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/27636900/22065563/27636900_apply_MIKECDB
ROOT_2018Apr27_07_23_27.log
    Status : SUCCESS

PL/SQL procedure successfully completed.

And in addition I used a patch query to check if not only the patches had been applied physically but also if datapatch had been executed successfully as well:

alter system set "_exclude_seed_cdb_view"=false scope=both;  

select patch_id, patch_type, action, status,con_id from cdb_registry_sqlpatch order by con_id, action_time;

  PATCH_ID PATCH_TYPE ACTION	      STATUS			    CON_ID
---------- ---------- --------------- ------------------------- ----------
  27676517 RU	      APPLY	      SUCCESS				 1
  27636900 INTERIM    APPLY	      SUCCESS				 1
  27676517 RU	      APPLY	      SUCCESS				 2
  27636900 INTERIM    APPLY	      SUCCESS				 2
  27676517 RU	      APPLY	      SUCCESS				 4
  27636900 INTERIM    APPLY	      SUCCESS				 4
  27676517 RU	      APPLY	      SUCCESS				 6
  27636900 INTERIM    APPLY	      SUCCESS				 6

Done!

Finally I realized that my cloud instance does not give any indication from the GUI that I patched it. I know, I’m picky. But I’m a database guy. And I think it would be beneficial if the GUI dashboard would tell me the patch level of my database environment straight ahead.

Version display still says 18.0.0 even though my database is an 18.2.0 now

–Mike