In this Document
  Goal
  Solution
  References

Applies to:

Goal

This procedure is for Oracle Enterprise Linux 5.3 x86, but the principle is applicable to all platforms with a base product version available. Nevertheless, other platforms may show slight differences in the configuration required to complete a successful installation. Likewise, different stage sources may result in a different filepath to required locations in the staged software, so adjust accordingly.

The software-only method of installation, first offered in version 10.2.0.4.0, allows;

- Installation with an existing database of a variety not supported with the base product
- Achieving a DST-compliant installation of the agent (from any Grid Control installation type) prior to initial startup

The procedure for version 10.2.0.5.0 is presented here.

.
Note that filepath designations such as .../oms10g and .../agent10g are relative, represent generic locations, are for descriptive use only and indicate that the Parent Directory should be prepended to arrive at a usable filepath value. A descriptive character string such as .../agent10g" should never be used in an installation exercise. The same is true for .../oraInventory, but in this case, the filepath to be prepended may not be the Parent Directory, rather the actual value should be that described in the /etc/oraInst.loc file.

For this exercise, the following configuration is used in the example:

Values used in response files and command executions must be altered if a different configuration is used. These values are for demonstration use only and should be changed to be applicable to the system receiving the installation.

Solution

Database Prerequisites:

All of the requirements of the Grid Control installation with a new database must be met as described in the Oracle Enterprise Manager Grid Control Installation Guide, 10g Release 5 (10.2.0.5.0). This document describes general (i.e, must be an enterprise edition with fine grained access control active) and specific (i.e., initialization parameters) requirements for the existing database. Note that a default enterprise edition database installation is not sufficient for use as a Grid Control repository due to these general and specific requirements, but must be configured to meet them.

Additionally, the database must be free of any prior repository contents, whether for Database Control or Grid Control. Use emca, RepManager or the manual procedure in Note 278100.1 to remove an existing repository before installing Grid Control with the existing database. Use of the emca utility is described in chapter 1 of Oracle Enterprise Manager Advanced Configuration, 10g Release 5 (10.2.0.5). Use of RepManager is described in chapter 9 of the same document, available on the OTN Enterprise Manager documentation site.

Lastly, the database must be a version currently certified for database support and use as a Grid Control repository as shown on the Certify section of My Oracle Support. Note that a separate instruction for the 11g database instance in use as a repository is provided in references available from Note.763351.1 Documentation Reference for Grid Control 10.2.0.5.0 Installation and Upgrade.

Special attention must be paid to the repository database in certain versions. See Note 853691.1 "ALERT: Important Upgrade Steps Required for Enterprise Manager Grid Control 10gR5 (10.2.0.5) Upgrades" for pre-patch installation maintenance requirements for the affected database versions.

To install Enterprise Manager Grid Control using a new database with the silent, software-only method, follow these steps:


A. Install Source Staging and Response File Preparation

1. Place the base product install stage for Linux (10.2.0.1.0) in an accessible directory: i.e., /u02/gc10201

2. Modify the base install response file for the "Grid Control with an existing database" install type, located at:

 Generic filepath form:

3. Alter the following parameters from default as follows (archive this file before alterations):

4. Place the 10.2.0.5.0 Grid Control patchset in a different staging location, i.e., /u02/gc10205

5. Make a copy of the patchset response file.located at:

/u02/gc10205/3731593/Disk1/response/patchset.rsp

generic filepath form:

> /3731593/Disk1/response/patchset.rsp

6. Rename the copy in place to oms_patchset.rsp.

Alter the following parameters from default as follows in the oms_patchset.rsp file:

7. Make a copy of the patchset response file located at:

generic filepath form:

8. Rename the copy in place to agent_patchset.rsp.

9. Alter the following parameters from default as follows in the agent_patchset.rsp file:

B. Product and Patchset Installation without Configuration

1. Install the base release (10.2.0.1.0) for Linux using the following command:

generic command form:

Note:

Use the -force option if installing into a parent directory that is not empty..

Base product installation will be logged in two installActions.log files located in:

In addition, the installActions.log for each component is located in:

These two installActions.log files will represent the installations of the oms10g and agent10g Oracle Homes in time sequence. Note that the configuration assistant content normally to be found in the agent installActions<>.log (last in the time sequence) will be missing due to the -noconfig option used in the runInstaller command.

2. Log in as a root user in a new command session and run the following scripts on the host where you installed the base release of Enterprise Manager Grid Control, when prompted by the installer:

If this is the first Oracle product you just installed on the host (i.e., no /etc/oraInst.loc file exists yet), then run the oraInstroot.sh script from the Central Inventory:

Run the allroot.sh script from the Oracle home directory of the database:

3. Certain opmn processes will be running merely as a result of installation, in spite of the fact that no configuration of the OMS Oracle Home has been performed. Stop these OPMN processes by running the following command from the Oracle Home directory of the OMS:

4. Apply the 10.2.0.5.0 patchset to OMS:

generic command form:

Logging for the oms patchset application will be in the installActions.log for the patchset application found in either of these locations:

The installActions.log for the OMS patchset application will be later in timestamp than the two files created during installation. Again, no configuration assistant logging will be included due to the -noconfig option used in the runInstaller command.

5. Run the root.sh command:

No feedback will be given on successful execution in this case.

6. Apply 10.2.0.5.0 patchset to Agent:

generic command orm:

Logging for the agent patchset application will be in the installActions.log for the patchset application found in either of these locations:

The installActions.log for the agent patchsest application will be later in timestamp than the two files created during installation or the file created during oms patchset application. Again, no configuration assistant logging will be included in the associated installActions.log due to the -noconfig option used in the runInstaller command.

7. Run the root.sh command as root:

C. Configuring the Gid Control Installation with the ConfigureGC.pl Script

1. Ensure that the .../oms10g/oui/bin/runConfig.sh file has execute permission.

2. Use the following procedure to preserve and set the PERL5IB environment variable:

Make a backup of the PERL5LIB variable value:

Set PERL5LIB:

3. Configure Enterprise Manager Grid Control by running the ConfigureGC.pl script:

generic command form:

Logging for this action will start in the:

As the configuration assistants are run through the progress of the script, ORACLE_HOME/cfgtoollogs/cf**/ files will begin to populate with the results of these configuration actions for each Oracle Home in its respective directory (i.e., .../oms10g/ or .../agent10g/). As operational actions (i.e., process start) are taken in the configuration steps, operational logs will be populated in these locations:

amongst others.

4. The configuration may take around an hour with little session update at times.
It may be instructive to follow the progress of the configuration in these files:

5. At the point where the OMS Configuration Assistant runs and accesses the repository database to perform a repository drop in preparattion for the new repository creation, database access may fail with ORA-01017 as logged in the .../oms10g/sysman/log/emca_repos_drop.log file:

This problem is discussed in Note.602750.1 ConfigureGC.pl Reports - Invalid Username/Password.
Note that in this case, the respository objects have not yet been touched, hence the CA may be run again after a correction:
Log on to the database as SYSTEM, and issue this literal upate:

Run the configuration command again, as before:

In this case, the repository creation will be successful but the configuration action will fail later, in one of the last actions, a patch upgrade to the repository, again with the ORA-01017 (seen in the latest .../oms10g/cfgtoollogs/cf**/CfmLogger.log file). To correct:

Log on to the database as SYSTEM, and issue this upate:

Generic command form:

Run the confiugration command yet again as before:

This last configuration command should run to successful completion after the repository upgrade action is complete.

6. Successful finish of the last configuration script will be denoted by this messaging in the command session (ignore date):

7. Verify the 10.2.0.5.0 component version for the OMS in any of these ways:

8. Verify the OMS' new Application Server version (10.1.2.3.0) in any of these ways:

9. Verify the 10.2.0.5.0 component version for the agent in any of these ways:

10. Review the post patch requirements of  Note 853691.1 "ALERT: Important Upgrade Steps Required for Enterprise Manager Grid Control 10gR5 (10.2.0.5) Upgrades" for OMS and agent patching requirements of the 10.2.0.5.0 version. This is also a good time to apply the pre-patch database maintenance actions from this note, if appropriate, if this was not done before 10.2.0.5.0 patchset application to the OMS.

D. Potential Pitfalls:

Database bug 5345437 may be encountered after patched agent startup. This bug prevents the agent from completing upload at some point, after initial upload success. The agent will continue to operate, but cannot upload further and cannot upload on restart. Applying the 5345437 database bugpatch to the repository database will allow the agent to continue to upload regularly. This patch is only available for certain database versions, so upgrade may be necessary.

E. Published Documentation References:

Oracle Enterprise Manager Grid Control Installation Guide
10g Release 5 (10.2.0.5.0)

Oracle Enterprise Manager Advanced Configuration
10g Release 5 (10.2.0.5)

Oracle Enterprise Manager Grid Control Release Notes for Linux and Microsoft Windows
10g Release 4 (10.2.0.5.0)

References