2013-08-11 06:55 AM - last edited on 2015-08-25 05:56 AM by alissa
We've been considering using the new NetApp 188.8.131.52.0 Plug-In for Oracle Enterprise Manager 12c, but it seems to be missing many metrics in comparison to the older target type in OEM 10g/11g ("NetApp Filer") - for example "Buffer Cache" metrics or "File or Directory" metrics.
Also, there are only three configurable thresholds in the new plug-in.
Is this intentional? Are there any plans to issue a newer version of the plugin with more extensive functionality?
2013-08-11 09:44 AM
We are now working on version 184.108.40.206.0 of the NetApp Storage System Plug-in for OEM 12c. New features in this version include:
Can you please list other metrics that you are interested in monitoring that exist in the OEM 11g plug-in and not in the plug-in for OEM 12c.
Product Manager - Oracle Products, Integrations and Solutions
2013-08-28 07:58 AM
I installed the current version of the plugin and it shows basic performance data as expected.
What I don't understand is how does the mapping of Netapp NFS volumes to databases occur? Is there a 'discovery' I need to run?
I don't see any data when I run a 'Database Storage Utilization' report.
2013-08-28 09:23 PM
Please confirm the below steps:
1) Make sure that you have discovered database from Oracle Enterprise Manager and it is listed as Target.
2) Ensure that storage controller is registered with NetApp plug-in on which database resides.
3) Please ensure that you have used same storage controller (IP address or fully qualified domain name) as defined in fstab entry on linux host for database nfs mount point. It is recommended to use IP address at both places because storage controller can have multiple data IPs (data IP and management IP address)
4) While launching Database Storage Utilization report from plug-in home page, please make sure that you have selected "Database Instance" by clicking on selection icon. By default, it selects storage controller instance. This is limitation from Information Publisher Reporting tool that by default, it picks same target type instance.. This will be fixed when we will migrate reports to BI publisher reporting.
Point to note: Sometimes, it takes more than 6 hours to reflect the storage mapping after storage and database registration with OEM.
Please let me know your feedback.
2013-08-29 11:46 AM
2) Yes, the SANs in question have been added to OEM.
3) I think what you are saying is that the Netapp console has to be on the same subnet as NFS????
In our case the console is on a different subnet than the NFS traffic. So OEM will talk to the Netapp console
on xx.nn while NFS traffic occurs on yy.nn - two different IP's. If this is the requirement for database mapping report
to work then I think we are out of luck.
4) Yes I have tried this.
2013-08-29 12:22 PM
All points are fine. We need to discuss about point 3. It's not subnet. We do support database to storage mapping across subnet communication i.e NetApp console and NFS traffic can be on different subnet. What we need to validate is: IP address entry for NFS mount point in /etc/fstab file on linux host on which database resides. For version 1.0, we have a requirement that storage name or ip address in fstab file should map to IP address or storage name used for storage controller registration on OEM "Add Targets" page. I request you to share following piece of information:
1) Fstab file entry for NFS mount point on which database resides.
2) IP address or Storage name used at the time of storage controller registration to OEM.
Based upon that, we will decided further steps. If problem persists, we can do conf call to see your setup and do our best to make this report working for you.
Can you please share your company name?