ODC Appreciation Day : Upgrading DBaaS tools in Cloud Database Instances

As part of Tim Hall’s ODC Appreciation Day I’ve been spurred into action… finally tidying up and publishing this DBaaS post!

A key component for most Oracle PaaS cloud environments is Database as a Service (DBaaS). I’ve been Level 3 support behind some Oracle Cloud PaaS systems now for well over 2 years (quite a long time in “cloud years”!), and I think it’s fair to say we’ve raised a few SRs for our DBaaS instances, particularly in the early days. Our issues have mostly been around backup failures, updating storage passwords (in the various places they are held) and patching, but we’ve also had errors in DB Backup Cloud Service usage metrics.

One common theme I’ve noticed is that errors that aren’t user-inflicted usually involve the dbaastools package installed in the DBaaS cloud instances. What I think happens is that the centralised service management side of DBaaS gets updated monthly, but sooner or later, the client-side running in your DBaaS instance becomes incompatible or hits bugs.

I have also noticed that the first advice from Oracle Support for most DBaaS SRs is to upgrade dbaastools to the latest version. It seems the latest it’s always compatible with the currently running “other side” and we’ve never been asked to install a specific, older version.

Moreover, a couple of months ago Oracle has released a new feature that allows DBaaS tools to auto-update. It’s not enabled automatically (at time of writing) but I expect it soon will be.

The procedure to configure auto-update is documented here:


The only awkward step is that if you are on a version more than about 6 months’ old you’ll need to update to 18.2.3 first, before you can then get to the latest version automatically. I found a quicker way than the docs to do that:

rpm -U https://storage.us2.oraclecloud.com/v1/dbcsswlibp-usoracle29538/dbaas_patch/

Once you are on 12.2.3 or later dbaascli has a simple update command (rather than using rpm with a specific URL as you used to have to):

dbaascli patch tools apply --patchid LATEST

Then you can also enable auto-update:

dbaascli patch tools auto enable

Once enabled you’ll see a job like this in your /etc/crontab file:

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed

20 10 * * 3 root /var/opt/oracle/misc/rpmupd -execute

I don’t know where it picked the time from (I was doing this in an evening) but it can run anytime as long as it doesn’t clash with your backup time (maybe it is clever enough to check?!).

We’ve had this auto-update feature running on dev instances since 21st August and are now moving it to test instances with, I expect, production within a month. I’ve not seen any downsides to this yet, but I am expecting it will reduce the number of SRs we raise for DBaaS.

Therefore I’ve two pieces of advice for people working with Oracle databases in Cloud Ops teams:

  • Always update your dbaastools to the latest version, even when instructions, e.g. MOS Notes or the pre-check output for applying a PSU, advises a specific version.
  • Seriously consider enabling the auto-update feature for dbaastools.

I’d be happy to hear if others have had similar or different experiences though!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s