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 184.108.40.206, 220.127.116.11 and 18.104.22.168 databases. But I was positively surprised when I spotted also Oracle 18.2.0 in my cloud deployment the same day.
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 22.214.171.124. 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
ssh -i ./myOracleCloudKey firstname.lastname@example.org sudo -s
Then check the version of the cloud tools:
rpm -qa|grep -i dbaastools
In my case it gave:
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 126.96.36.199.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.
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 email@example.com sudo -s rpm -qa|grep dbaastools /var/opt/oracle/patch/dbpatchmsm -toolsinst_async 188.8.131.52.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 (
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:
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 : 184.108.40.206.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: 220.127.116.11.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
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.