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

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.

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

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

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

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:

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

That’s good.

So finally I tried to apply Oracle 18.2.0 to my cloud environment. Do it!Patching to Oracle 18.2.0 in the Oracle Cloud (OCI Classic)

And Hurray!!! The environment got patched successfully.

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

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.

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

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

–Mike

 

8 thoughts on “Patching to Oracle 18.2.0 in the Oracle Cloud (OCI Classic)

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

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

      • 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

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

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.