| Oracle® Enterprise Manager Grid Control Installation and Configuration Guide 10g Release 5 (10.2.0.5.0) Part Number E10953-15 |
|
|
View PDF |
| Oracle® Enterprise Manager Grid Control Installation and Configuration Guide 10g Release 5 (10.2.0.5.0) Part Number E10953-15 |
|
|
View PDF |
This chapter describes how an existing Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher release can be upgraded to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) or higher. For example, you can use the instructions outlined in this chapter to upgrade an existing Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) for Linux to Enteprise Manager 10g Grid Control Release 2 (10.2.0.1) for Linux.
A full release refers to the first, complete, base Enterprise Manager 10g Grid Control software that was released for a particular platform. A full release comprises all three components that form Enteprise Manager Grid Control, mainly OMS, Oracle Management Repository, and Oracle Management Agent. For more information about full releases, see Understanding What This Guide Helps You Install and Upgrade.
With the option of deploying the Enterprise Manager Grid Control (Grid Control) environment across the enterprise and in any number of permutations, upgrading the entire environment becomes a very complex activity involving updating of software and configurations in different levels (tiers) located in different machines.
The Grid Control Upgrade process aims at simplifying this entire operation and rendering it as seamless and error-free as possible.
Caution:
This chapter helps you upgrade an Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher release to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) or higher.
This chapter does not deal with patching procedures that help you patch a release of Enterprise Manager 10g Grid Control. For example, patching any 10.2.0.1 release to 10.2.0.2 release. Although there is basic information in this chapter, the actual patching procedures are furnished in the Patch Set Notes document that is packaged with the Patch Set, not in this guide. You can download the Patch Sets and the relevant Patch Set Notes from My Oracle Support (formerly Metalink).
The following topics are covered in this chapter:
Enterprise Manager 10g Grid Control Release 2 (10.2.x.x) installer upgrades only the corresponding Enterprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher components. Table 22-0 lists the supported component versions:
Table 22-1 Supported Component Versions that Correspond to the Installation Type
| Installation Type | OMS Version | Database Version |
|---|---|---|
|
Enterprise Manager Using New Database |
10.1.0.4 and higher (with Application server 9.0.4) |
9.0.1.5 |
|
Enterprise Manager Using Existing Database |
10.1.0.4 and higher (with Application server 9.0.4) |
9.2.0.6 or higher |
|
Additional Management Service |
10.1.0.4 and higher (with Application server 9.0.4) |
containing the 10.1.0.4 or higher OMS schema |
|
Additional Management AgentFoot 1 |
Not Applicable |
Not Applicable |
Footnote 1 The supported Management Agent version is 10.1.0.3 and higher.
This section lists the checks you must perform before starting any of the Enterprise Manager 10 Grid Control Release 2 (10.2.x.x) upgrade scenarios as discussed in the following sections.
You must ensure that the existing Grid Control processes are shut down before starting the upgrade process.
To shut down Grid Control, execute the following commands:
<OMS Oracle_Home>/opmn/bin/opmnctl stopall <AGENT_HOME>/bin/emctl stop agent <OMS Oracle_Home>/bin/emctl stop em
Note:
Ensure you shut down all instances of the OMS that are uploading to the same repository.These commands usually successfully shut down all Grid Control processes that are running. However, there may be instances where some processes might still be left running. Such instances may cause the upgrade to fail. To avoid this, you must ensure the following processes are not running before attempting to start the upgrade process:
OPMN
DCM
Note:
Ensure that all OMS instances uploading to the same repository are shut down before the upgrade. Such OMS instances must be upgraded simultaneously.The <Oracle_Home>/Apache/<component> configuration files must be examined to ensure only hard links (and no symbolic links) were referenced.
As part of the Enterprise Manager 10g Release 2 (10.2) Upgrade from 10.1, the underlying Oracle9iAS release 9.0.4 stack is also upgraded. During this phase, the upgrade utility attempts to replace the 10g Release 1 Oracle home path that is referenced in these configuration files with the new Enterprise Manager 10g Release 2 ORACLE_HOME path.
If you have customized the Oracle9iAS release 9.0.4 stack using symbolic links to the Oracle home, then the configuration files may also contain these references as symbolic links, instead of the complete path of the Oracle home.
For example, <Oracle_Home>/Apache/modplsql/conf/plsq.conf contains references to the plsql_module. If this path is a symbolic link, you must modify this path to be a hard link.
If there have been any middle-tier customizations files that cannot be accessed using the upgrade user's credentials, ensure such customizations are removed or commented out before starting the upgrade. You can reapply these customizations after the upgrade is successfully completed.
Also ensure you (use performing the upgrade) have read and write permissions on /temp/em.
If you have previously upgraded the database (from 9i to 10g) manually, you must recompile the EMD_MAINTENANCE package. To do this:
Shut down the OMS that is associated with the database.
Execute SQLPLUS into the upgraded database as SYSMAN.
Execute alter package EMD_MAINTENANCE COMPILE BODY; ensure this package has been recompiled successfully.
Now, start the OMS.
Ensure the <Oracle_Inventory>/ContentsXML/inventory.xml file to make sure the Oracle home path is the same as the components that you are upgrading.
Note:
These paths must always be hardlinks.During the upgrade process, you can choose not to specify the Agent Registration password. This leaves the upgraded agent unsecure. The installer displays an error message when the agent's REPOSITORY_URL does not match with that of the OMS, indicating the agent is not bound to the OMS.
This can happen if multiple OMSs are grouped together through a load balancer, and the agent is using this load balancer to communicate with the OMSOMS.You can also choose to secure the upgraded agent manually after the agent has been upgraded.
If the current Enterprise Manger installation (10g Release 1) was performed using a new database, the 10g Release 2 (10.2) upgrade process will first attempt to upgrade Oracle Database if it has not already been upgraded manually.
In an Enterprise Manager Grid Control 10g Release 1 (10.1) installation using a new database, the installer performs a release 9.0.1.5 Oracle Database installation along with the other Grid Control components. When you upgrade Grid Control release 10.1 to release 10.2, the database instance is upgraded to a release 10.1.0.4 before the Grid Control migration configuration is performed.
To successfully migrate your existing Grid Control to release 10.2, the new 10.1.0.4 database listener has to be started. To do this, you must simply stop the old (release 9.0.1.5) database listener just prior to executing the allRoot.sh script.
After you stop the old listener and execute the allRoot.sh script, the release 10.1.0.4 listener will be started automatically.
WARNING:
Do not shut down the database listener if you are attempting to upgrade a Grid Control installation that was performed using an existing database. The upgrade will fail if the database listener is shut down.
Note:
On Microsoft Windows, you must modify the start-up type value of the old listener to Disable, and the start-up type value of the new listener to Automatic after the upgrade process is complete.During a Grid Control upgrade from 10g R1 to 10g R2, there will be some modifications to the default port values.
For example, port 1158 will no longer be used for communications between the OMS and the agent. similarly, the default port for the OMS and agent communications will now (in 10g R2) be 3872 and not 1830 (as in 10g R1) though the 1830 port will still be valid.
The Grid Control upgrade operation will preserve the ports that were being used in the original deployment. Hence, additional ports will not be required even if Grid Control was originally deployed with a firewall.
Similarly, you will not have to perform any modifications to the software load balancer (SLB) configurations after the Grid Control upgrade.
Ensure that the database where the Management Repository is configured has the Partitioning Option enabled. To verify this, connect to the database as SYSDBA and run the following query:
SQL> select value from v$option where parameter = 'Partitioning';
The result of this query should be VALUE=TRUE.
Note:
No additional partitioning license is required for Oracle Database that houses the Management Repository.Before you begin any upgrade or patching process, ensure that you back up the database. This helps you maintain a copy of the database that was existing before the environment was upgraded and it naturally gives you the flexibility to revert to it whenever you want.
Before you begin any upgrade or patching process, configure SUDO in your environment. If you are unable to configure SUDO in your environment or if you have already upgraded any of the core components (OMS or Management Agent) without configuring SUDO, then follow the workaround described in My Oracle Support note 789363.1.
The following sections explain the configuration tasks to be performed for upgrading Enteprise Manager 10g Grid Control Release 1 (10.1.0.4 or higher) to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x or higher).
Also explained are tasks to be performed for patching Enterprise Manager 10g Grid Control Release 2. For example, tasks to be performed before migrating from Enterprise Manager Grid Control 10.2.0.1 (Linux) to 10.2.0.2 (Linux) or higher.
Caution:
This section does not deal with patching procedures that help you to migrate from one patch release of Enterprise Manager 10g Grid Control to another. For example, patching any 10.2.0.1 release to 10.2.0.2 release. Although there is basic information in this section, the actual patching procedures are furnished in the Patch Set Notes document that is packaged with the Patch Set. You can download the Patch Sets and the relevant Patch Set Notes from My Oracle Support (formerly Metalink).The following sections describe how you can upgrade Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher release to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) or higher.
The following steps describe the tasks to be performed before upgrading Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher release to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) or higher. For example, before upgrading an existing Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) for Linux to Enteprise Manager 10g Grid Control Release 2 (10.2.0.1) for Linux.
Note:
Before you begin any upgrade process, ensure that you back up the database.Shutdown all OPMN processes and agents.
Perform Grid Control partition cleanup. To do this, log into the database using SQLPLUS with SYSMAN credentials. At the SQL> prompt, execute the following command:
SQL>exec emd_maintenance.partition_maintenance;
Apply fix for index/constraint issues. To do this, log into the database using SQLPLUS with SYSMAN credentials. At the SQL> prompt, execute the following commands:
SQL>Alter table MGMT_JOB_TYPE_INFO disable constraint PK_JOB_TYPE_INFO cascade drop index; SQL>Alter table MGMT_JOB_PARAMETER disable constraint PK_MGMT_JOB_PARAM cascade drop index; SQL>Alter table MGMT_TARGET_PROP_DEFS disable constraint MGMT_TARGET_PROP_DEFS_PK cascade drop index; SQL> Alter table mgmt_license_definitions disable constraint mgmt_license_definitions_pk cascade drop index; SQL> ALTER TABLE mgmt_annotation DISABLE CONSTRAINT mgmt_annotation_pk cascade drop index;
Check and enable the queue MGMT_NOTIFY_Q if it is not enabled. To do this, log into the database using SQLPLUS with SYSMAN credentials. At the SQL> prompt, execute the following commands:
SQL> select OWNER, NAME, ENQUEUE_ENABLED from dba_queues where name='MGMT_NOTIFY_Q'; If ENQUENE_ENABLED is NOT "YES", then exec dbms_aqadm.start_queue(queue_name => 'SYSMAN.MGMT_NOTIFY_Q');
The following steps describe the tasks to be performed for upgrading Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) or higher release to a full release of Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) or higher. For example, for upgrading an existing Enteprise Manager 10g Grid Control Release 1 (10.1.0.4) for Linux to Enteprise Manager 10g Grid Control Release 2 (10.2.0.1) for Linux.
Using the shiphome, invoke OUI with -noconfig option as follows:
./runInstaller -noconfig
When prompted for upgrade options, choose both OMS and Agent for upgrade. Enter valid input values for the installation. OUI will perform a software-only install as described in Grid Control Upgrade.
After the software-only install, replace the pre_post_creation.sql file that is available in the upgraded release's directory with the pre_post_creation.sql extracted from the patch for bug# 5666424.
For example, if you are upgrading from 10.1.x.x to 10.2.0.1, then replace the $ORACLE_HOME/sysman/admin/emdrep/sql/core/v102010/pre_post_creation.sql file with the pre_post_creation.sql file extracted from the patch for bug# 5666424.
Run the following command to launch the Configuration tool to complete the upgrade.
If the older OMS was installed using "Enterprise Manager 10g Grid Control Using an Existing Database' install type or if it was an additional OMS installation, then run the following command:
$NEW_OMS_HOME/oui/bin/runConfig.sh ORACLE_HOME=<OMS HOME> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}
If the older OMS was installed using "Enterprise Manager 10g Grid Control Using a New Database", then run the following command:
$NEW_OMS_HOME/oui/bin/runConfig.sh ORACLE_HOME=<OMS HOME> MODE=perform ACTION=configure COMPONENT_XML={encap_emseed.1_0_0_0_0.xml}
The following sections describe the tasks to be performed for patching Enteprise Manager 10g Grid Control Release 2 (10.2.x.x).
The following steps describe the tasks to be performed before patching Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) to another patch set release of 10.2.x.x. For example, before patching the existing Enteprise Manager 10g Grid Control Release 2 (10.2.0.1) for Linux to Enteprise Manager 10g Grid Control Release 2 (10.2.0.2) for Linux, using the 10.2.0.2 patch set that was released for Linux.
Note:
Before you begin any upgrade process, ensure that you back up the database.Using the 10.2.x.x Grid Control Patch Set, invoke OUI with -noconfig option as follows:
./runInstaller -noconfig
OUI will perform a software only install.
After the software only install, replace the pre_data_upgrade.sql file available in the upgraded release's directory with the pre_data_upgrade.sql file extracted from the patch for bug# 5666424.
For example, if you are patching 10.2.0.1 Linux to 10.2.0.2 Linux, then replace the $ORACLE_HOME/sysman/admin/emdrep/sql/core/v102020/pre_data_upgrade.sql file with the pre_data_upgrade.sql file extracted from the patch for bug# 5666424.
Run the following command to launch the Configuration tool to complete the upgrade.
OMS_HOME/oui/bin/runConfig.sh ORACLE_HOME=<OMS_HOME> ACTION=patchsetConfigure MODE=perform RERUN=true COMPONENT_XML={oracle.sysman.top.oms.10_2_0_x_0.xml}
Also:
To prepare yourself better for a patching operation, Oracle recommends you to read the patching checklist that is available as Document ID 464674.1 on My Oracle Support (formerly Metalink) at:For patching Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) to another patch set release of 10.2.x.x, follow the installation/patching steps provided in the Patch Set Notes or Release Notes that is packaged with the 10.2.x.x Patch Set.
When you patch multiple OMSs, after the first OMS gets patched, it restarts itself automatically, leaving the other OMSs shut down. At this point, DO NOT restart the other OMSs until you apply the latest patch on them.
Note:
While patching the install types "Enterprise Manager Grid Control Using a New Database" and "Enterprise Manager Grid Control Using an Existing Database" to 10.2.0.4, you might have to apply the RDBMS patch 4329444. However, this patch might conflict with some previous CPU releases (for example, April 2007 CPU) that might be applied to your repository database.In case of a conflict while applying patch 4329444, DO NOT continue with the patching process. Contact Oracle support to first resolve the patch conflict and then follow the steps outlined in the Oracle Enterprise Manager Grid Control Release Notes for Linux and Microsoft Windows 10g Release 4 (10.2.0.4.0) available in the document library at:
After patching any Enteprise Manager 10g Grid Control Release 2 (10.2.x.x) to another patch set release of 10.2.x.x, ensure that you download the Clone Support Files from My Oracle Support (formerly Metalink) and install them on each OMS. This is to enable clone support for many major releases of Oracle Tech stack components. The Clone Support Files are available on My Oracle Support (formerly Metalink) as one-off patches.
The concept of Cloning in Grid Control helps you clone any installed Oracle home that is recognized as a clonable home by Grid Control. This means you can clone the installed Oracle homes of most Oracle products as is, without having to install any additional support files. Table 22-2 shows the Oracle products that can be cloned as is. However, there may be Oracle homes that are not recognized as clonable homes by Grid Control. For such Oracle homes, you must patch Grid Control with appropriate Clone Support Files before starting the cloning operation.
The following Oracle products can be cloned as is, without Clone Support Files. Any other Oracle home that is not mention in this table needs Cloning Support Files.
Table 22-2 Oracle Products That Can Be Cloned As Is
| Oracle Product | Release |
|---|---|
|
Oracle Database |
10.1.x and 10.2 |
|
Oracle RAC Database |
10.1.x and 10.2 |
|
Application Server |
10.1.2.0.0, 10.1.2.0.2 |
|
Oracle Clusterware |
10.2 |
To locate these Clone Support Files at My Oracle Support (formerly Metalink):
Access http://metalink.oracle.com/ and navigate to the Advanced Search option under Patches and Updates.
Select the Enterprise Manager Grid Control (emgrid) product from the list.
Select the appropriate release, platform, and patch type.
Enter "Clone Support Files" in the Description field, and click Search. The Patch Release Notes include instructions for installing the updated clone support files in the OMS home.
The following upgrade scenarios are discussed in this section:
Upgrading Oracle Management Service that Is Installed Using a New Database
Upgrading Management Service that Is Installed Using an Existing Database
Caution:
During the upgrade process, you must ensure the monitoring agent is also upgraded along with the OMS and repository database
Ensure that you back up the database before upgrading your environment.
Unless you are instructed, DO NOT remove or modify any of the OMS files.
If the Enterprise Manager 10g Release 1 (10.1) was of this installation type, then the 10g Release 2 (10.2) installer performs an out-of-place upgrade of the release 10.1 OMS, the repository database, and the agent Oracle homes. During the upgrade, the installer creates a new Oracle home for the OMS, Management Repository, and Management Agent. The upgrade assistants upgrade the datafiles and SYSMAN schema, and then configure the new Oracle homes.
Caution:
Before you start the upgrade process on Microsoft Windows, ensure the parameterSQLNET.AUTHENTICATION_SERVICES value is NTS (SQLNET.AUTHENTICATION_SERVICES=NTS). If this is not done, the Database Upgrade Assistant will fail.
You must also ensure that the listener is running, and the SQL command (sqlplus "/as sysdba") is connecting to the database.
If the earlier Grid Control installation was done using an existing database, the 10g Release 2 installer automatically checks the remote database version (must be release 9.2.0.6 or later). If the minimum database version requirement is met, the installer not only performs an upgrade of the OMS but also upgrades the SYSMAN schema in the remote database.
Note:
If the database version is lower than release 9.2.0.6, this database is not upgraded as part of the Grid Control upgrade process. You are required to upgrade the database separately, before proceeding with the OMS upgrade process.Caution:
If you are upgrading a Grid Control target (for example, database) using an upgrade mechanism other than Oracle Universal Installer, the agent you have selected must also be part of the same installation (is the agent associated with that OMS). See Monitoring Agent Does Not Discover Upgraded Targets for more information.If the previous Grid Control installation was for an additional OMS, the 10g Release 2 installer checks the remote database (must be release 9.2.0.6 or later). If this minimum database release requirement is met, the installer performs the Management upgrade.
If you are upgrading only the OMS to 10g Release 2 (10.2) without upgrading the monitoring agent (agent associated with that OMS), you may encounter a metric collection error. To resolve this issue, you must upgrade the monitoring agent to 10g Release 2 as well.
Oracle recommends upgrading the OMS and the associated (monitoring) agent at the same time.
Caution:
Ensure you shut down the OMS that you are going to upgrade, and its associated (monitoring) agent before starting the upgrade process.Note:
If the database release is earlier than 9.2.0.6, this database is not upgraded as part of the Grid Control upgrade process. You are required to upgrade the database separately, before proceeding with the OMS upgrade process.Caution:
After successfully upgrading the 10g Release 1 (10.1.0.4) OMS to release 10.2, the 10.1.0.4 agents that are uploading data to this OMS may show an incorrect OMS version when you execute./emctl status agent.
To resolve this issue, you must stop the 10.1.0.4 agents (./emctl stop agent) and restart them (./emctl start agent).
All agent Oracle homes that need to be upgraded are detected and displayed in the Select Install or Upgrade screen of the installer. You can select the agent Oracle homes that you want to upgrade and proceed with the process.
Note:
The agent Oracle homes that are installed as part of the first two installation types are not upgraded automatically along with the OMS Oracle homes. You must select the agent home that you want to upgrade. This agent home can be independent of the OMS home.Because the Management Agent upgrade process is an out-of-placeFoot 1 installation, upgrading an agent will create a new agent Oracle home directory. If you are using OS-based user-defined metrics that are referencing scripts located in an agent Oracle home, then such scripts will not be copied over during the upgrade process. Specifically, if a release 10.1.0.4 agent is being upgraded to release 10.2 agent, any user-defined metric scripts that may have existed in the 10.1.0.4 agent Oracle home will not be copied into the new 10.2 agent Oracle home.
In order to ensure the user-defined metrics continue to work the same, you must manually copy all user-defined metrics scripts into another directory (outside any Oracle home), and then update the user-defined metric definitions to reflect the new script location.
For example, if the user-defined script is called myScript.sh and is located in the 10.1.0.4 agent Oracle home (for example, /u1/oracle/sysman/admin/scripts directory), copy this script over to a new directory (for example, /u1/scripts). Now, in the definition of the user-defined metric, you must change the command line from /u1/oracle/sysman/admin/scripts/myScript.sh to /u1/scripts/myScript.sh.
Note:
Ensure you do not delete the original Oracle home (that is 10.1.0.4 Oracle home in the preceding example) until you have changed the user-defined metric script location.When you invoke Oracle Universal Installer to perform an upgrade, it automatically detects the existing Grid Control installation type of the target Oracle homes and displays the components that need to be upgraded. You can select the component that you want to upgrade and proceed with the process.
Caution:
Oracle recommends that you perform a backup of the repository before starting the upgrade process.To upgrade Grid Control using Oracle Universal Installer (OUI), follow these steps:
Start Oracle Universal Installer by running the runInstaller script in Linux (go to the top-level folder in the contents copied from the DVD and execute ./runInstaller or setup.exe on Microsoft Windows) from the top directory of Disk1.
When you invoke Oracle Universal Installer, you will be presented with two choices:
Perform a new Enterprise Manager Grid Control installation
See Understanding the Installation Types for more information.
Products Upgrade
Select this option to continue with the upgrade process.
Click Products Upgrade. The Select Install or Upgrade screen appears.
The installer automatically detects the Grid Control components that require an upgrade and lists them in this screen.
Here, you can choose to perform the following upgrades:
OMS and the associated (monitoring) Management Agent
Only the OMS
Only the Management Agent
Caution:
If you are upgrading both OMS and Agent (which is part of a chain agent installation), ensure the agent you have selected is the one that is communicating with selected OMS.Also, ensure you shut down the agent and the OMS that you are going to upgrade, before starting the process.
Select the Oracle homes that you want to upgrade and click Next. The Specify Installation Location screen appears.
Here, specify a parent directory (base directory), for example, /scratch/OracleHomes, for the new installation. because the installer is going to perform an out-of-placeFoot 2 upgrade, all the Oracle homes created during the upgrade will be placed as subdirectories under this parent directory.
Click Next. The Product-Specific Prerequisite Checks screen appears.
At this point, the installer runs some prerequisite checks to verify whether or not the environment meets the minimum requirements for a successful Enterprise Manager installation.
Early detection of problems with the system setup reduces the chances of you encountering problems during installation; for instance, problems with insufficient disk space, missing patches, inappropriate hardware, and so on.
This page displays the check name, type, and status for all prerequisite checks designed for the installation. Automatic checks are run first, followed by optional and manual checks.
Depending on the status of the automatic checks, you must verify all warning and manual checks. At some point, if you have stopped the prerequisite check and want to rerun these checks, select the checks that you want to rerun and click Retry. As each check runs, a progress bar is shown, and test details (expected results, actual results, error messages, instructions) are displayed in the details section, at the bottom of the page.
To stop all prerequisite checks, click Stop. At any point of time, click a prerequisite check to view its corresponding details, including the recommended user actions.
Note:
You must manually verify and confirm all checks that were flagged with a warning, skipped (stopped by user), or failed.To continue with the installation without retrying, click Next.
The Specify Configuration screen appears.
Here, you must specify the existing Database and Secure OMS passwords. The Database Password (SYS) is required to access the configuration files of the existing database repository that is associated with the OMS that you have selected for upgrade.
In the Database password section, specify the SYS Password (the default super administrator account) for the existing database repository that is associated with the selected OMS.
In the Management Service Security section, specify a password that will be used to secure the communications between the OMS and its agents.
Note:
Management Service Security: This section is enabled only when the existing OMS that you are upgrading is not secure.Click Next. If you are upgrading both OMS and Agent, but only the existing OMS is secure and locked, then the Agent Registration Password screen appears. Here, you must provide the correct password to enable communications between the secure OMS and the agent that you are upgrading.
Note:
This screen appears only if the base (existing) agent installation is not secure.Caution:
If you do not know the password and choose to leave the Password field blank, you must do the following after installation, to enable secure communication between the agent and OMS:Find out the correct password for the secure OMS environment. If you do not know the password, obtain it from the user who configured the OMS for SSL.
In the Agent's <ORACLE_HOME>/bin directory, execute the following command:
<AGENT_HOME>/bin/emctl secure agent -reg_passwd <password>
The <passwd> argument must be replaced with the Agent Registration Password. However, note that even after securing the Management Agent, some data might still be transferred over the network without being encrypted.
The Summary screen appears. This screen displays all the Oracle homes that will be created. Depending on the type of upgrade you have selected, this page will display any of the following details:
Global Settings
Product Languages
Space Requirements
New Installations
Verify the choices that you have made, and click Install to start the upgrade.
During theOMS upgrade, the following log files are created:
iasua.log
The Oracle Application Server stack is upgraded by the OMS Upgrade Plugin. This is performed by invoking the IASUA utility. the iasua.log file is created at the following location:
<NEW_OMS_HOME>/upgrade/log/iasua.log
emrepmgr.log.<pid>
This log is created during the schema upgrade. The upgrade output log file is located at:
<NEW_OMS_HOME>/sysman/log/emrepmgr.log.<pid>
Perform the following configuration tasks after the upgrade is complete.
After the OMS upgrade is complete, you must do the following:
Check the <OMS_HOME>/sysman/log/emrepmgr.log.<pid> log file and verify whether or not there were any errors.
Note:
There may be more than one
emrepmgr.log.<pid> file present in the OMS home. Ensure you select the files that were updated most recently.In the log files, examine the last line to see whether or not it indicates Repository Upgrade as successfully completed or as having ended in a failure.
If it shows a failed upgrade, search for any "ORA-" or "compilation" errors.
After OMS upgrade (regardless of whether or not the agent has been upgraded along with it), you must execute agentca with discovery options in order to discover CSA targets.
You can optionally delete the BC4J target of the old OMS home after the OMS upgrade is complete.
You must reset the ias_admin password after the OMS upgrade. The ias_admin password is set as welcome1 by default, during the upgrade process.
If in the Patch Advisories page on the Grid Control console, the patch advisories and affected homes count is showing 0 (zero), do ne of the following:
Execute the following SQL as sysman and then run the RefreshFromMy Oracle Support job. This must be done just once after the upgrade process.
BEGIN
MGMT_POLICY.AUTO_ENABLE_EXISTING_TARGETS(
p_target_type => 'host',
p_policy_name => 'Critical Patch Advisories for Oracle Homes' );
END;
Go to the Targets tab in the console and click Hosts. On this page, click the Metric and Policy Settings link for a host. Now, go to the Policies tab and click Add Policy. Here, select the CPF policy and associate it to the target.
After the upgrade, if you find the links under the Web Application tasks tab (under Monitoring Configuration) in the console disabled, it means that the Application Server diagnostics pack is disabled after the upgrade. To work around this issue, do the following:
Identify the system associated with the Web Application Enterprise Manager Web site.
Add the new Application Server target as a member of this system.
Mark the new Application Server target as a key component of the Web Application Enterprise Manager Web site.
After the upgrade, if the performance graph is missing, do the following:
Go to the Performance Metrics page under Monitoring Configuration.
Add the metric and select the performance graph to be displayed on the home page. Perform similar tasks for the Usage Metrics also.
You may fin some of the Web site targets in a broken state after the upgrade. They will show up in the All Targets page under the Targets Not Configured list. This does not affect their monitoring in any way. Even though the target is in a "non-configured" state, the availability is still computed and al functions remain in working order.
To prevent these targets from showing up in that list, the user has to run the query provided below, to update a table in the repository. This query must be run after the OMS upgrade is complete.
UPDATE MGMT_TARGETS SET broken_reason = 0, broken_str = NULL, emd_url = NULL,
host_name = NULL
WHERE target_guid IN (SELECT t.target_guid
FROM MGMT_TARGET_PROPERTIES p,
MGMT_TARGETS t
WHERE t.target_guid = p.target_guid
AND t.target_type = 'website'
AND t.broken_reason != 0
AND p.property_name = 'Upgraded'
AND p.property_value = '1');
COMMIT;
After this query completes, the targets will not show up in the Targets Not Configured list.
After the Oracle Database upgrade is complete, you must do the following:
On Microsoft Windows, if you have performed an upgrade on an installation of the type Enterprise Manager Using a New Database, you must manually modify the Listener services to make sure that the old Listener's startup type is set to Disable, and the new Listener's startup type is set to Automatic.
There may be instances where the Enterprise Manager Using a New database installation and its subsequent upgrade encounters an abnormal growth of the ons.log. This can potentially take up a lot of disk space relatively quickly.
In such circumstances, you must check whether or not the ons.log contains repeated messages such as the following:
Local connection 0,127.0.0.1,6100 missing form factor
If such an error message is observed in the ons.log, perform the following steps:
In the Database Oracle home, rename the $ORACLE_HOME/opmn/conf/ons.config file (in order for the Listener not to find the database to sue it). For example,
cd $ORACLE_HOME/opmn/conf mv ons.config ons.config.orig
Restart the Listener.
This sections details some of the diagnostic checks that you should perform along with their resolutions.
Check the appropriate log file to get the facts for this occurrence. The installation dialog and the configuration framework log file is located at:
<New_OracleHome>/cfgtoollogs/cfgfw/oracle.sysman.top.oms_#date.log
This file will list the SEVERE messages indicating the reason that iASUA (Oracle Application Server Upgrade Assistant) failed to complete successfully. If the message shows that "permission denied" on certain files, that means that the user running the installer may not have the correct privileges to run certain iAS configuration.To resolve this issue, comments out the iAS configuration that contains these files, and then retry the upgrade again.
The most common reasons that EMDeploy would fail are because of some pre-upgrade check list items that were not satisfied. The messages in the log file located at:
<New_OracleHome>/cfgtoollogs/cfgfw/oracle.sysman.top.oms_#date.log
This file will indicate the reasons for the EMDeploy failures.
You must resolve the issue in accordance with the pre-upgrade check list items, and then retry the upgrade.
The most common reason that repository schema upgrade fails is when it is not able to connect to the listener. The log file mentioned below would indicate the reason that repository schema upgrade has failed.To fix this issue, you must examine whether or not the listener that the OMS connects to is valid and live. If the OMS is of installation type Enterprise Manager Using a New Database, then you should check whether or not the old listener has been stopped, and the new listener has been started. After the listener issue is resolved, you can retry the upgrade process.
The log file is at the following location:
$ORACLE_HOME/sysman/log/emrepmgr.log.<pid>
You must examine this log file to check whether or not there are any errors.
Note:
There may be more than oneemrepmgr.log.<pid> file present in the OMS home. Ensure you select the files that were updated most recently.In the log files, examine the last line to see whether or not it indicates Repository Upgrade as successfully completed or as having ended in a failure.
If it shows a failed upgrade, search for any "ORA-" or "compilation" errors.
Agent Deploy is a J2EE application that is used for mass deployment of Management Agents.
The Upgrade Agent option in this application will help you upgrade an existing Management Agent installation to a release 10.2 Management Agent.
Note:
If the upgrade operation fails, review the log files described in Appendix C, "Agent Log Files".The following are the prerequisites to be met before upgrading the management agent:
Ensure that the SSH daemon is running on the default port (that is, 22) on all the target hosts.
For Enterprise Manager 10g Grid Control Release 4 (10.2.0.4), the port must be 22. If it is any other port, then the upgrade fails.
For Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), the port can be 22 or any non-default port, that is, any port other than 22. If the port is a non-default port, then update the SSH_PORT property in the following file to ensure successful upgrade of the agent:
<OMS_HOME>/sysman/agent_download/<VERSION>/<PLATFORM>/agentdeploy/Paths.properties
If the central inventory owner and the user upgrading the agent are different, then ensure that they are part of the same group. Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory. For example, if the inventory owner is abc and user installing the agent is xyz, then ensure that abc and xyz belong to the same group, and they have read and write access to the inventory.
Ensure that you have SUDO privileges to run root.sh and /bin/sh.
To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.
<user> <hostname>=PASSWD: /home/em/agent10205/agent10g/root.sh, /bin/sh
Accessing the Agent Deploy Application
To access the Agent Deploy application, follow these steps:
Log in to the Grid Control console and go to the Deployments page.
Click Install Agent under the Agent Installation section.
Click Upgrade Agent to upgrade the Management Agent. Grid Control displays the Agent Upgrade: Installation Details page.
In the Version section of this page, select the appropriate version of the agent software that you want to use for upgrade.
Note:
The values in this list will depend on the staged software that are available on the OMS host.In the Hosts section, do the following:
Select the appropriate platform on which you want to perform this installation.
In the Provide Host List text box, specify all the hosts (host names or IP addresses) on which you want to perform the Agent installation. Alternatively, click Get Host Names From File to browse and select the file that contains a list of all the required host names.
WARNING:
Do not specify duplicate entries of the host list. If there are duplicate host entries in this list, the application hangs.
Use the same host names for which the SSH has been set.
Note:
You can use either a comma (,) or white space as a separator when specifying multiple hosts.Caution:
The Agent Deploy application picks up only the values in the first column of the Host List file that you specify or select.Ensure the host list format is appropriate, since the Agent Deploy application does not validate this format on the selected file.
A sample host list format is provided in Table 22-3.
Select Cluster Upgrade if you want to upgrade the Management Agent cluster.
Note:
The hosts that you specify must belong to the same cluster. Also, note that only the hosts that you specify here will be upgraded, irrespective of the number of hosts in that cluster. For example, if there are 10 hosts in a cluster and you specify only 5 here, Agent Deploy will upgrade only those five hosts in the cluster that you have specified.In the OS Credential section, specify the appropriate operating system user credentials. Select Run root.sh (UNIX platforms only) if you want Agent Deploy to execute this script.
The root.sh script runs after the configuration assistants are run and before the postinstallation scripts (if any) are run. If you do not select this option here, you must run root.sh on each node manually.
Agent Deploy application uses sudo to run the root.sh script. You must specify the invoking user's password here.
If /etc/sudoers is configured in such a way that sudo never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory. To avoid this, ensure that you configure /etc/sudoers file such that running a command using sudo always prompt for a password.
In the Existing Agent Information section, specify the full path to an existing agent Oracle home location. This source agent installation will be used to perform the upgrade.
Note:
The path of the source agent should be the same on all the remote hosts.In the Destination section, specify the absolute path for the Installation Base Directory. This directory will be created on all the specified hosts, and the Agent Oracle home directory will be created as a subdirectory under this directory.
In the Additional Parameters text box, specify any additional parameters that you want to pass during installation.
Oracle recommends you to specify only those parameters that you want to run in addition to the general parameters you have already provided in this page for upgrade. For example, in step (7), you are providing the installation base directory. Therefore, for additional parameters, try to avoid specifying the installation base directory again. If you still do so, then the value you specified in step (7) will be ignored and the value you specified here will be used instead.
The following are the additional parameters you can specify:
Specify -t if you do NOT want to start the Agent after installation or upgrade. No value required.
Specify -d if you do NOT want to initiate automatic target discovery. No value required.
Specify -i if you want to provide an Inventory pointer location file. For example, -i /etc/oraInst.loc.
Specify -p if you want to provide a file location for Static port for Agent. For example, -p /home/config/staticports.ini.
In the Management Server Security section, specify the OMS registration password to secure your communication to the OMS.
In the Additional Scripts section, specify any preinstallation and postinstallation scripts that you want to execute.
Click Continue. Grid Control displays the My Oracle Support Details page.
On the My Oracle Support Details page, do the following:
If the host where the Management Agent is being installed has a direct connection to the Internet, then specify an email address and My Oracle Support (formerly Metalink) password.
An email address is required so that security updates and install updates can be sent. You can specify any email address, but Oracle recommends you to specify the My Oracle Support (formerly Metalink) user name. For example, john.mathew@xyz.com.
If the My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an email address, then you will continue to receive security updates and other notifications from Oracle to that email address.
If the host where the Management Agent is being installed has an indirect connection to the Internet through a proxy server, then specify an email address and My Oracle Support password, and then in the Connection Details section, specify the proxy server details.
Note:
You can change the proxy server settings any time after the installation or patching process ends. To do so, run the
configCCR command from the /ccr/bin/ directory within the Oracle home directory of the Management Agent.If the host where the Management Agent is being installed does not have a direct or indirect connection to the Internet, then specify the email address and leave the other fields blank.
In this case, after you complete the installation process, manually collect the configuration information and upload it to My Oracle Support. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support (formerly Metalink).
Click Continue to start the upgrade process.
The important parameters for Agent Upgrade are -o, -b and optionally -i, -t.
Table 22-4 lists all the possible parameters that you can specify.
To upgrade Management Agent using the agentDownload Script, follow the instructions documented below:
Invoke the agendDownload script using -u option.
The OLD_ORACLE_HOME that you want to upgrade should be specified either by passing the -o option, or setting the OLD_ORACLE_HOME environment variable.
Invoke the agentdownload script using the following command:
./agentDownload.linux -u -o <OLD_ORACLE_HOME_PATH>
For Microsoft Windows, invoke the agentDownload script using the following command:
./agentDownload.vbs -u -o <OLD_ORACLE_HOME_PATH>
Note:
The first two options (-u and -o) are mandatory. The -b option can be skipped if this has already been specified in the response files.To construct the new Oracle home name, either pass the -b option, or specify these values for BASEDIR in the agent_download.rsp file.
Note:
You can specify these options in the command-line even though they are present in the response file. The command-line options will have a higher precedence over the ones in response file.If the base agent that you are upgrading is not secure, the script will prompt you to specify the Agent Registration Password.
You can use the options listed in Table 22-4 to execute the agentDownload script.
Table 22-4 Options that You Can Use To Execute the agentDownload Script
| Options | Description |
|---|---|
|
-b |
baseDirectory of the Agent Oracle home |
|
-l |
local (pass -local to runInstaller) |
|
-n |
Cluster name |
|
-o |
OLD_ORACLE_HOME during Upgrade |
|
-u |
Upgrade |
|
-c |
CLUSTER_NODES (to specify the cluster nodes). For example, "CLUSTER_NODES={node1,node2,node3}" |
|
-p |
|
|
-s |
Installer stage directory |
|
-t |
Do NOT start the Agent |
|
-i |
Inventory pointer location file |
|
-d |
Do NOT initiate automatic target discovery |
Note:
When performing an Management Agent upgrade using theagentDownload script, ensure you are using the agentDownload script from the Oracle home of the pointing OMS.
For example, if you are upgrading agent1 that is pointing to OMS A, then you must use the agentDownload script that is located in the OMS A Oracle home only.
Caution:
If you are upgrading a non-secure agent to a secure mode, the script will prompt you to specify the Agent Registration Password. Specify the correct password to secure the upgraded agent.Note:
If the upgrade operation fails, review the log files described in Appendix C, "Agent Log Files".Each node that is going to be part of your Oracle Real Application Clusters (Oracle RAC) installation must meet the following hardware and software requirements. You will perform step-by-step tasks for hardware and software verification for the platform-specific preinstallation procedures.
Each node in a cluster requires the following hardware:
External shared disks for storing the Oracle Clusterware files.
Refer to the respective Oracle RAC installation guides for information on the disk configuration options that are available. Review these options before you decide which storage option to use in your Oracle RAC environment.
One private internet protocol (IP) address for each node to serve as the private interconnect. The following must be true for each private IP address:
– It must be separate from the public network.– It must be accessible on the same network interface on each node.– It must have a unique address on each node.The private interconnect is used for internode communication by both Oracle Clusterware and Oracle RAC. If the private address is available from a domain name server (DNS), then you can use that name. Otherwise, the private IP address must be available in each node's /etc/hosts file.
On Microsoft Windows, this IP address must be available at the following location on each node:
C:/Windows/<system drive>/etc/hosts file
During Oracle Clusterware installation, the information you enter as the private IP address determines which private interconnects are used by Oracle RAC database instances. They must all be in an up state, just as if their IP addresses were specified in the initialization parameter, CLUSTER_INTERCONNECTS. Oracle Real Application Clusters does not fail over between cluster interconnects; if one is down, then the instances using them will not start.Oracle recommends that you use a logical IP address that is available across all private networks, and that you take advantage of any available operating system-based failover mechanism by configuring it according to your third-party vendor's instructions for using their product to support failover.
One public IP address for each node, to be used as the Virtual IP address for client connections and for connection failover.
This public Virtual IP address must be associated with the same interface name on every node that is part of your cluster. In addition, the IP addresses that you use for all of the nodes that are part of a cluster must be from the same subnet. If you have a domain name server (DNS), then register the host names for the Virtual IP with the DNS. The Virtual IP address should not be in use at the time of the installation, because this is a Virtual IP address that Oracle manages.
One public fixed hostname address for each node, typically assigned by the system administrator during operating system installation. If you have a DNS, then register both the fixed IP and the VIP address with the DNS. If you do not have a DNS, then you must make sure that both public IP addresses are in the node host file.
If you have a DNS, then you should be able to use DNS to resolve the name of the host on which you want install OMS. For more information, contact your network administrator.
Each node in a cluster requires a supported interconnect software protocol to support Cache Fusion, and to support Oracle Clusterware polling. Your interconnect must be certified by Oracle for your platform. You should also have a Web browser, both to enable Grid Control, and to view online documentation. For Oracle Database 10g requirements, Oracle Clusterware provides the same functions as third-party vendor clusterware. Using Oracle Clusterware also reduces installation and support complications. However, you may require third-party vendor clusterware if you use a non-ethernet interconnect, or if you have deployed clusterware-dependent applications on the same cluster where you deploy Real Application Clusters.
See Chapter 14, "Prerequisites for Installing Enterprise Manager Grid Control on Oracle RAC" for more information on the preinstallation tasks.
Caution:
If you are upgrading a 10.1.0.n agent to 10.2.0.2 release, you must execute the following command before starting the upgraded agent:emctl resetTZ agent
This command is required to correct the agent time zone.
This command will correct the agent-side time zone, and specify an additional command to be run against the repository to correct the value there.
Note:
Before you change the timezone, check if there are any blackouts that are currently running or scheduled to run on any of the targets that are monitored by the upgraded agent. Do the following to check this:In the Grid Control console, go to the All Targets page under Targets and locate the Agent in the list of targets. Click the agent name link. The Agent home page appears.
The targets monitored by the agent will be listed in the Monitored Targets section.
For each target in the list, click the target name to view the target home page.
In the Related Links section, click Blackouts to check any blackouts that are currently running or may be scheduled to run in the future.
If such blackouts exist, you must stop all the blackouts that are running on all the targets monitored by this agent.
From the console, stop all the targets that are scheduled to run on any of these monitored targets.
Now, run the following command from the agent home to reset the timezone;
emctl resetTZ agent
After the timezone is reset, you can create new blackouts on the targets.
Footnote Legend
Footnote 1: Out-of-place upgrade refers to the process of installing the software in a new Oracle home. All the data and configuration files from an existing Oracle home are retrieved and migrated to the new Oracle home. After the upgrade is complete, the old Oracle home is discarded and the software can be started from the new Oracle home.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|