Recommended Install Type- ‘Enterprise Manager 10g Grid Control Install Using an Existing Database’
Silent Install Scenario -‘Installing Software-Only and Configuring Later’ 10.2.0.4+ OMS
Why should I install a separate database?
- Because you tend to get caught (a painful migration) when a major change is required – such as the timezone changes, CPU’s, database and/or OMS patchsets, migrations to different nodes or operating systems, etc. “If your Enterprise Manager Grid Control Release is 10.1.0.2, you cannot move your Repository (from the native 18.104.22.168 to) a 10.1.0.3 database.” This is a direct quote from the document on how to uncouple the native database installation – “How to Move a Grid Control Repository to a 10.1.0.3 Database” – Note:285087.1
- Separating the installation allows the database install to be at 64-bit (64-bit OS) and keep the OMS install on 32-bit on a different node (32-bit OS).
- Allows the use of 10.2.0.3+ for the database.
- Allows newly supported platforms.
- Install during DST (patchset has DST fixes)
- Can’t be used to migrate any OMS installation less than 10.2.0.4.
Install Enterprise Edition database 10.1.0.4+ (see Document ID 412431.1 for compatibility). I would recommend using 10.2.0.3+. See “How to Pre-configure a 10g Database to Become the EM 10g Management Repository”-Note:285209.1
If using the GUI installation: Specify full installation type (doesn’t matter what version since you are upgrading to 10.2.0.4 or 10.2.0.5 immediately)– Using an Existing Database Option (note: if init.ora parameters are not at the recommended minimums…this install will fail).
Cookbook for Silent install and Configuring later
Before starting the install of the Base 10.2.0.1 or 10.2.0.2 OMS, repository has already been created, see the Metalink Note in the preceding paragraph. Unzip the installation directories and create the response files (em_using_existing_db.rsp and patchset_oms.rsp, patchset_agent.rsp) in advance using the documentation/Metalink notes as a guide. Double check the variables in the response files because there is no feedback on its success or failure until you run the configure script. Make a copy of the response files before starting, you will need two different sets of a response when patching oms and agent.
./runInstaller -noconfig -silent –responseFile <exact_path>/em_using_existing_db.rsp –force
$OMS_HOME/oraInstRoot.sh (as root, if no previous oracle products installed)
$OMS_HOME/allroot.sh (as root)
Immediately install the 10.2.0.5 patchset (release notes explicitly tell you not to start an unpatched OMS server)
./runInstaller -noconfig -silent -responseFile <exact_path>/patchset_oms.rsp -force
$OMS_HOME/root.sh (as root)
Now patch the agent (the reponse files are different)
./runInstaller -noconfig -silent -responseFile <exact_path>/patchset_agent.rsp –force
$AGENT_HOME/root.sh (as root)
$OMS_HOME/perl/bin/perl $OMS_HOME/sysman/install/ConfigureGC.pl <GC Base Dir>
There is a bug…(imagine that!)
$OMS_HOME/oms10g/sysman/log/emca_repos_drop<serial #>.log file
Could not connect to connect string ORA-01017: Invalid username/passsword: logon denied (DBD ERROR: OCISessionBegin)
ALTER user SYS identified by "default"; (repository database)
$OMS_HOME/perl/bin/perl $OMS_HOME/sysman/install/ConfigureGC.pl <GC Base Dir> (run again it will fail again)
ALTER user SYS identified by “realpassword”; (repository database)
$OMS_HOME/perl/bin/perl $OMS_HOME/sysman/install/ConfigureGC.pl <GC Base Dir> (run again it should work this time to completion)
Note.763314.1How to Install Enterprise Manager Grid Control 10.2.0.5.0 Using a New Database with the Software Only Method
Note.763347.1 How to Install Enterprise Manager Grid Control 10.2.0.5.0 Using an Existing Database with the Software Only Method:
Note.793870.1How to Install Grid Control 10.2.0.5.0 on Enterprise Linux 4 Using the Existing Database (11g) Option
Note.784963.1 How to Install Grid Control 10.2.0.5.0 on Enterprise Linux 5 Using the Existing Database (11g) Option