Oracle Enterprise Manager (OEM) Patching

Be forewarned - patching OEM has changed!

I assume you are reading this because it has become necessary to patch your installation of the product now known as "Cloud Control".  Past iterations of this product were called:

Oracle Enterprise Manager (OEM)
Oracle Monitoring System (OMS)
Oracle Grid Control (GC)

In fact, many of the commands in the software stack for this product still have these legacy names, and many of the documents associated with installation, administration, maintenance and use of OEM still use these names/acronyms. 

If you are about to patch, keep in mind, very similar to standard Oracle database software, that a utility named "opatch" will be used.  It comes with the software stack (still called "oms"), and is located in the standard location: $ORACLE_HOME/Opatch (which indicates the home directory for the product + the location of the "opatch" utility.  However, there is another patching utility, specifically for the OMS, called OMSPatcher, which is used as well. 

As of this writing, the proper document to be followed for applying the April 2020 OMS "PSU" patch are at the Oracle Support site (support.oracle.com).  It is also assumed you have access to support and a valid product license.  Please reference:

Patch 31058360: enterprise manager for oms plugins 13.3.1.0.200331

If your OMSPatcher software is out of date, you will have to update it by following procedures documented for patch 19999993 OMSPatcher v13.9.3.

This patch is applied the traditional way.   Move the patch bundle zip to $ORACLE_HOME/OMSpatch and then unzip it into the same directory (after backing up first).   Patching Opatch (when required) is where it gets interesting!  THE OMS MUST NOW BE DOWN TO PATCH OPATCH! We may no longer use the standard method.  You must now unzip the patch, and then invoke java (assuring the correct version is in your path, or calling the version imbedded in your Oracle home):

- If needed, install the software with custom inventory via:

java -jar /6880880/opatch_generic.jar -silent oracle_home=$ORACLE_HOME -invPtrLoc $YOUR_INVENTORY where inventory pointer location is the absolute path to the oraInst.loc file  In my next post, I will detail patching specifics, including the necessary steps  of backing up the OMS software and running a "prechceck".

Unpublished Syntax for Oracle "dbaas_diag_tool.pl" Script For Diagnostic Collection

Oracle cloud presents a lot of new tooling and scripts, with enhancements and refinements occurring almost daily.  I recently had to work a support request (SR) and was asked by the Oracle support engineer to do an environment collection using a tool called dbaas-diag-tool.  This tool is actually a perl script and will be located here on Oracle provisioned exa-Cloud linux servers:

/var/opt/oracle/misc/dbaas_diag_tool.pl

There was an Exadata compute node which rebooted during a patching event.  So we opened a support request for direction, as the patch failed.  The request from support was to run the tool and collect diagnostic information from a "four hour window around the event".  However, the syntax supplied only includes syntax for days of collection, not hourly.  So I tried to collect syntax documentation from various sources, without much info.  Here is what a syntax help request returns:

# /var/opt/oracle/misc/dbaas_diag_tool.pl --help
Usage: perl /var/opt/oracle/misc/dbaas_diag_tool.pl \
            [-help|-h|-?] [--envtype ] [--dbname ] [--operation collect] [--gettfalogs ] [--getdbaaslogsonly ]  [ --diagdir
 Example:
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl -h
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --envtype DBCS
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --healthcheck
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --envtype DBCS --operation collect
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --starttime YYYY-MM-DD
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --starttime YYYY-MM-DD --endtime YYYY-MM-DD
         perl /var/opt/oracle/misc/dbaas_diag_tool.pl --getdbaaslogsonly True|False
Note: Currently tool only supports envtype and operation
Note: TFA Logs are collected only if getTFALogs is set to True. By default it is False
Note: dbname is relevant only for envtype and ignored in other environments


Note that the syntax specifies "starttime" and "endtime" but does not give the format for time in hours, minutes or seconds?  Even the request from the engineer did not include the syntax for such granularity.  Left to ponder this, after trying help, above, I referenced various support documents, without success.  
Doc ID 2219712.1 seemed promising, but only contained information for collecting "TFA logs".  Another document (Doc ID 2094679.1)  seemed promising, but also did not include the needed syntax.   I even reviewed the perl script itself, however, it makes many calls to unpublished subroutines, so I didn't get anywhere.  

However, I did notice that the output log file from the process includes the date, in the same format, with an underscore and colon between each value, so I tried that.  Alas, no luck.  However, within the code was the following one-line hint:

 my ($date_out, $date_err) = $LOG->logexe("date \+\'\%Y\-\%m\-\%d \%H\-\%M\-\%S\'");

This syntax is what will work.  Notice double-quote delimiters are required around starttime and endtime because a space must be imbedded between day and hour:

/var/opt/oracle/misc/dbaas_diag_tool.pl --starttime "2020-04-18 10:00:00" --endtime "2020-04-18 14:00:00"

So, in the end, Oracle should probably update their documentation to include this syntax.  I hope this will help if you need to run this useful utility.