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:
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 🙂
Pickleball spielen 
#1 von saurabh am März 13, 2012 - 14:54
Dear Uwe,
Thanks for the detailed steps.
I was trying to connect cell servers on database control. But getting below error message when I click on Test Connection after putting Management IPs:
Permission denied (publickey,gssapi-with-mic,password)
I logged in Database Control using sysman user.
We have ssh set on all the cells.
Kindly let me know why it is throwing error.
Thanks,
Saurabh
#2 von Uwe Hesse am März 17, 2012 - 11:30
Saurabh, I have no clue here – suggest you contact Oracle Support or try this forum (LINKS list on the right): http://forums.oracle.com/forums/forum.jspa?forumID=829
#3 von bdrouvot am November 28, 2012 - 17:24
Hello Uwe,
I just want to let you know that I developed a perl script to extract exadata real-time metric information based on cumulative metrics.
More details (on how and why) here : http://bdrouvot.wordpress.com/2012/11/27/exadata-real-time-metrics-extracted-from-cumulative-metrics/
Please don’t hesitate to give your opinion and report any issue you may found with it.
Thx
Bertrand
#4 von Uwe Hesse am November 28, 2012 - 21:01
Bertrand, I’m very busy these days, so I don’t know when I can have a look at it. Thank you for the mentioning, though!
#5 von bdrouvot am November 29, 2012 - 08:04
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.
Bertrand
#6 von bdrouvot am Dezember 12, 2012 - 16:45
Hello Uwe,
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.
Example:
exadata_metrics.pl cell=cell metricobjectname=’CD_disk03_cell‘ name!=‘.*RQ_W.*‘
exadata_metrics.pl cell=cell name=‘.*BY.*‘ metricobjectname=‘.*disk.*‘ name!=’GD.*‘ metricobjectname!=‘.*disk1.*‘
New version of exadata_metrics.pl available here : http://bdrouvot.wordpress.com/perl-scripts-2/
Bertrand
#7 von Yuri Pudovchenko am Dezember 19, 2012 - 16:46
Hello,
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.