Oracle Enterprise Manager 12c Grid Control

I've always used Enterprise Manager to some extent. I can remember when it just started out as a Java console program. Clunky, unrefined and not very friendly. Yet, I could see the potential and where Oracle likely wanted to take the product, but wondered as to if they were up to the task. I often thought they would just buy Quest who had an impressive portfolio and was probably (I thought) used most by DBAs, developers, and architects alike. Maybe even Embarcadero, whose DBArtisan tool I actually preferred and found to be a better tool than Quest Toad back then. It is now several years later and how Enterprise Manager has grown up. It is now offered as "DB Console" for single database administration, and as "Grid Control" for multiple database administration and your enterprise-wide monitoring and administration tool.

Grid Control 11g (11.1.0.1) is a web-based tool leveraging WebLogic Server (WLS) 10.3.2 for UI presentation, a database back-end for its storage repository, and agents for data gathering and carrying out monitoring and administration. I'm sure I've been told on many an occasion why each Grid Control will require a specific WLS version but the answer escapes me for now. This however should not be an issue since the WLS should be self-contained (i.e. only for Grid Control) and IMHO installed on the same server as the OMS. If you have multiple OMS for HA, then install a WLS instance on each OMS as well for HA.

Now released is Enterprise Manager 12c (12.1.0.1) Grid Control which will require WLS 10.3.5. This brings a new and improved interface, which also includes cloud computing management features such as charge back and metering.




My interest in this case are the available upgrade options as shown below:

Two-System Upgrade - Creating a new EM 12.1 infrastructure and switching the new 12.1 agents to point to the new EM 12.1 infrastructure. Requires minimal downtime but new EM infrastructure and you will also have to merge data that was accruing while the upgrade was taking place.



One-System Upgrade - This option requires more downtime but no additional infrastructure. Here you are installing the new 12.1 OMS (and 10.3.5 WLS) on the same servers, and then upgrading your OMS to 12.1 (which includes upgrading the repository). Prior to this you would have shutdown your pre-12.1 agents and started up your new 12.1 agents (which were already installed).



I prefer the Two-System approach since it has the advantage of minimizing downtime, while providing a fallback option. It also seems a bit less complicated. The previous hardware can be recycled so I don't find that to be an issue (also serves to provide a hardware refresh opportunity). I think most would agree with this being the better of the two options given. To provide a bit more information see the comparison below: