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
Mike,
Thanks for this blog.
Regarding version 18.0.0.0, I guess it is coming from V$VERSION.
“`sql
SQL> select banner_full from v$version;
BANNER_FULL
——————————————————————————–
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 – Production
Version 18.2.0.0.0
“`
Regards,
Ed
Hi Mike,
Thanks. I have faced same issue today,your blog helped to resolve the issue.
One question: I was watching the patch log closely while the patching process was running in the background, noticed that it downloaded the 18.2.0 SW ( 4.2GB) along with 27676517+27636900 patch ( 170MB). Is this because of the release update of 18.1.0? Considering my DB is running with 18.2.0, in July we will get 18.2.1 so during that it will be required to apply only the patch ?
Regards
Suraj.
Suraj,
what exactly did you download from which location?
From eDelivery or OTN or MyOracle Support?
Or did you observe the patching process itself downloading something in the background?
Do you have the logfile?
Cheers,
Mike
Thanks for sharing – this helped in my case and save lot of time.
Thanks for the feedback, Fayaz!
Cheers,
Mike
Hi Mike,
I have noticed that since the patch process is automated and multiple steps (i.e. pre-req check, download etc.) are being executed in background, how can we estimate the time window when the actual downtime to service will start? This is critical to know in arranging downtime from respective business units. Is there a way?
Fayyaz,
your questions makes a lot of sense. And you are fully right – at the moment the monitor does not give you any assumption about how long such an action will take.
Two things our teams are working on already:
– make patches less invasive
– display more useful information to give the information you are looking for
If you don’t mind, I will send your feedback to the appropriate people working on it.
Thanks and kind regards,
Mike
Hi Mike,
While applying patches to oracle database in oracle cloud, it is very hard to know the actual downtime window when the database will be stopped. This is crucial to know to get a downtime from critical business units while planning to promote patches to production instances. Since I am new to Oracle cloud so must be missing something – please need your clarification