Thursday, October 15, 2015

Separate or one Enterprise Manager environment for managing prod and non-prod targets


A friend wrote:
I know we can manage all targets using one single Enterprise Manager 12c environment but I know there are advantages of having two separate environments, one for Prod targets and the other for non-Prod targets.  Please explain pros and cons of both architectures, so that we can decide one over the other.
My answer:
Mate, the benefits of a single Enterprise Manager install for Prod and non-prod are manifold:
  1. Single pane of glass to see and manage and monitor all software and hardware, whether prod or non-prod
  2. Ability to control access between DBA teams. A dev DBA will not be able to even see a prod target if the access is properly set up.
  3. Several EM packs work more effectively if targets are in 1 EM system. For example, comparing configurations between dev, test and production is only possible if all targets are together. Change management – copying schema changes from development  to test to production – works seamlessly if all the targets are together. And so on.
  4. A separate EM for separate targets will increase EM management overhead. You will need to patch the OMS as well, so now you are patching two instead of one, and so on.
  5. Everything in EM, including things like monitoring templates, will need to be duplicated.
  6. Defeats the idea of Database as a Service, if the company wants to move to that in the future. If targets are in different EM systems, you cannot use them in database pools for the same self-service user defined in an EM system. The self-service user now will have two self service screens, one for production, one for test. This may work however with a separate orchestration engine, like Oracle BPM.

Regarding the advantages of separate systems, do tell me. Security? Less load on the OMS from non-prod targets? Most of these points and objections ultimately turn out to be non-valid. Nothing beats a centralized EM installation managing and monitoring your entire enterprise.
This blog post was originally published at this link.

No comments:

Disclaimer

Opinions expressed in this blog are entirely the opinions of the writers of this blog, and do not reflect the position of Oracle corporation. No responsiblity will be taken for any resulting effects if any of the instructions or notes in the blog are followed. It is at the reader's own risk and liability.

Blog Archive