Oracle Enterprise Manager - a perfect tool for monitoring databases and for performance tuning.
1. To monitor production databases for alerts against set thresholds.
2. To diagnose and drill down into details of the performance issues.
- In OEM, the agents are installed on production database servers and they collect and send diagnostic information from databases to the OMS. The OMS compares this information with set thresholds and raises alerts in OEM. This is particularly done well as Oracle database does have lot of diagnostic information that OEM agent can collect.
- It can monitor databases at set interval time for required diagnostic information and for error codes. It then displays that information in a GUI interface that is graphical and easy to understand. The OEM can raise alerts based on thresholds and it can send emails or input to other systems that can raise tickets or alert operations.
- It can also run preventive actions based on alerts. This helps in reducing response time to errors and issues that can cause database downtime. There are predefined actions and DBAs can also write customized procedures to be run as preventive measures.
Cons
- The OEM is very good at monitoring Oracle databases as they are from the same vendor and have in-depth knowledge of Oracle technology. However, improvements can be made to monitor all sorts of databases and even NoSQL databases which are now commonplace.
- The OEM architecture can be simplified so installs and configurations can be simple and straightforward. Complex installations require a long implementation time and it increases cost of the implementation.
- The OEM slows down response as it monitors a large number of busy prod databases. So scaling should be improved to handle large workloads.
- The OEM should use standard TNS ports in place of non-standard ports which are often blocked in most networks. This causes delay in implementation due to violation of security compliance in most organizations.