Oracle Enterprise Manager Review

Very helpful to have the ability to enable centralized control & administration of Oracle products from a single console


What is our primary use case?

Provide 24x7 monitoring of application system availability for both on-premise, and on-cloud application systems, and forecasting data relating to overall system utilization (or under-utilization.)

How has it helped my organization?

With over 2,700 different target components deployed and in-use, it would be impossible for 4 DBA's to otherwise monitor and assess the condition of this number of separate application and database systems by individually logging into separate administration consoles for each product. The automation elements reduce the training time required to get our junior operators up to speed doing routine patching or cloning, and allow the senior staff to have more resource time available for strategic planning and ensuring overall availability of the critical systems without sacrificing proper monitoring and security awareness checking.

Recently, including new off-premises (cloud- based) application re-hosting, presents the challenge of whether to monitor cloud from on-premise, or vice-versa. We are currently experimenting with a cloud-watches-cloud plus on-premise-watches-on-premise approach.

What is most valuable?

The 13cR3-PG (Patch Group) 1 updates to the OEM family, strongly integrate Cloud (off-site, hybrid and on-premise) services providing a seamless way to see all of your resources regardless of where they are deployed.

PG1 adds enhancements for EMCLI (Command Line Interface) extensions to allow additional automation and scripting of common OEM tasks (Blackout begin/end, Patch availability monitoring, cloning enhancements.)

Of the 12c series of Oracle Enterprise Manager products, version 12.1.5.0.x introduces Cloud (both public and private) support for both monitoring, and lifecycle management. This allows individual components, or entire systems to be resident either in-house on conventional hardware/VM's, or ported into virtualized datacenter environments, off-site, whether for fault tolerance and disaster recovery, or simply to reduce the cost of non-Production systems by using a pay-to-play methodology (reducing investment in specific hardware just to support disposable and transitional software systems development?) Consolidated and uniform monitoring of all Oracle-related technologies. Ability to enable centralized control and administration of Oracle products from a single console. Ability to see at a glance, all conditions of all products throughout the enterprise. Version 13c includes hybrid cloud support making transparent the transfer of provisioning systems between Oracle's Cloud and on-premise equipment. All of the cloud systems and in-house systems appear in logical groups according to their common function (Applications, Middleware, Databases, etc.) The configurations are also snapshot-friendly and made comparable to quickly isolate differences between similar systems.

In the Oracle Cloud Infrastructure (OCI) based Oracle Management Cloud (OMC) 1.48.0 you have many subscription-based options, like Log Analytics and Application Performance Management that you can activate quickly, try them on for size, and keep them or decomission them for relatively less cost and time than doing so, on-premises. These features also avail you access to technologies requiring higher horsepower (CPU/RAM/etc.) found in the OCI Exadata-based Virtual Machines (VMs) that may be beyond your current investment level.

What needs improvement?

Reporting and statistical charting is largely still left up the end-user to develop custom solutions. Having more pre-built standard industry-generic reports using Business Intelligence (BI) Publisher provides out-of-the box basic analysis would be increasingly useful. The actual product inventory discovery and configuration process has improved, but is still fairly convoluted and requires multiple pre-requisite setup steps to be completed, requiring numerous Cancel, Go back and set something else up, then Return to the process you were performing types of process flows. It works really well if all the technology stack layers are current releases, but the more heterogeneous the architecture is, the more you will spend more time configuring outlying systems, or systems that aren't quite up-to-date.

The OMC array of offerings is quite numerous, so when you first try to navigate the menu offerings, you'll experience 7 to 10 layers of click-throughs to find what you may be looking for in the mass number of options. There is currently a hybrid UI between the Cloud Classic menus and the revised OCI v2.0 menus that has many duplicates, but are found using different navigation paths, which can be confusing. While the main dashboards are fairly clear, there are often click-throughs that lead you down not so clear breadcrumb trails during your navigation. One thing that is particularly annoying is when a Cloud Management component itself fails (such as a Cloud Agent, or a discovery job) you will still need a 2nd monitoring system, such as OEM to watch for the failed Cloud service target. Sometimes simple operations like checking for a failed backup set in OCM are not at all straight-forward and need to be programmed individually by the customer, rather than being available as a simple template to be activated, as expected.

For how long have I used the solution?

More than ten years.

What do I think about the stability of the solution?

During upgrades, plugins take on 2 different architectures - some are built as standard WebLogic composites, allowing hot upgrades and installation (meaning you don't have to have an outage for the OEM Management System (OMS) in order to complete the installation. Others are more complex requiring specific outage windows during which time the OMS will not be able to monitor targets (often the OEM Agents are still operating, and collecting information, but you need to develop standalone OS-based alerting on the individual boxes to leverage an individual Agent's ability to provide outage notifications when the OMS is down.) These OMS-downtime upgrades and installations can also be the most prone to potential failure during installation requiring complete system rollback to a backup point.

OMC is updated frequently and only incurs momentary downtime when sortware homes are being switched between pre- and post-patch versions. Agent patching is similar to on-premise, requiring no downtime.

What do I think about the scalability of the solution?

Both on-premise and OMC are scalable vertically and horizontally; you would just include the licensing costs of high-availability for both the middle-tier and database layers (or number oF VMs for clustering) and the added storage or incremental costs to include additional targets or resiliency.

How are customer service and technical support?

Customer Service:

7 of 10 for customer service (often various contacts are disconnected from each other communication-wise regarding the profile and installation data of customers).

Technical Support:

8 of 10 for technical support (My Oracle Support is well-integrated into the OEM platform and guides the user quickly to relevant solutions.)

Which solution did I use previously and why did I switch?

Previously used prior release of OEM (version 9.2.0.6) - these older versions are no longer supported by Oracle, and are prone to many security, stability and incompatibility issues with most newer product releases (for example, 10g (10.2.0.x) is the only client still capable of backwards-compatible connections to 9i and 8i databases, and also forwardly compatible to 11g and 12c databases - but it is not supported anymore, patch or bugfix-wise.)

How was the initial setup?

Straight-forward - the basic deployment simply requires an adequately sized and certified hardware platform with sufficient storage to hold the software, and database repository, and sufficient CPU to run a web-based application based upon the number of potential monitored targets and users.

OMC is a little different in that there are a number of security-related prerequisites to enable the OMC side to communicate securely with the OCI VMs being monitored.  All of the process, though lengthy, is reasonably documented, and typical of Oracle documentation, a little fragmented and jumps around a bit.

What about the implementation team?

In-house implemented. 3 days from initial download to production operation.

What was our ROI?

The typical acquisition and year-to-year support maintenance costs equate roughly to a person-year of a typical DBA. You can expect that given the ability of the existing staff to either become more precise and strategic at preventing issues from arising without adding additional staff, makes this an easy pitch. e.g. You could either add 3 additional dedicated DBA's whose job is to login and monitor every application in a typical 4-5 major application environment (EBS, HR, BI, Webapps, Mobile, SOA, etc.) 24x7, or you can install OEM and configure it to provide the requisite alerts and projection reports needed to ensure the same SLA requirements, without adding staff.

What's my experience with pricing, setup cost, and licensing?

Based upon 3 days of implementation by a single person, plus licensing costs would be approximately $60,000, including the virtualized hosts. Day-to-day is very roughly $100 for routine patching and maintenance. High-availability significantly may double or even triple these expenditures, but for some environments that's inevitable. If one system needs that level of oversight, then all of the infrastructure will be managed to the same level of oversight by OEM. There is also an augmented set of separate, but useful features being added under the Oracle Management Cloud suite of products designed to focus more on analytical problem identification (such as when one issue triggers a seemingly unrelated set of other symptoms) and leverages the power of mass target data agglomeration at the expense of having costs driven by the volume of data being recorded. But this is typical of most cloud-based solutions, where bandwidth utilization is a cost driver.

Oracle Management Cloud is basically a VM environment spun up in the region containing your systems to be monitored and managed. Oracle do not support cross-region management using OMC (however, you can do that with additional plugins to OEM on-premise) so if you run VMs actively in more than one region, you'll end up with multiple OMC systems, and the associated costs.  Be aware, you are charged in many different levels, but mostly to license the product itself, the cost and storage to run the VM, and then storage to injest and store however much logging and data you want to retain for the puposes of monitoring, troubleshooting, auditing, and forecasting growth. This is quite different from on-premise monitoring costs which usually are limted to a base license, plus support subscriptions, and then incremental spends for increasing base storage for the hosts. It's best to proceed slowly and incrementally when adding systems to OMC to monitor, so you can baseline and measure how much each system costs in-total to monitor, and determine what level you want to monitor each system (Enterprise and Standard monitoring templates are available and can be dynamically switched for each system, or the whole OMC target inventory.)

Which other solutions did I evaluate?

ELK, HP OpenView, BMC Patrol

What other advice do I have?

Analyze your daily monitoring and service intervention needs, based upon the available (or target) headcount, otherwise you may find yourself inundated with more alerts and notifications than can actually be handled by your staff. Don't just turn on all the alerting and notifications out of the box. Start with what you know you want and are capable of responding to, and closing effectively. Enable those. Then work outwards towards the nice-to-know, or discovery alerts.

Currently, depending on your implementation and use timeframe, you may also want to evaluate the Oracle Management Cloud solutions, which are similar, but different in that they employ a pay-as-you-go approach to the monitoring and management cycle. The On-Premise OEM solution works best for dynamically growing environments (that tend to get bigger and bigger over time) or for stable complex environments that will be in-place for the next 10 or more years.

Which deployment model are you using for this solution?

On-premises

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More Oracle Enterprise Manager reviews from users
Add a Comment
Guest
3 Comments

author avatarit_user516591 (Operations and Infrastructure Manager at a financial services firm with 51-200 employees)
Vendor

Used Oracle Enterprise Manager for a long time and it is very helpful in doing monitoring of Oracle Database. It helps in Utilization Monitoring and Performance Monitoring. What I want on it is that is can provide insights on database fine tuning as we are working on high performance database. We are currently using EM 12C and integrating all our Database Servers and Database Instances on it to have a better view on the whole spectrum of our infrastructure.

author avatarit_user516651 (User with 1,001-5,000 employees)
Vendor

I have installed these EM versions from 11g, 12c, and 13c. So far Oracle support is quite helpful in the process.

author avatarJames Lui
Top 5LeaderboardReal User

Agreed. Though with the Lifecycle management suite, the configuration comparisons of changes to parameters overlaid on the ABSTRACT for the same periods can provide good insights. Any thoughts on the specific "fine tuning" elements you would like to see added? Those kinds of recommendations can always be relayed back to the product development team.