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

Oracle 19c Available for Exadata On-Premises

Oracle just released Oracle 19c for Exadata On-Premises. This is just close to a year when they released the 18c version for Exadata On-Premises on February 16th 2018.

If they follow the same schedule, we may expect 19c for the Database Cloud Service early next month.
Release dates can be found in the MOS Doc Id 742060.1
I did check the versions available in the Oracle Cloud for VM, Bare Metal and Exadata.
No 19c version as expected.

Now is time to start playing with the new features of 19c. Stay tuned!
Thanks,
Alfredo

Exadata/Exacloud CellServer health using AWR report

Exadata’s unique sauce relies on the fact that the DB instance can offload work to the CellServers to speed up I/O bound queries. But how do you monitor the health of the CellServers?
A quick and dirty way, especially if you don’t have access to the CellServers is to use AWR in a database that’s currently using those CellServers. Let’s get an AWR report and search for the SMART IO section. It should look like this.

What you want to see here is that % Total MB Requested is evenly distributed across all Cells. The same applies for Storage Index and Flash Cache metrics.
Now this is the interesting part. If you happen to see the Offload % Efficiency dropping for one of the cells, that means that the Cell is sending the complete blocks back to the DB and then the % Passthru metric is going to increase.
You don’t really want the % Passthru to increase as this will have a direct performance is the DBs being served by this Cell.
What are the reasons of this Passthru increasing?
There are 3 reasons for Passthru.
The first one is due to an issue with the Cell itself. The second one is due to issues with DST patches and the third one is related to user queries crashing the Cell.
You should look at the below MOS note in order to gather all the required information and open an SR immediately after you see this behavior.
SRDC – Exadata: Smart Scan Not Working Issues (Doc ID 2310422.1)
Thanks,
Alfredo