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):
The Database Control Homepage reflects the Cells presence now:
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:
SQL> alter table sales storage (cell_flash_cache keep); Table altered.
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:
CellCLI> list metriccurrent FC_IO_BYKEEP_R detail name: FC_IO_BYKEEP_R alertState: normal collectionTime: 2011-02-15T04:56:35-08:00 metricObjectName: FLASHCACHE metricType: Cumulative metricValue: 26.7 MB objectType: FLASHCACHE
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 🙂