I do know it has been quite some time since I published a blog here. Sorry about that. Changes in life and work do come along. I now must mention I work for a large company, and that the opinions expressed here are my own. I have been working with cloud software from various vendors for some time now, and quite recently, Oracle has begun to make their presence known in this space.
Just recently, I was asked to troubleshoot a client installation patching issue for their Oracle Cloud database. Cloud supported databases in the Oracle world are referred to as "DBAAS" or "database as a service". However, like any other database hosting installation, from time to time, patching and maintenance may be required. From a special console website, the patching menu is presented with a drop down menu, where first instances and then eligible patches are listed. It can be as simple as point and click to pre-check (verify) and then install the applicable patch.
However, what if something goes wrong? In this particular case, the point and click methodology didn't work! Using conventional methods is not generally advised, as the "dbaas" implementation of Oracle's software is somewhat customized (enhanced?) both to assure consistency as well as monitoring and metering of the service for support and to charge based upon usage.
In one particular case, a customer who had worked-around the standard patching methodology lost support, and in another, was charged an incorrect fee (much higher) due to this.
I cannot go into specific detail at this time, due to the confidential nature of the customer's business and Oracle's requirements as well. Eventually, we worked with Oracle support and received a custom rpm (unix source code) fix to make patching for dbaas functional in this specific case. There were some things we noted that once again should convince readers to tread gingerly before doing any customizations or non-standard configuration activities on a cloud system:
1) Root is a very powerful privilege. You can invoke it, but at your own peril. Oracle gives a default account of "opc" (standing for Oracle Public Cloud) from which you can sudo su to oracle or root. In this case, some permissions for grid executables were set incorrectly, quite possibly by someone with root privilege for some other valid reason.
2) Patching outside of the interface is dangerous - While more mature administrators such as myself may prefer command line because of the extra options and ability to configure and control output and logging, you are probably better off to try using standard tooling first. This was pointed out by Oracle, who, even after fixing the patching tools and running manually, had us execute via the console as well!
3) Think twice and think again - before any task, or before adding/removing any software/logs/configurations or making any changes to files like /etc/fstab /etc/hosts or /etc/oratab.
We've already had instances where valid and necessary changes to these files caused the instrumentation to fail. While I readily agree, as Oracle Cloud software matures, such small items should not do so, changing these items can cause problems which are very very difficult to solve!
This is sort of a rambling post. But I am glad to get back up on the horse again. I hope to write again soon. Have a good one! And happy patching!!!
