A friend wrote:
- Single pane of glass to see and manage and monitor all software and hardware, whether prod or non-prod
- 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.
- 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.
- 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.
- Everything in EM, including things like monitoring templates, will need to be duplicated.
- 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.