Skip to content

Using Oracle Enterprise Manager Grid Control to Manage DB2

I posted a question on DB2-L asking other DB2 database professionals about their experiences using Oracle Enterprise Manager (OEM) Grid Control (GC) to manage DB2 databases using the OEM DB2 plug-in. I received this very helpful response from Peter Suhner ( peter_suhner AT hotmail DOT com ), posted with his permission:

yes, we do [use OEM to manage DB2 databases] – just for convenience (many Oracle DBs, only around 60 DB2 LUW instances). The DB2 Plug-in is ok, it basically grabs the values from the DB2 databases through JDBC by calling the respective admin functions (e.g. “get_dbsize_info(?,?,?,-1)” and the like – NOT the SYSIBMADM views). It provides you with about all relevant standard monitoring values. I think you could also extend these standard checks with some of your own, but I haven’t found the time to delve into this.

However, my experience is as follows:
– I’m not aware of a way to acutally manage the DB2 instances, we just monitor them through OEM. Maybe I missed something there?
– DB2 health monitoring must be turned on (not all shops like to do this for performance reasons)
– You can use the DB2 plug-in out of the box, but might want to adapt some of the standard threshold and scheduling values
– Not all the values shown in OEM are 100% reliable (e.g. Bufferpool Hit Ratio sometimes varies heavily from what native DB2 values show – looks like this is caused by OEM doing some strange maths of it’s own to various values – thus the term “Oracle”?). For our shop, these differences were found to be negligible.
– OEM database tends to become incredibly slow with growing amounts of monitoring data
– As a result, reports of one single DB usually work fine, but reports over groups (which would be a nice feature) just fail with timeouts (maybe there’s a way to tune our OEM database? But I’ve seen better data models in my life)

From my experience, I would not recommend OEM for sites with many and/or performance critical DB2 databases. However, to integrate monitoring of a few DB2 instances into an Oracle shop, this is an acceptable solution providing low overhead and one single, identical interface. Definitely a pro!

Thanks Peter! My biggest concern in reading your comments that Health Monitor would have to be active to use OEM to monitor DB2 health. As I have commented elsewhere in this blog, I have had to deactivate Health Monitor in a DB2 version 9 database due to its detrimental effect on database performance.

Post a Comment

Your email is never published nor shared. Required fields are marked *