I'm trying to upgrade my OEM from v2.1 to v2.2 on a Windows NT 4.0 sp5 box. I have a few questions before proceeding....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The format is a quote from a Metalink article. Thanks in advance.
Subject: Enterprise Manager 2.2.0 Components Compatibility Matrix
This release of Enterprise Manager has been designed to operate in a multi-tier architecture. When running more than one of these tiers on the same machine, make sure that all components simultaneously in use are run from the same Oracle Home. This is not a requirement, but is strongly recommended.
Version 2.0/2.1 with 2.2
It is possible to have multiple copies of Enterprise Manager 2.0, 2.1 and 2.2 installed on the same machine at the same time, as long as they are installed in separate Oracle Homes. Oracle does not recommend this configuration and if you have v2.0, 2.1 and 2.2 installed on the same machine consider the following points:
- Do NOT run different versions of 2.x applications concurrently.
- Only one instance of the OMS can be run at a time, whatever the version.
- Do NOT use this configuration if you are using any of the management packs (most of the packs prevent multiple installations of themselves).
If multiple 2.x versions have been installed on the same machine, deinstalling any one of the versions will cause some registry entries common to both versions to be removed. Oracle recommends customers deinstall all versions and then reinstall the required version to avoid this problem.
The JRE (Java Runtime Environment) is installed by various Oracle products. However, there is only one shared JRE per system. Hence, if after installing Enterprise Manager 2.2 you install a previous version (i.e. 2.0 or 2.1), the JRE will be downgraded automatically, without warning messages. This downgrade from JRE 18.104.22.168o will cause problems with release 2.2. Installation of a pre-8.1.7 Oracle database will also cause this problem. Oracle does not recommend installing an earlier release after installing 2.2.
Q1: I have applied patch 22.214.171.124.1. The patch set includes recovery manager 126.96.36.199.0. If I were to deinstall Oracle Enterprise Manager Packs 188.8.131.52.0 and Oracle Enterprise Manger Products 184.108.40.206.0, Oracle Intelligent Agent 220.127.116.11.0, Oracle Management Server 18.104.22.168.0 and Oracle Enterprise Manager Packs and Management Infrastructure 22.214.171.124.0 and reinstall just the Oracle Enterprise Manager Packs and Management Infrastructure 126.96.36.199.0, I'm concerned the recovery manager patch might not be recognized.
A1: You should not have a problem because the OEM software should be in a completely different ORACLE_HOME than your RDMBS software. So your deinstal of OEM should not affect your 188.8.131.52.1 patchset. I believe that the OEM documentation clearly states that OEM should be in its own ORACLE_HOME.
If you have both products in the same ORACLE_HOME, then you should remove the OEM software from your RDBMS ORACLE_HOME directory.
SQL*Plus Worksheet by default uses SQL*Plus 8.1.7 installed in the OMS Oracle Home. Editing the SQLPLUS_EXE_DIR / SQLPLUS_EXE_FILENAME entries in the ..sysmanconfigdbapps.cfg file allows you to use different versions of SQL*Plus. Oracle doesn't recommend changing this unless it is necessary to work around a bug. When using SQL*Plus 8.0.6 the following restrictions apply:
- DBA (SVRMGRL) commands are not available.
- All commands must be completed with a semicolon.
- SQL*Plus can only connect to the database as Normal. It cannot connect to the database as SYSDBA or SYSOPER.
In the OEM22_Home, the entry in the dbappscfg.properties file is SQLPLUS_ENDOFBUFTOKEN=OEM_sqlplus_input_finished. In the Oracle816_Home, the entries are:
OMS, Repository & Migration/Configuration asst.
The version of the repository must be compatible with the release of the OMS (Oracle Management Server) with which it is being used. Enterprise Manager OMS v2.2.0 must use a v2.2.0 repository, a previous OMS cannot access a 2.2.0 repository. The version of the Console and OMS must also be the same; customers should be aware if they upgrade the OMS to v2.2.0 they will also have to upgrade all Consoles to 2.2.0. Additional information is available in [NOTE:69185.1].
Creation of the Enterprise Manager Repository for Release 2.2 has been certified in the following Database Releases: 8.1.7, 8.1.6.x, 8.0.6.x and 7.3.4.x. If an existing repository is being upgraded to 2.2 the database must first be upgraded to one of these database releases.
If the existing Enterprise Manager repository version is v2.0.4 or 2.1.0 then use the Enterprise Manager Configuration Assistant (EMCA) to upgrade the repository to 2.2.0. This will not automatically occur when the OMS is upgraded.
Q2: I think I'm getting confused by terminologies: They say an 8.1.6 repository can work with OMS 2.2, and they say OMS 2.2 must use a v2.2 repository (which to me is an 8.1.7 repository). Is that an accurate read on my part?
I too think that you are getting terms confused. The OMS repository is nothing more than a bunch of tables which store your OEM information so that when you fire up OEM (and OMS) again, you won't have to re-enter your information once again. For instance, there is a table which holds all of my events. This repository can exist in either an Oracle 8.1.6 or an Oracle 8.1.7 database.
When you fire up OMS the first time and connect to the database, it creates the repository tables for you. If you fire up OMS 2.1, it creates 2.1 repository tables (the database version is of no importance here). I cannot then fire up OMS 2.2 and expect it to use the same repository tables. I must upgrade my repository (but not my database version). If my repository is created with OMS 2.2, then I cannot use OMS 2.1 on that repository. And there is no downgrade procedure that I can recall.
I think you are getting confused because OEM 2.1 ships with Oracle 8.1.6 and OEM 2.2 ships with Oracle 8.1.7. But that's just the release schedule. I can (and do) mix the OEM versions with my Oracle versions. In fact, I currently have an Oracle 8.1.6 database that holds OEM repositories for OEM 2.0, 2.1, 2.2, and even older OEM 1.x versions!
Dig Deeper on Oracle database design and architecture
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.