Bye Bye Flash!

Formerly named Macromedia Flash (now Adobe Flash) player was really popular in the 2000’s. I remember learning it to add animation to Web Sites I was developing during my college years. Flash has also been the target of hackers to insert viruses, hence posing several security concerns to enterprises and home users.

In the IT world, change is the only constant. So, is time to move on to the next thing.

Adobe Flash is widely used in several Oracle sites. My Oracle Support, Oracle Business Intelligence EE, Oracle Enterprise Manager Cloud Control, etc.
Google just announced that it will stop supporting Flash in Google Chrome at the end of 2020.

https://blog.google/products/chrome/saying-goodbye-flash-chrome/

That means that you will loose all those fancy graphs in your browser. Well, not quite. Oracle started to provide patches and upgrades to get rid of Adobe Flash and use JET instead.

We still have more than a year for this to happen, but is the perfect time to start planning to switch. Is this already in your plans?

Thanks,
Alfredo

Oracle Enterprise Manager 13.3 problems discovering Exadata targets

If you are on the latest Exadata plugin for EM 13.3 (well, even the 13.2 version of the plugin). Be aware that there’s a bug where if the Exadata nodes’ names are longer than 7 characters, you cannot discover them.

EM just throws a weird error with below legend:

SEVERE: makeTargetsXml for each rack#: 1 e=java.lang.StringIndexOutOfBoundsException: String index out of range: -1 

The solution is to apply the latest (March 2019) Bundle Patch to the agents running on the Exadata’s compute nodes.

More info on below MOS note:  

Exadata Discovery Fails With “No New Component Is Discovered. Click Cancel” (Doc ID 2477624.1)  

Another good excuse to keep your EM system up to date.  

Happy patching.  

Thanks,
Alfredo

OEM 12c Agent Crashing on Solaris

I recently had an issue with an OEM agent 12.1.0.4 version running on Solaris. Looks like there’s a Java related bug which causes the agent to consume high amounts of CPU in the box. But the interesting part is this only happens when Listeners are being monitored. If you blackout the Listener targets this stops.
If this’s the case then you are hitting Bug 15953286.
The solution is comprised by various steps outlined on MOS “EM 12c: Enterprise Manager 12c Cloud Control Agent CPU Spiking and High Utilization on Solaris with Many Database and Listener Targets (Doc ID 1536871.1)”.
Thanks,
Alfredo

OEM 13c and Amazon’s RDS

Amazon released a note late last year about Amazon’s RDS is now supporting Oracle Enterprise Manager Agents.
Amazon RDS supports agent version 12 (12.1.0.5), 13R1 and 13R2 (13.2.0.0).
You can use this to monitor your DB instances running on Amazon’s RDB but there are some limitations, like the fact you cannot execute jobs against those targets.
See below for more information about this.
Thanks,
Alfredo

Enable NFS mount point monitoring in OEM 13c

OEM doesn’t monitor NFS mount points by default. In case you need to monitor NFS mount points you have 2 options.
Either create a metric extension using an OS script or to enable a property called EM_MONITOR_ALL_DISKS in the agent’s configuration file.
There are two ways to accomplish the second option. You can go and modify the emd.properties file or you can use the OEM console to modify it.
The OEM console can submit a job called “Agents Configuration Operation”. This job is going to prompt you for a name and the agents you want to modify the property. The Parameters tab has all the available parameters to modify. Just set the EM_MONITOR_ALL_DISKS to true and submit the job.

If you want to modify this manually. Just follow the instruction in the MOS note 1513537.1.
Thanks,
Alfredo

Exclusion not working in OEM 13c Rule Sets

While setting up Rules and RuleSets you may want to exclude either target types or alert categories from your notifications. Well, there’s an issue if you try to do this in OEM 13c.
If you configure a Rule that has the exclusion and contains more than one category, then you will keep receiving alerts from it. So the exclusion won’t work.
In order to fix it you need to apply a patch or the January 2018 BP for OEM.
MOS note (Doc ID 2347238.1) shall be used as a reference.
Thanks,
Alfredo

“Failed to find the OPatch patch directory” while applying patch 25105555 ( 13.2.0.0.161231) from OEM console

While applying patch 25105555 ( 13.2.0.0.161231) to an agent using the “provisioning and Patching” console from OEM 13.2 and choosing the “Upgrade OPatch” option, got this error:
———- Error Message ———-
Error: 010
Failed to find the OPatch patch directory “/tmp/p6880880_600000000057471_2000_0/oracle/OPatch”.
If you chose “No” for the “StagePatches” option, ensure that you manually place the patch at the required location and retry the operation.
———– End Message ———–
Tue Aug 27 15:41:48 2017 – Patching aborted.
You have to follow the solution section from below MOS note:
EM 13c: Applying EM-AGENT Bundle Patch 25105555 ( 13.2.0.0.161231) from Enterprise
Manager 13.2 Cloud Control Fails with Message: Error: 010 Failed to find the OPatch patch directory (Doc ID 2229452.1)
It depends on whether you have an online or offline OMS configuration.
After doing this I was able to apply patch 25105555 to the agent.
Hope this helps.

Alfredo

2017 April PSU – OEM sending tablespace related alerts every collection schedule

I noticed that several alerts related to tablespace full were sent from OEM every collection schedule. At first sight I thought this may be related to OEM itself but after spending some significant time in MOS found a bug note stating that the 2017 April PSU patch was responsible.



The issue is that dba_tablespace_usage_metrics is not accounting for autoextend datafiles. So even if you add a new datafile, your used space will continue be reported as it was before.
You need to apply patch 26198757 on top of April PSU.
Hope this help you to avoid all this noise and happy patching.
Thanks,

Alfredo

OMS responded illegally [ERROR- Failed to Update Target Type Metadata] in 13c R2

I want to discuss about this OMS error coming from the agent’s heartbeat status. The agent shows with an unreachable status but is actually up and running.
$: emctl status agent
Oracle Enterprise Manager Cloud Control 13c Release 2
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
—————————————————————
Agent Version          : 13.2.0.0.0
OMS Version            : (unknown)
Last Reload            : (none)
Last successful upload                       : (none)
Last attempted upload                        : (none)
Total Megabytes of XML files uploaded so far : 0
Number of XML files pending upload           : 2,210
Size of XML files pending upload(MB)         : 2.89
Available disk space on upload filesystem    : 56.39%
Collection Status                            : Collections enabled
Heartbeat Status       : OMS responded illegally [ERROR- Failed to Update Target Type Metadata]
Last attempted heartbeat to OMS              : 2017-01-24 21:09:21
Last successful heartbeat to OMS             : (none)
Next scheduled heartbeat to OMS              : 2017-01-24 21:09:51
—————————————————————
Agent is Running and Ready
In this case the agent is not able to upload the metadata because is different in the OMS.
This is mainly due to a patch in the agent side that is missing in the OMS. By mistake I applied the latest bundle patch to the agent before applying it to the OMS.
Just another proof that any patches have to be installed to the OMS first then the agents.
Thanks,

Alfredo