| Oracle® Enterprise Manager Grid Control Installation and Basic Configuration 10g Release 2 (10.2) B16228-05 |
|
 Previous |
 Next |
| Oracle® Enterprise Manager Grid Control Installation and Basic Configuration 10g Release 2 (10.2) B16228-05 |
|
Previous |
Next |
Oracle recommends reading this chapter to get a better understanding of the requirements for an Enterprise Manager upgrade.
Oracle Enterprise Manager Grid Control consists of three major components:
Repository Database
Management Service
Management Agent
With the option of deploying the 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 Enterprise Manager Upgrade process aims at simplifying this entire operation and rendering it as seamless and error-free as possible.
The following topics are covered in this chapter:
Grid Control release 10.2 installer only upgrades the corresponding Enterprise Manager release 10.1 components. Table 11-0 lists the supported component versions:
Table 11-1 Supported Component Versions that Correspond to the Installation Type
| Installation Type | Management Service Version | Database Version |
|---|---|---|
|
Enterprise Manager Using New Database |
10.1.0.4 and later (with Application server 9.0.4) |
9.0.1.5 |
|
Enterprise Manager Using Existing Database |
10.1.0.4 and later (with Application server 9.0.4) |
9.2.0.6 or higher |
|
Additional Management Service |
10.1.0.4 and later (with Application server 9.0.4) |
containing the 10.1.o.4 or higher Management Service schema |
|
Additional Management AgentFoot 1 |
Not Applicable |
Not Applicable |
Footnote 1 The supported Management Agent version is 10.1.0.3 and later.
This section lists the checks that you must perform before starting any of the Enterprise Manager release 10.2 upgrade scenarios discussed in the following sections.
You must ensure that the existing Enterprise Manager processes are shut down before starting the upgrade process.
To shut down Enterprise Manager, 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 Management Service that are uploading to the same repository. |
These commands usually successfully shut down all Enterprise Manager 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 Management Service instances uploading to the same repository are shut down before the upgrade. Such Management Service 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 Management Service 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 management Service.
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 Management Service.
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 Management Service.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 Enterprise Manager components. When you upgrade Enterprise Manager release 10.1 to release 10.2, the database instance is upgraded to a release 10.1.0.4 before the Enterprise Manager migration configuration is performed.
To successfully migrate your existing Enterprise Manager 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 an Enterprise Manager 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 an Enterprise Manager 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 Management Service and the agent. similarly, the default port for the Management Service 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 Enterprise Manager upgrade operation will preserve the ports that were being used in the original deployment. Hence, additional ports will not be required even if Enterprise Manager was originally deployed with a firewall.
Similarly, you will not have to perform any modifications to the software load balancer (SLB) configurations after the Enterprise Manager upgrade.
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. |
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 Management Service (OMS), the repository database, and the agent Oracle homes. During the upgrade, the installer creates a new Oracle home for the management Service, Repository Database, 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 ( |
If the earlier Enterprise Manager 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 Management Service 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 Enterprise Manager upgrade process. You are required to upgrade the database separately, before proceeding with the Management Service upgrade process. |
|
Caution: If you are upgrading an Enterprise Manager 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 Management Service). See AppendixA, "Monitoring Agent Does Not Discover Upgraded Targets" for more information. |
If the previous Enterprise Manager installation was for an additional Management Service, 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 Management Service to 10g Release 2 (10.2) without upgrading the monitoring agent (agent associated with that Management Service), 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 Management Service and the associated (monitoring) agent at the same time.
|
Caution: Ensure you shut down the Management Service 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 Enterprise Manager upgrade process. You are required to upgrade the database separately, before proceeding with the Management Service upgrade process. |
|
Caution: After successfully upgrading the 10g Release 1 (10.1.0.4) Management Service to release 10.2, the 10.1.0.4 agents that are uploading data to this Management Service may show an incorrect Management Service version when you execute./emctl status agent.
To resolve this issue, you must stop the 10.1.0.4 agents ( |
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 Management Service (OMS) Oracle homes. You must select the agent home that you want to upgrade. This agent home can be independent of the Management Service 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 Enterprise Manager 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. |
Follow these steps to perform an Enterprise Manager upgrade.
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 Installation
See Chapter3, "Enterprise Manager 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:
Management Service and the associated (monitoring) Management Agent
Only the Management Service
Only the Management Agent
|
Caution: If you are upgrading both Management Service and Agent (which is part of a chain agent installation), ensure the agent you have selected is the one that is communicating with selected Management Service.Also, ensure you shut down the agent and the Management Service 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 Management Service passwords. The Database Password (SYS) is required to access the configuration files of the existing database repository that is associated with the Management Service 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 Management Service.
In the Management Service Security section, specify a password that will be used to secure the communications between the Management Service and its agents.
|
Note: Management Service Security: This section is enabled only when the existing Management Service that you are upgrading is not secure. |
Click Next. If you are upgrading both Management Service and Agent, but only the existing Management Service is secure and locked, then the Agent Registration Password screen appears. Here, you must provide the correct password to enable communications between the secure Management Service 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 Management Service:
|
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 the Management Service (OMS) 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 Oracle Management Service 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 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.
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 Management Service 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 RefreshFromMetalink 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.
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.
In the Agent Deploy Application home page that appears, select the appropriate installation option that you want to perform.
|
Note: If you want to view the status of an earlier installation/upgrade session, click Agent Installation Status in the Deployments page. |
To upgrade the Management Agent using Agent Deploy, follow the instructions documented below:
On the Agent Deploy application home page, click Upgrade Agent to perform the Management Agent upgrade.
The Agent Upgrade: Installation Details page appears.
In the Source 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 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 Management Service 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 (,), white space, or a new line 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 11-2. |
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. Agent Deploy will use sudo to run this script. You must specify the invoking user's password here. You must also ensure that the targetpw variable is not set in the /etc/sudoers file.
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.
In the Additional Scripts section, specify any preinstallation and postinstallation scripts that you want to execute.
Click Continue to start the installation process.
Click Help, in the Agent Deploy application for more information.
The important parameters for Agent Upgrade are -o, -b and optionally -i, -t.
Table 11-3 lists all the possible parameters that you can specify.
Table 11-3 Possible Parameters that You Can Specify During Agent Upgrade
| Parameters | Description |
|---|---|
|
-t |
Do NOT start the Agent after installation/upgrade. No value required. |
|
-b |
Specify installation Base Dir location. For example, |
|
-d |
Do not initiate automatic target discovery. No value required. |
|
-i |
Specify inventory pointer location file. For example, |
|
-o |
Specify existing agent home to upgrade. For example, |
|
-p |
Specify file location for static port for Agent. For example, |
|
-z |
Specify the timezone environment variable value ( |
|
Note: If the parameters that you specify here are also specified independently through command-line options, the value of the parameters that you specify here will take precedence over the others. For example, if installation Base Dir has been specified independently, and the -b option is specified here, the value of the latter (-b) will be used during the upgrade. |
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 11-4 to execute the agentDownload script.
Table 11-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) |
|
-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 Management Service (OMS).
For example, if you are upgrading |
|
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. |
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.
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 Oracle Enterprise Manager, 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 5, "Prerequisites for Installing Enterprise Manager 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:
|
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.
