The architecture and installation of Oracle Enterprise Manager GC 10g, GC 11g, and CC 12c differ for all components, and particularly for the OMS and Management Repository:
OMS Architecture and Installation
Both the architecture and installation of the OMS diverge between GC 10g, GC 11g, and CC 12c.
The 11g and 12c Oracle Management Service (OMS) is built on Oracle WebLogic Server (WLS) 11g Release 1 (version 10.3.5), whereas the 10g OMS runs on Oracle Application Server 10g (10.1.2.3). This architectural distinction results in an entirely new and vastly improved Console look-and-feel in CC 12c than in GC 11g/10g.
The GC 11g installation on all platforms except Linux 32-bit requires that you first install Java Development Kit (JDK) 1.6, then install WLS 10.3.2 and apply patch ID WDJ7, whereas on all CC 12c platforms, the Installer takes care of WLS 10.3.5 installation and patching for you. CC 12c installs WLS, just as GC 10g lays down Oracle Application Server 10g.
Management Repository Installation
As of GC 11g, the installation of the database for the Repository was decoupled from the OEM installation itself. In GC 10g, one of the Oracle Universal Installer (OUI) options was, in addition to installing the OMS, to create a new 10g Database for the Repository. By contrast, the GC 11g and 12c software distributions do not include a built-in Oracle database for housing the Management Repository; you must preinstall a database in all cases. However, CC 12.1.0.2 offers a template in Database Configuration Assistant (DBCA) that creates a preconfigured Repository database.
The following section provides more details on these key architectural and installation differences between the OEM 10g, 11g, and 12c releases.
OEM 11g and 12c Use WLS Whereas OEM 10g Uses AS 10g
Moving from Oracle Application Server 10g in GC 10g to an Oracle Fusion middleware WLS platform in OEM 11g and 12c was a radical departure for Oracle, but in line with what is now the foundation of their application infrastructure. Oracle acquired BEA Systems, Inc. for 8.5 billion dollars in April 2008 as a strategic move to overtake IBM’s WebSphere platform. Oracle was looking to become the service-oriented architecture (SOA) market leader, by providing complementary middleware products, Oracle OC4J Application Server and BEA WebLogic. Oracle positions WLS 11g as the industry’s most comprehensive platform for developing, deploying, and integrating enterprise applications. WLS is indeed the top-rated application server in the industry.
In GC 10g, the OMS is a Java 2 Platform Enterprise Edition (J2EE) middle-tier application that renders the user interface for the GC Console. (J2EE is an environment for developing and deploying enterprise applications.) The GC 10g middle tier, which runs on Oracle Application Server (OAS or Oracle AS) 10g, contains three elements: Oracle Application Server Containers for J2EE (OC4J), Oracle HTTP Server (OHS), and OracleAS Web Cache. The OHS deploys the 10g Management Service J2EE Web application. The OMS 10g is technically part of the OC4J, but the entire GC 10g middle tier is usually referred to as the OMS. OracleAS Web Cache provides an additional way to log in to the GC Console.
In contrast to GC 10g, the GC 11g and CC 12c middleware platforms consist of a WLS instance in which an OMS application domain is created (called the GCDomain), rather than the OMS being deployed in its own OC4J container. In addition, OracleAS Web Cache is not used in GC 11g and CC 12c, as it is in GC 10g. This is a boon for GC 11g, in our opinion, for at least three reasons. The first is that Web Cache is not terribly useful in GC 10g, and provides very little performance advantage over logging in to the Console directly to OHS.
Most Console requests, being ad hoc, are for dynamic data with very little cached content, generally limited to icons, menu items, headers, and footers. Secondly, Web Cache complicates the diagnosis of GC 10g problems, as many Enterprise Manager analysts at Oracle Support can surely attest. Lastly, Console access via Web Cache is unsecure (on HTTP port 7777) out of the box, and the configuration process to secure such access is nontrivial and undocumented. This is a gaping security hole for sites that want to use Web Cache, but need to enforce secure communications between all GC components.
NOTE
Web Cache in GC 10g acts like a virtual server on behalf of OHS for the Management Service. If any part of the content is in its cache, such as from navigating to a previous page, Web Cache sends that part of the content directly to the Console browser and stores a copy of the page in cache. This is known as a cache hit. If Web Cache does not have the requested content, or if the content is stale or invalid, it hands off the request to the OHS, which requests the data from the Management Service. This is known as a cache miss.
Must Preinstall a Database for the Repository in OEM 11g and 12c
Oracle’s direction to use WLS rather than OAS as the middleware platform for the OMS cannot be disputed from the standpoint of technology choice. By all accounts, WLS is a superior product to OAS 10g in many respects. Oracle could have taken the direction of using Oracle Application Server (AS) 11g for the OMS application. However, AS 11g itself uses WLS as its J2EE component. The technological direction came down to whether to build the OMS application in an OC4J container (used in GC 10g) or in a WLS instance. While Oracle provides customers with the choice to build their own applications on either OC4J or WLS, it is clear which choice Oracle itself preferred for its own applications, GC 11g and CC 12c.
Before installing GC 11g or CC 12c, you must first install a certified database to house the Management Repository. By contrast, in GC 10g, while you had the option to first manually install an Oracle 10g or 11g Database, you could alternatively choose to have the OUI install a single-instance Oracle 10gDatabase containing the Management Repository. This distinction is more than just a superficial difference in installation choices; it is an architectural diversion between 10g and the later 11g and 12c releases. One can safely assume that the Oracle EM development team recognized that there are too many supported releases (including patch sets) and types of Oracle database installations available in OEM 11g and 12c to be able to choose just one type or offer multiple installation types through the OEM Installers. Database releases and patch sets include 11.2.0.1+, 11.1.0.7, and 10.2.0.5+, and installation types include Oracle RAC, single-instance, Oracle RAC One-Node (ORON), and Cold Failover Cluster (CFC). The EM development team understandably wanted to get out of the business of having to maintain links in the OEM Installer to one or more Oracle database releases and patch sets certified for the Management Repository.
Even if the EM group chose for the 11g and 12c Installers only to offer the latest certified database release and patch set for the Repository, this would be a moving target. That is, new database patch sets released and certified with OEM would supersede any earlier database patch set that might be bundled with the OEM software. By not offering to lay down an Oracle database as an option in the OEM 11g or 12c Installers, the responsibility for selection of a particular Oracle database release, and the database architecture, is left with the DBA performing the EM installation. In our view, this is a good direction for Oracle to have taken, particularly now that CC 12.1.0.2 offers a template for DBCA that creates and configures an 11.2.0.3 Database and preinstalls the Repository in it, before the Cloud Control Installer is run to install the OMS. It was certainly convenient for customers to let the GC 10g Installer lay down all GC components, including a database for its Repository. However, we observed that many customers who installed GC 10g with the New Database Installation Type never patched, reconfigured, or tuned the seed 10g Database that the GC Installer dropped down.
These customers made an arguably justifiable assumption that the 10g Database installed by GC 10g would be patched, configured, and tuned out of the box to support the accompanying Management Repository. Sadly, however, this was not the case. In fact, if you selected the GC New Database Option in any release or version of GC 10g (10.1 or 10.2), the Installer laid down Database 10.1.0.4 for the Repository. This was the case long after 10.2 Database was certified with GC 10g—and even after 11.1 Database was certified. Thus, to take advantage of bug fixes and new features afforded by Database Release 10.2 over Release 10.1, customers who chose to let the GC 10g OUI install a new database had to subsequently upgrade the Repository database software and database itself from 10.1.0.4 to 10.2.0.1 (including performing post-installation database steps), and then apply the latest Database 10.2.0.x Patch Set.
Leave a Reply