Exadata Part V: Monitoring with Database Control

This posting will show how we can use Oracle Enterprise Manager Database Control to monitor an Exadata Database Machine, especially the Storage Servers (Cells). The other option would be of course to use Grid Control for that purpose, which is described here on OTN. I have prepared a small installation with only one Database Server and two Cells and Database Control already present. The creation of the Database is not different from non-Exadata Oracle Installations at all, besides that the diskgroups we use are residing on Cells.

There are no Cells known to Database Control yet. Like with Grid Control usage, we do not install an Agent on the Cell but instead access the Cell with a present Agent via ssh. In this demonstration it is the Database Control Agent from the Database server. In the Related Links section of the Database Control homepage, we have the option to add Exadata Cell Targets:

After clicking on that link, we see an overview that describes the adding process, during that we need to setup the ssh connection between Agent and Cell. This is described quite well with the OEM Online help that we reach in the upper right corner:

I followed the instructions and setup ssh connection for the Database Control Agent to the two Cells. The OK button then leads to this screen, where we click on the host link (my host is named database):

Next step is to add the two Cells; from the next screen, we click the GO button:

That lead us to the following screen, where we type in the name and the IP of every Cell subsequently:

After having added both Cells this way, we see this screen:

The Database Control Homepage reflects the Cells presence now:

Clicking on the number (2) gets us to this screen:

On the Cell layer (Cell1 link from above), we have a huge collection of metrics, similar as we are used to have on the Database layer since 10g:

I have a collection error, probably because my Database Machine is simulated inside VirtualBox. But most metrics get collected as with the real thing. For example metrics related to the Flash Cache. I have created a small table and assigned it to be kept in Flash Cache with a statement like:

If later on select is done on the table, we can monitor the reads from Flash Cache on behalf of kept objects. As with all the other metrics, this can also be done on the command line – but with much more effort. I connect to Cell1 as user cellmonitor or celladmin and call cellcli:

From that Storage Server, we have read objects that had the attribute keep from Flash Cache with in summary 26.7 MB, collected at 4:56. This can be done much more comfortable (notice the peak at short before 5:00) with Database Control now:

Conclusion: We can use our familiar Enterprise Manager (Grid Control or Database Control flavor) to administer and monitor Exadata – amongst others we have similar metrics now on the Storage Server Layer as we have had already on the Database Layer before. Fortunately, Exadata is still Oracle :-)

Uwe, No problem take your time to read it ;-)
The main idea is that cumulative, instantaneous, rates and transition exadata metrics are not enough to answer all the basic questions. That’s why the script has been created as it provides a better understanding of what’s is going on on the cells right now.

I modified the utility so that we are now able to exclude name and/or metricobjectname based on wildcard.

The arguments are now a little bit different (to avoid too much arguments):

– NAME_LIKE and METRICOBJECTNAME_LIKE have been removed
– The “=” predicate now supports the wildcards.
– The “!=” predicate has been added to answer your need (the not like need) that supports wildcard too.

If you have problem “Permission denied (publickey,gssapi-with-mic,password)” then
before setup “Monitoring with Database Control” you need co setup the user equivalency between oracle user (or user under which EM agent is working) and cellmonitor user on the cell.