Skip Headers
Oracle® Enterprise Manager Cloud Control Upgrade Guide
12c Release 2 (12.1.0.2)
E22625-16
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

11 Performing Postupgrade Tasks

This chapter describes the postinstallation tasks you must perform. In particular, this part covers the following:

Verifying the Host on Which Enterprise Manager Is Installed

For 2-system upgrade approach, Oracle recommends that you use a clean, fresh host for installing Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2). Verify that you have installed on a fresh host.

To do so, on the Management Services and Repository page, click the information icon adjacent to the page title. In the Target Information region that appears, as shown in Figure 11-1, validate the host name and make sure it reflects the host on which you have installed the OMS. Also verify that the same host name appears on the top-right corner of the page, right below the Search Target Name text box, as shown in Figure 11-1.

Figure 11-1 Verifying the Host

Surrounding text describes Figure 11-1 .

If the host names match and if they reflect the host on which you have installed the OMS, then it is a confirmation that you have installed on a fresh host.

If one of them reflects a different host name, then it is a confirmation that you have installed on a host that already has a Management Agent. Under such circumstances, follow these steps:

  1. Deinstall the existing Management Agent. Clean up or remove information related to the existing Management Agent and the targets monitored by it, from the Management Repository. For instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

  2. Add the host as a target to the new Management Agent. To do so, run the following command from the Management Agent home:

    $<AGENT_HOME>/bin/emctl config agent addInternaltargets

  3. Verify that the host is added as a target in Enterprise Manager Cloud Control Console. To do so, on the Management Agent home page, in the Monitoring section, in the Monitored Targets tab, verify that the host is listed.

  4. Relocate the Management Services and Repository target to this new Management Agent. To do so, log in as SYSMAN and run the following command from any host where EM CLI is installed:

    emcli relocate_targets -src_agent="<old_agent>" -dest_agent="<new_agent>" -target_name="Management Services and Repository" -target_type=oracle_emrep -copy_from_src

  5. Set the connect descriptor and credentials of the new, upgraded Management Repository as the monitoring configuration settings of the Management Services and Repository target.

    To do so, on the Management Services and Repository Home page, from the OMS and Repository menu, select Target Setup, then select Monitoring Configuration. On the Monitoring Configuration page, enter the connect descriptor and the credentials of the new, upgraded Management Repository. Click OK.

Creating Link to Upgraded Oracle Management Repository


Note:

Follow these instructions only if you are upgrading using the 2-System upgrade approach. Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

As a prerequisite for upgrading your Enterprise Manager system using the 2-System upgrade approach, you are required to back up your existing database first, and then upgrade the Oracle Management Repository (Management Repository) that is configured in it. This is to ensure that the upgraded Management Repository coexists with the earlier release of the Management Repository.

However, after you upgrade the Management Repository in the backed up database, link it to your earlier release of the Management Repository so that the two repositories are linked with each other, and any operations on the upgraded repository can be directly done from the old repository.


WARNING:

Verify the value set to the GLOBAL_NAMES parameter on both the databases:

  • If the GLOBAL_NAMES parameter is set to FALSE on both the databases, then ensure that you do not change this value until the upgrade is complete, and all the Management Agents are switched over.

  • If the GLOBAL_NAMES parameter is set to TRUE on even one of the databases, and if both the databases have the same value for the GLOBAL_NAME parameter, then change the value of the GLOBAL_NAME parameter set on the new, cloned database to a value that is different from the one set on the old database.


To link the earlier release of the repository to the upgraded repository, follow these steps:

  1. In Grid Control, click Deployments.

  2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

  3. On the Upgrade Console page, in the Select Upgrade Type section, select 2-System. For information about these upgrade approaches, see "Understanding Upgrade Approaches".

    Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

  4. In the OMS Upgrade Steps section, from the table, click Create Link to Upgraded Repository.

  5. On the Create Upgraded Oracle Management Repository Link page, in the Repository Link Details section, do the following:

    1. Enter the connect string to connect to the upgraded Management Repository that will be used by Enterprise Manager Cloud Control.


      Note:

      You will find the connect string set as a value to the EM_REPOS_CONNECTDESCRIPTOR parameter of the emgc.properties file. This file is present in the OMS Instance Base directory (gc_inst). When you enter this value as the connect string, remove all backslashes (\) and white spaces if any.

      For example, the value in the emgc.properties file might be:

      (DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=emrep)))

      When you enter this value as the connect string, it must look like this:

      (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))

      If you connect using service name instead of SID, then replace SID in the syntax with SERVICE_NAME.


    2. Enter the SYSMAN password of the upgraded Management Repository that will be used by Enterprise Manager Cloud Control.

    3. Enter the SYS password of the old Management Repository.

  6. Click Create DB Link.


Note:

If you had already provided these details and linked the two repositories, and if you are updating the connect descriptor or the SYSMAN password, then click Re-create DB Link.

Reconfiguring Oracle Software Library


Note:

Follow these instructions only if you are upgrading using the 2-System upgrade approach.

To reconfigure an upgraded Software Library in a two-system upgrade, perform these steps:


Note:

  • In a one-system upgrade, where the upgraded Enterprise Manager 12c comes up on the same host, reconfiguration is not required as the upgraded Software Library becomes functional when the system starts.

    For a one system upgrade, where the upgraded Enterprise Manager 12c comes up on a different host, all the location(s) configured in the earlier, existing Enterprise Manager system for Software Library should be accessible from the new host.

  • In a two-system upgrade, and sometime in a one-system upgrade on a different host, if the location configured in the earlier, existing Enterprise Manager system is a local file system path, then follow the instructions outlined in Upgrading with 1-System Upgrade Approach for more information.


  1. In Cloud Control, from Setup menu, select Provisioning and Patching and then, click Software Library.

  2. If the Software Library has been upgraded, then on the Software Library home page, the following notification will appear:

    Software Library has been upgraded recently and has not been reconfigured yet. Software Library will be usable only after the reconfiguration has been performed. To initiate the reconfiguration process, click Post Upgrade Reconfiguration.

    Click Post Upgrade Reconfiguration, to reconfigure the Software Library.

    Surrounding text describes reconfig.gif.
  3. On the Software Library Reconfigure Locations page, enter the new file system location that is to be configured, corresponding to the location configured in the earlier, existing Enterprise Manager system.

    Surrounding text describes reconfig_page.gif.

    The archive of the location which was configured for the old Enterprise Manager system must be unzipped in the corresponding location on the new file system. Also, ensure that the new location, and all its unarchived files and directories have read/write permissions for the 12c OMS process owner.

    For example:

    In the earlier, existing Enterprise Manager system, lets assume that the Software Library was configured to use the following file system locations:

    /shared/swlib1
    /shared/swlib2
    

    Figure 11-2 Two-System Reconfiguration

    2-System Reconfiguration

    After an upgrade, on the Reconfigure Locations page, you will see:

    migrated1, /shared/swlib1
    migrated2, /shared/swlib2
    

    where, migrated1 and migrated2 are names automatically assigned to the upgraded locations.


    Note:

    Since the new locations are only reconfiguring the OMS Shared File System storage locations, you must ensure that these new locations are either NFS-mounted shared locations or OCFS2 shared locations.

    You should then provide an alternate file system path for each of the existing locations. For example, as follows:

    migrated1, /shared/swlib1, /vol/newswlib1
    migrated2, /shared/swlib2, /vol/newswlib2
    

    Before confirming this configuration, you must ensure that the new locations have the corresponding back ups of the configured Software Library directories unarchived, which means, /vol/newswlib1 should have the same content as /shared/swlib1, /vol/newswlib2 should have the same content as /shared/swlib2 had when the backup was taken.

    1. Click Validate to submit a validation job that performs exhaustive validation checks on the entities being migrated. Ensure that you track this job to completion. If there are any validation errors, then it will appear on the job step. Some of the common validation errors are:

      - The new location specified for reconfiguration does not exist.

      - The new location specified for reconfiguration does not have read/write permissions for the OMS process owner.

      - The content of the location(s) configured in the old Enterprise Manager Software Library is not restored in the corresponding new location specified for reconfiguration.

    2. After a successful validation, click Confirm to reconfigure the Software Library. A job is submitted which must be tracked to successful completion, following which you should initiate any patching or provisioning tasks.

Checking Agent Upgrade Status


Note:

Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To check the status of the agent upgrade operations, follow these steps:

  1. In Grid Control, click Deployments.

  2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

  3. On the Upgrade Console page, do the following:

    • For macro-level details, in the Agent Upgrade Status section, view the count displayed against the following:

      • Successful, to identify the Management Agents that have been successfully upgraded.

      • Failed, to identify the Management Agents that failed to get upgraded.

      • In Progress, to identify the Management Agents that are currently being upgraded.

      • Not Started, to identify the Management Agents that are yet to be upgraded.

      • Not Supported, to identify the Management Agents that are not supported in the upgraded Enterprise Manager system because Oracle Management Agent 12c is not released for a particular platform.

        To drill down and view more information, click the count value. Enterprise Manager Grid Control displays the Agent Upgrade Status page that provides information.

    • For micro-level details, in the Other Links section, click Agent Upgrade Status.

      On the Agent Upgrade Status page, do the following:

      • To filter the list according to your needs and view only the upgrade operations that interest you, use the search functionlity.

        For example, to view only the deployment operations that have failed, select Deployment from the Operation Type list, and select Failed from the Operation Status list, and click Search.


        Note:

        An Operation Type refers to a job submitted for a particular agent upgrade step such as Deployment, Configuration, Health Check, Upgrade, or Switch Over. An operation name refers to the operation name you specified while submitting any of these jobs. And each of these operations can have a status such as Not Started, In Progress, Success, Not Supported, Failed, or Pending Report Verification.

      • To deploy the agent software, select one or more Management Agent from the table, and click Deploy and Configure Agent.


        Note:

        You cannot deploy and configure Oracle Management Agent 12c for problematic Management Agents. To identify problematic Management Agents, see Identifying Problematic Oracle Management Agents.

        Also, you can deploy and configure Oracle Management Agent 12c only on existing Management Agents that are either completely upgradable or upgradable with missing plug-ins. To identify the upgradability status of the Management Agents, see Checking the Upgradability Status of Oracle Management Agents.


      • To check the health and readiness of the deployed Management Agent, select one or more Management Agents, and click Check Agent Readiness.

      • To view the readiness check details, select one or more Management Agents, and click View and Verify Health Check Reports.

        On the Agent Readiness Check Details page, review the reports one by one. If you want to confirm that you have verified the report, then select the Management Agent and click Verify and Sign Off Report. If you want to view more details about the readiness check, then select the Management Agent and click View Detailed Report.

      • To switch over the agents, select one or more Management Agents, which have successfully been deployed, configured, and health-checked, and click Switch Agent.

Performing General Postupgrade Tasks

This section describes the postupgrade steps you must follow after upgrading to Enterprise Manager Cloud Control. In particular, this section describes the following postupgrade steps:

Performing General Postupgrade Steps

Perform the following general postupgrade tasks:

  1. Follow the postupgrade steps outlined in the chapter that describes how to install a new Enterprise Manager system, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

  2. As a sanity check, ensure that all the database parameters are reset to their original values that existed before you started the upgrade operation, particularly for the job_queue_process parameter.

  3. Restart the Management Agent that monitors the Management Services and Repository target.

  4. Upgrade from 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2) is an out-of-place upgrade, and therefore, any customization done on the WebLogic Server, which is configured with the earlier release of the Enterprise Manager system, is not carried over by the upgrade process. You will have to redo the customization on the upgraded system.

  5. If the Enterprise Manager Console was secured with custom or third party certificates, then after upgrading to 12c Release 2 (12.1.0.2), these custom or third party certificates for the console are not automatically migrated to the upgraded 12.1.0.2 OMS home. However, the custom or third party certificates for upload ports are migrated. Therefore, after upgrading to 12c Release 2 (12.1.0.2), you must run the following command to secure the console with third party wallets:

    $<OMS_HOME>/bin>emctl secure console -wallet <third_party_wallets_location>

Patching Oracle WebLogic Server

Ensure that you apply patch 13349651 on the WebLogic server, which is configured for Enterprise Manager.

Upgrading Oracle Database Plug-ins


Caution:

  • Follow the instructions in this section only if you have upgraded from 12c Release 1 (12.1.0.1) with Bundle Patch 1 to 12c Release 2 (12.1.0.2) Patch Set 1 released in October 2012, and if you want to now upgrade your Oracle Database plug-ins from one revision of 12.1.0.2 to another (for example, from 12.1.0.2 to 12.1.0.2 [u120804], or from 12.1.0.2 [u120427] to 12.1.0.2 [u120804]).

  • If you have upgraded to 12c Release 2 (12.1.0.2) Patch Set 1 released in October 2012, and if you want to now upgrade your Oracle Database plug-in from 12.1.0.2 directly to 12.1.0.3 version, then skip this section and follow the plug-in upgrade process described in the OMS plug-in upgrade section and Management Agent plug-in upgrade section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.

  • If you have upgraded to 12c Release 2 Plugin Update 1 (12.1.0.2) released in February 2013, then skip this section. With this particular release, you automatically receive all the latest plug-ins as part of the upgrade process, and therefore, your Oracle Database plug-ins are automatically upgraded to 12.1.0.3 version, and also deployed to the OMS. You only have to deploy the upgraded version to the Management Agent as described in the Management Agent plug-in deployment section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.


Ensure that you upgrade the existing database plug-in revisions to the latest revision by applying the required patches on the database plug-in homes of the OMS. Table 11-1 lists the patches required for various database plug-in revisions.

Table 11-1 Upgrading Oracle Database Plug-ins

Source Version Target Version Patch to Apply

12.1.0.2

12.1.0.2 [u120804]

14340329

12.1.0.2 [u120427]

12.1.0.2 [u120804]

14340329

12.1.0.2 [u120704]

12.1.0.2 [u120804]

14340329


Make sure you apply this patch to the DB plug-in home of the OMS. For instructions to apply the patch, refer to the ReadMe that is released with the patch.


Caution:

While applying patch 14340329, you might see the following message if there are any patch conflicts.
Conflicts/Supersets for each patch are:
Patch : 14336159
     Bug Conflict with 12361589
     Conflicting bugs are:
     14171309
Patch : 14340329
     Bug Superset of 14089634
     Super set bugs are:
     13713877,14089634
Following patches have conflicts: [12361589 14336159]

To resolve this issue, first apply the MLR patch14546154, and then apply the patch 14340329. For instructions to apply the MLR patch, refer to the ReadMe that is released with the patch.



Note:

In future, if you see patch conflict with any other patch, then raise a service request for an MLR patch.

Upgrading Oracle Exalogic System Targets

Ensure that you upgrade your Oracle Exalogic System targets.

  1. To do so, from the Enterprise menu, select Job, then select Library.

  2. On the Job Library page, select the job name UPGRADE EXALOGIC SYSTEMS TO FUSION MIDDLEWARE 12.1.0.3.0 MODEL, and click Submit.

For the job to run successfully and upgrade the Oracle Exalogic System targets, you should have already upgraded the Management Agents, which are monitoring these targets, to 12c Release 2 (12.1.0.2) so that they contain the 12.1.0.3 Oracle Fusion Middleware Plug-in.

If one or more such Management Agents are not upgraded yet to 12c Release 2 (12.1.0.2), then the job fails and does not upgrade the Oracle Exalogic System targets. Under such circumstances, to resolve the issue, first upgrade those Management Agents, and then try submitting this job to upgrade the Oracle Exalogic System targets.

Restarting Central Agent When Additional OMS Is Upgraded

After you upgrade an additional OMS of 10g Release 5 (10.2.0.5) to 12c Release 2 (12.1.0.2) using 1-system upgrade approach, the targets that begin with /EMGC_GCDomain/GCDomain might appear as if they are down (see Example 11-1).

To resolve this issue, restart the upgraded central agent (that is, the Management Agent installed with the OMS).

Example 11-1 Targets Beginning with /EMGC_GCDomain/GCDomain That Are Down

/EMGC_GCDomain/GCDomain/EMGC_OMS2 
/EMGC_GCDomain/GCDomain/EMGC_OMS2/emgc 
/EMGC_GCDomain/GCDomain/EMGC_OMS2/empbs 
/EMGC_GCDomain/GCDomain/EMGC_OMS2/OCMRepeater 
/EMGC_GCDomain/GCDomain/EMGC_OMS2/oracle.security.apm(11.1.1.3.0)

Stopping OCM Scheduler

If OCM was installed in the Enterprise Manager system that you upgraded, then follow these steps:

  • If you upgraded from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then follow these steps:

    1. Set the environment variable ORACLE_HOME to the Oracle Management Service (OMS) home.

      • In bash terminal, run the following command:

        export ORACLE_HOME=<absolute_path_to_oms_home>

      • In other terminals, run the following command:

        setenv ORACLE_HOME <absolute_path_to_oms_home>

    2. Stop the OCM scheduler:

      $ORACLE_HOME/ccr/bin/emCCR stop


    Note:

    If you have the OCM scheduler installed on Oracle Management Agent, then repeat these steps on the Management Agent home as well. In this case, set the environment variable ORACLE_HOME to the Management Agent home as described in Step (1), and perform Step (2) from its home.

  • If you upgraded from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then

    1. Set the environment variable ORACLE_CONFIG_HOME to the OMS instance home:

      • In bash terminal, run the following command:

        export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>

      • In other terminals, run the following command:

        setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>

    2. Set the environment variable ORACLE_HOME to the OMS home:

      setenv ORACLE_HOME <absolute_path_to_oms_home>

    3. Stop the OCM scheduler:

      $ORACLE_HOME/ccr/bin/emCCR stop


    Note:

    If you have the OCM scheduler installed on Oracle Management Agent, then repeat these steps on the Management Agent home as well. In this case, skip Step (1), set the environment variable ORACLE_HOME to the Management Agent home as described in Step (2), and perform Step (3) from its home.

Deleting Obsolete Targets

The following targets from the earlier release of Enterprise Manager are not deleted automatically. This is because you might have created notification rules, metric threshold settings, compliance standard settings, jobs, and so on for these targets, and you might want to copy them to the new Oracle WebLogic Server targets of Enterprise Manager Cloud Control. After copying them, manually delete these targets.

  • While upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), the following targets are not deleted automatically. You must delete them manually.

    • EM Website

    • EM Website System

    • The following targets of each old OMS. You can delete these by deleting the top-level Oracle Application Server target of each old OMS.

      • Oracle Application Server

      • OC4J

      • Oracle HTTP Server

      • Web Cache

  • While upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), the following targets are not deleted automatically. You must delete them manually.

    • EM Website

    • EM Website System

    • The following targets of each old OMS. You can manually delete these by deleting the top-level farm target secFarm_GCDomain.

      • Oracle Fusion Middleware Farm

      • Oracle Weblogic Domain

      • Application Deployment

      • Metadata Repository


    Note:

    After you upgrade your Enterprise Manager using the 1-System upgrade approach, these targets might appear as if they are up and running. This status is false. In any case, do not investigate to resolve the status issue. Manually delete the targets as they are no longer needed in the Enterprise Manager Cloud Control.

Disabling Incident Rule Sets

If you upgraded using the 2-System upgrade approach, then disable the default incident rule sets. If you do not disable them, the incidents are automatically created for all critical metric alerts.

To disable the default incident rule sets, follow the steps:

  1. In Cloud Control, from the Setup menu, select Incidents, and then select Incident Rules.

  2. On the Incident Rules - All Enterprise Rules page, scroll down the table, and expand Incident management Ruleset for all targets.

  3. Select the row for the rule set you want to disable.

  4. From the Actions menu, click Disable.

  5. On the pop-up window, click OK.

  6. Repeat Step (3) to Step (5) for every rule set you want to disable.

  7. Once all the rule sets are disabled, ensure that the Enabled column of the table shows No with a warning icon next to it.

Resolving Metric Collection Errors for SOA Target

If you were monitoring a SOA target in your earlier release of Enterprise Manager, then in the health report you generated as described in Generating Health Report of Deployed Oracle Management Agents, you might have seen metric collection errors for the metrics Top SOA SQL Queries and Dehydration Store Tables.

To resolve that issue, access the Monitoring Configuration page of the SOA target, and provide the database credentials.

Enabling Linux Patching After Enterprise Manager Upgrade


Note:

This section is applicable only when you upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c.

After upgrading Enterprise Manager, you must stop all active jobs for Linux patching that were submitted prior to the upgrade, and resubmit them on the same targets. This section describes how you can achieve this.

In particular, this section covers the following:

Configuring DownloadLatestPackages Job

To configure the DownloadLatestPackages job, follow these steps:

  1. Stop active jobs which were scheduled prior to upgrade as follows:

    1. From the Enterprise menu, select Job and then Activity. The Job Activity page is displayed.

    2. In the Job Activity page, click the Advanced Search link.

    3. In the Advanced Search options, select Job Type as DownloadLatestPkgs, Target Type as Host, Status as Active, Scheduled Start as All, and then click Go.

    4. In the Advanced Search result, select each job listed in the table and click Stop.

  2. For each host target on which an active DownloadLatestPkgs job was stopped, resubmit a new DownloadLatestPkgs job on it as follows:

    1. From the Setup menu, select Provisioning and Patching and then Linux Patching. The Patching Setup page is displayed.

    2. In the Patching Setup page, click Setup RPM Repository.

    3. In the Setup RPM Repository page, select the Host target and set Normal Host Credentials and Privileged Host Credentials for this host target.

    4. Click Apply to submit the new job.

Configuring UpdateHostPackages Job

To configure the UpdateHostPackages job, follow these steps:

  1. Stop active jobs which were scheduled prior to upgrade as follows:

    1. From the Enterprise menu, select Job and then Activity. The Job Activity page is displayed.

    2. In the Job Activity page, click the Advanced Search link.

    3. In the Advanced Search options, select Job Type as UpdateHostPackages, Target Type as All Target Types against which jobs were submitted, Status as Active, Scheduled Start as All, and then click Go.

    4. In the Advanced Search result, select each job listed in the table and click Stop.

  2. For each group target on which an active UpdateHostPackages job was stopped, resubmit a new UpdateHostPackages job on it as follows:

    1. From the Setup menu, select Provisioning and Patching and then Linux Patching.

    2. In the Patching Setup page, click Setup Groups. The Setup Groups page is displayed.

    3. In the Setup Groups page, select the group on which you stopped an active UpdateHostPackages job and click Edit. The Edit Group wizard is displayed.

    4. In the Edit Group: Properties page, click Next.

    5. In the Edit Group: Package Repositories page, click Next.

    6. In the Edit Group: Credentials page, either use Host Preferred Credentials or Override Preferred Credentials and specify Normal Host Credentials and Privileged Host Credentials. Click Next.


      Note:

      Before editing this step, ensure that the host Preferred credentials are set already or the appropriate Named Credentials have been created already. If not, from the Setup menu, select Security and then Named Credentials to create Named Credentials or Preferred Credentials to set the Preferred Credentials for the host targets contained in the Linux Patching group.

    7. In the Edit Group: Review page, click Finish to submit the new job.

(Optional) Deleting the Old OMS Home

After upgrading your Enterprise Manager system completely, you can choose to delete your old OMS home. To do so, follow these steps:

Updating the Console URL

If you have a multi-OMS environment with a Server Load Balancer (SLB) configured for the upgraded OMS instances, then make sure you update the console URL on the Management Services and Repository page. The console URL you enter here is used to compose links pointing back to the Enterprise Manager Cloud Control Console in the e-mails sent by Enterprise Manager.

To update the console URL, follow these steps:

  1. From the Setup menu, select Manage Cloud Control, then select Health Overview.

  2. On the Management Services and Repository page, in the Overview section, click Edit against the Console URL label, and modify the URL to the SLB URL.

    For example, http://www.example.com, https://www.example.com:4443.


    Note:

    Do NOT end the console URL with /em.

  3. Verify if the updated console URL appears correctly in the e-mails sent by Enterprise Manager.

Tracking the Status of Deferred Data Migration Jobs

This section describes the following:

Overview of Deferred Data Migration

Deferred Data Migration is a post-upgrade activity to migrate the format of the data stored in an earlier release of Enterprise Manager to the format compatible with the upgraded Enterprise Manager system. The migration activity is essentially a job in Enterprise Manager that is submitted when the Oracle Management Repository gets upgraded and is scheduled to run in the background when the upgraded Enterprise Manager system starts functioning.

The format of the data stored in Enterprise Manager Cloud Control is different from the format in which the data was stored in any earlier release of Enterprise Manager.

When you upgrade from an earlier release of Enterprise Manager to Enterprise Manager Cloud Control, the data format gets automatically converted or migrated to the format that is compatible with Enterprise Manager Cloud Control.

However, the time taken to migrate the data format depends on the volume of data available in your earlier release of Enterprise Manager. Therefore, if you have a large amount of data, then it takes longer to migrate, and as a result, the upgrade process takes more time to complete. Unfortunately, until the upgrade process completes, your existing Enterprise Manager system might be unavailable, particularly when you use a 1-System upgrade approach (either on the local host or on a different, remote host).

Considering this, Oracle has fine-tuned its upgrade process to migrate the data format in two distinct phases.

In the first phase, when the Enterprise Manager system is shut down and upgraded, the most critical data relevant to the functioning of Enterprise Manager Cloud Control is migrated within a short time so that the new system can start functioning without much downtime. At this point, only some historical data is unavailable, but you can start monitoring the targets in the upgraded Enterprise Manager system, and see new alerts generated by the upgraded Oracle Management Agent.

In the second phase, after the upgraded Enterprise Manager system starts functioning, the remaining data is migrated.

The data whose format is migrated in the second phase, after Enterprise Manager Cloud Control starts functioning, is called the Deferred Data, and this process of migrating from old to new format is called the Deferred Data Migration.


Note:

If you want to prevent the DDMP jobs from running immediately by default, then see Configuring Postupgrade Tasks and Identifying Host for Enterprise Manager Cloud Control (Step 6).

Tracking the Status of Deferred Data Migration Jobs

To track the status of deferred data migration jobs, follow these steps:

  1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

  2. On the Post Upgrade Tasks page, click the Deferred Data Migration tab.

    The tab provides a list of data migration jobs with their status, start date and time, and end date and time.

  3. In this tab, you can do the following:

    • To start a data migration job for a component, select that component and click Start. By default, the job starts immediately. You cannot change this behavior.

    • To rerun a failed job, click the status icon to reach the Job Run page. On the Job Run page, click Edit. On the Edit <JobName> Job page, click Submit to rerun the job.

    • To hide or unhide the table columns, from the View list, select an appropriate option.

    • To detach the table from the screen, click Detach.

Tracking the Status of Accrued Data Migration Jobs


Note:

This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

This section describes the following:

Overview of Accrued Data Migration

Accrued Data Migration is a post-upgrade activity to migrate the accrued data stored in an earlier release of Oracle Management Repository (Management Repository) to the upgraded Management Repository. The accrued data relates to functional areas such as blackouts, alerts, events, metrics, and so on.


Note:

The Accrued Data Migration Process does not migrate any manually created data such as new job type, user-defined metrics, Software Library-related changes, and so on.

The migration activity is essentially a job in Enterprise Manager that runs in the background immediately after the earlier releases of Oracle Management Agents (Management Agents) are switched over to Oracle Management Agent 12c, particularly in the case of 2-System upgrade approach.

As part of the upgrade process, when you switch over the earlier releases of Oracle Management Agents to Oracle Management Agent 12c, the new Management Agents start communicating with Enterprise Manager Cloud Control, and start uploading data to the upgraded Oracle Management Repository (Management Repository).

In the 1-System upgrade approach, the entire Enterprise Manager system is upgraded, and therefore, all the Management Agents are switched over at a given time. In this approach, earlier releases of Management Agents cannot coexist with the upgraded ones, and once they are switched over, the upgraded Management Agents upload data only to one Management Repository at any given point, which is the upgraded repository. Therefore, there is no scope for accrued data.

However, in the 2-System upgrade approach, you can choose to switch over your Management Agents in phases. When one set of Management Agents are switched over, they start uploading data about their hosts and targets to the upgraded Management Repository, whereas the ones that are not switched over yet, continue to upload data about their hosts and targets to the old Management Repository. Therefore, the earlier releases of Management Agents coexist with the upgraded ones when only some of them are switched over, and under such circumstances, the data is uploaded to the old Management Repository as well as the new one at a given point. However, note that only one Management Agent represents a host at any given time, so the coexistence does not indicate two Management Agents on the same host. It only indicates an earlier release of Management Agent monitoring a host that coexists with an upgraded Management Agent monitoring another host.

When you swtich over the next set of Management Agents in the next phase, although they start uploading data to the upgraded Management Repository, the data uploaded to the old Management Repository before being switched over continues to exist in the old Management Repository. This data is called the Accrued Data, and the process of migrating this accrued data from the old Management Repository to the new one is called the Accrued Data Migration Process.


Note:

The accrued data migration jobs migrate ECM history data with the following exceptions:
  • If the ECM history data is associated with a target that is no longer part of the Enterprise Manager system, then the ECM history data for that target is not migrated to Enterprise Manager Cloud Control.

  • For Oracle WebLogic Server targets, the WebLogic configuration data is not migrated. This configuration data has changed significantly in Enterprise Manager Cloud Control.

  • As part of the data migration process, summary counts are now calculated and displayed in the ECM Summary region. For migrated data, the summary counts are only calculated for the last seven days.

If you do not see key values that you saw in the past, or if you see new values as key values, then note that this is an expected behavior. Some snapshots have had metadata changes in the last release and key values have changed. If metadata keys were removed from the metadata, those values will no longer be displayed in the Enterprise Manager Cloud Control as key columns, though the data is still present in the migrated database. If existing columns are now flagged as key columns, those columns will start appearing as key columns for newly collected data only. For new columns that are added either as key columns or non key columns, data will start appearing for newly collected data only.



Note:

If you want to prevent the ADMP jobs from running immediately by default, then see Identifying Host for Enterprise Manager Cloud Control (Step 6).

Tracking the Status of Accrued Data Migration Jobs


Note:

This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

To track the status of accrued data migration jobs, follow these steps:

  1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

  2. On the Post Upgrade Tasks page, click the Accrued Data Migration tab.

    The Accrued Data Migration page displays information about the accrued data migration jobs related to all the targets available in your Enterprise Manager system. By default, for every target, the accrued data migration job migrates the ECM history details as well as the metric details.

  3. In this tab, you can do the following:

    • To control the data being migrated for all the targets, from the Run accrued data migration for list, select one of the following options:

      • ECM HISTORY MIGRATION, to migrate only the ECM history details.

      • METRIC DATA MIGRATION, to migrate only the metric details.

      • All, to migrate the ECM history details as well as the metric details.

    • To view different types of data, from the View Targets list, select one of the following options:

      • All, to view all the accrued data migration jobs for all the targets in your Enterprise Manager system.

      • Active, to view the accrued data migration jobs that either failed or are currently running.

      • History, to view the accrued data migration jobs that succeeded.

      • Not Started, to view the accrued data migration jobs that have not started yet.

    • To retry a failed job, select the target for which the job failed and click Retry.

    • To stop a running job, select the target for which you want to stop the job and click Stop.

Generating and Viewing Diff Reports


Note:

This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

This section describes the following:

Overview of Diff Reports

Diff Reports provide information about the configuration or setup-related changes that were manually made to the earlier release of Enterprise Manager while it was being upgraded to Enterprise Manager Cloud Control using the 2-System upgrade approach.

In the 2-System upgrade approach, the earlier release of Enterprise Manager coexists with Enterprise Manager Cloud Control until the upgrade operation ends. In some production environments, the upgrade operation might take a long time to complete due to a large volume of data, and during this period, you might make some changes to the functional areas in the earlier release. For example, you might configure an additional location for the software library.

Such changes must be carried over to Enterprise Manager Cloud Control so that the upgraded system is identical to the earlier release. The Diff Reports show a summary of such changes so that you can manually redo those changes in Enterprise Manager Cloud Control.

Generating and Viewing Diff Reports


Note:

This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

To generate and view diff reports, follow these steps:

  1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

  2. On the Post Upgrade Tasks page, click the Diff Report tab.

    The Diff Report page lists the reports that were generated in the past for various components. However, when you visit this page the first time, you will not see any reports.

  3. On this page, you can do the following:

    • To generate the reports for various components, click Regenerate Report.


      Note:

      On clicking Regenerate Report, the status in the Status column changes to In Progress. Keep refreshing the page manually until the status changes to Completed.

    • To view a report of a particular component, select a component (row) from the table, and click Show Report.

    • To refresh a report and view the latest changes related to a component, select a component (row) from the table, and click Regenerate Report.

    • To hide or unhide the table columns, or to reorder the table columns, from the View list, select an appropriate option.

    • To detach the table from the screen, click Detach.

Viewing Inactive Targets in the Upgraded Enterprise Manager System


Note:

This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

Targets available in the existing Enterprise Manager system are active (monitored) in the upgraded Enterprise Manager system only when the Oracle Management Agents that were monitoring those targets are switched over to the upgraded Enterprise Manager system using Oracle Management Agent 12c.

To view a list of targets that are currently inactive in the upgraded Enterprise Manager system, follow these steps:

  1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

  2. On the Post Upgrade Tasks page, click the Targets with Pending Activation tab.

  3. In this tab, you can view a list of inactive targets.

    To search for targets of your choice, enter a keyword or a part of the target name (or target type) in the search text box placed right above the Target Name column (or Target Type column).

    Alternatively, you can click the links in the Refine Search pane to filter the table and list the targets of your choice.


Note:

To convert these inactive targets to active targets, switch over the Management Agents that are monitoring these targets in the existing Enterprise Manager system to the upgraded Enterprise Manager system. For information about switching over the Management Agents, see Switching Over to Oracle Management Agent 12c.

Signing Off Agent Migration Process


Note:

This section is applicable only for 1-system upgrade, 2-system upgrade, and 1-system upgrade on a different host for 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

After you switch over the Oracle Management Agents (Management Agent) to the Enterprise Manager Cloud Control, you can deinstall the earlier release of Management Agents. Instead of manually deinstalling the Management Agents, you can formally sign off the Agent Migration Process for each of the Management Agents and have the Post Upgrade Console automatically deinstall them for you.

To sign off the Agent Migration process for each of the Management Agents, follow these steps:

  1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

  2. On the Post Upgrade Tasks page, click the Sign Off tab.

  3. In this page, you can do the following:

    • To search Management Agents for which you have signed off the Agent Migration process, for which you are yet to sign off, or for which you are in the process of signing off, do the following:

      (i) From the Search Criteria list, select an appropriate option.

      (ii) In the Agent field, enter the name of the Management Agent. You can leave this blank if you want to search all Management Agents with a particular sign-off status. Alternatively, you can enter a part of the name and use wildcards to search for Management Agents with a similar name.

      (iii) Click Search.


      Note:

      If you have not run the accrued data migration job for a Management Agent, then you cannot search and sign off that Management Agent. You will not find that Management agent even if you try searching for it using the search conditions.

    • To select Management Agents and formally sign off the Agent Migration process for each of them, do the following:

      (i) In the table, select the Management Agents you want to sign off. To select all the Management Agents, select Select All.

      (ii) Click Sign Off Migration.

      (iii) Provide credentials to access the hosts on which the selected Management Agents were running.

      (iv) Click OK.


      Note:

      Once you sign off, the selected old Management Agents will automatically be deinstalled and removed, and they cannot be recovered in any way. Therefore, before you sign off, ensure that your Management Agents have switched over successfully and they are fully functional, and their targets are successfully being monitored in Enterprise Manager Cloud Control.

    • To hide or unhide the table columns, from the View list, select an appropriate option.

    • To detach the table from the screen, click Detach.

Updating Incident Rules

During upgrade, all Notification Rules created in the earlier release of Enterprise Manager are automatically migrated to corresponding Incident Rulesets that act on the targets originally defined in the Notification Rule. For more information about Incident Rulesets, see Appendix B.

However, for situations where the target type modeling has changed in Enterprise Manager Cloud Control, you must manually adjust the rules. This appendix describes how you can manually adjust the rulesets.

In particular, it covers the following:

Why Update Incident Rules

In the earlier releases of Enterprise Manager, OMS and Repository was a common target type defined for all the OMS instances in your environment. And the metrics collected for the different OMS instances were shown within this common target type.

However, in Enterprise Manager Cloud Control, in addition to the target type OMS and Repository, a new target type Oracle Management Service has been introduced to represent each of the OMS instances in your environment. Therefore, if you have five OMS instances in your environment, you will see one target type OMS and Repository and five instances of the target type Oracle Management Service - one for each OMS.

While the target type OMS and Repository captures metrics that are common to all the OMS instances in your environment, the target type Oracle Management Service captures metrics specific to an OMS.

Table 11-2 lists the metrics and describes the changes done to them due to the introduction of a new target type Oracle Management Service, and the actions you must take for each change.

Table 11-2 Changes to Metrics and Updates to Be Done

Change Type Change Description Affected Metrics Action to Be Taken by You

Retained

Some metrics have been retained for the same target type —OMS and Repository.

The following metrics havebeen retained:

  • Collections Waiting To Run

  • DBMS Job Invalid Schedule

  • DBMS Job Processing Time (% of Last Hour)

  • DBMS Job UpDown

  • Dequeue Status

  • Enqueue Status

  • Job Step Backlog

  • Notification UpDown

  • Number of Active Agents

  • Overall Files Pending Load - Agent

  • Overall Rows Processed by Loader in the Last Hour

  • Number of Agent Restarts

  • Target Addition Rate (Last Hour)

  • User Addition Rate (Last Hour)

No changes required.

Moved

Some metrics have been moved to the individual target type—Oracle Management Service.

The following metrics havebeen moved:

  • Loader Throughput (rows per second)

  • Total Loader Runtime in the Last Hour (seconds)

  • Management Service Status

  • Job Dispatcher Processing Time, (% of Last Hour)

  • Service Status

  • Repository Session Count

    [Note: This metric has moved under the child targets OMS Console and OMS Platform]

Set up new incident rules to respond to the metrics that have been moved to different target types.

See Updating Incident Rules for Moved Metrics

Renamed

Some metrics have been renamed for easy undersanding.

The following metrics havebeen renamed:

  • Average Notification Delivery Time (ms) Per Method [Renamed to Average Notification Time (seconds)]

  • Notifications Waiting [Renamed to Pending Notifications Count]

Update the incident rules set to the metrics that have been renamed.

See Updating Incident Rules for Renamed Metrics

Decommissioned

Some metrics have been decommissioned due to lack of support in Enterprise Manager Cloud Control.

The following metrics have been decommissioned:

  • Number of Duplicate Targets

  • Notification Processing Time (% of Last Hour)

  • Overall Files Pending Load - Loader

  • Notifications Waiting

    (Note: This is different from the Notifications Waiting metric that is renamed. This one does not have objects, while the one renamed has objects.)

Remove decommissioned metrics from the incident rules.

See Deleting Incident Rules


Updating Incident Rules for Moved Metrics

To update the incident rules set to the metrics that have been moved to the individual target type Oracle Management Service in Enterprise Manager Cloud Control, follow these steps:

  1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

  2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

  3. On the Edit Rule Set page, in the Rules tab, select the event rule that operates on the moved metrics, and click Edit.

    Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

  4. In the Edit Rule Wizard, do the following:

    1. On the Select Events page, select the metrics listed in the second row of Table 11-2, and click Remove.

    2. Click Next.

    3. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

    4. On the Review page, click Continue.

  5. Click Save.

    Enterprise Manager displays the Incident Rules page.

  6. On the Incident Rules page, click Create Rule Set.

  7. On the Create Rule Set page, enter a unique name for the rule set.

  8. In the Targets tab, select All targets of types, and select Oracle Management Service.

  9. In the Rules tab, click Create.

  10. In the Select Type of Rule to Create dialog, select Event Rule, and click Continue.

    Enterprise Manger displays the Create New Rule Wizard where you can create a new incident rule set.

  11. In the Create New Rule Wizard, do the following:

    1. On the Select Events page, from the Event Type list, select Metric Alert.


      Note:

      For the metric Management Service Status, select Target Availability from the Event Type list.

    2. Select Specific metric alerts, and click Add.

    3. In the Select Specific Metric Alert dialog, do the following:

      1. In the Search region, from the Target Type list, select Oracle Management Service, and then, click Search.

      2. From the table, select the moved metrics listed in the second row of Table 11-2.

      3. In the Severity and Corrective Action Status region, from the Severity list, select an appropriate severity level.

      4. Click OK.

    4. Click Next.

    5. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

    6. On the Review page, click Continue.

  12. Click Save.

    Enterprise Manager displays the Incident Rules page.


Note:

Repeat the procedure for all other incident rules created for the OMS.

Updating Incident Rules for Renamed Metrics

To update the incident rules set to the metrics that have been renamed in Enterprise Manager Cloud Control, follow these steps:

  1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

  2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

  3. On the Edit Rule Set page, in the Rules tab, select the event rule that operates on the renamed metrics, and click Edit.

    Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

  4. In the Edit Rule Wizard, do the following:

    1. On the Select Events page, select the metrics listed in the third row of Table 11-2, and click Remove.

    2. Click Add.

    3. In the Select Specific Metric Alert dialog, do the following:

      1. In the Search region, from the Target Type list, select OMS and Repository, and then, click Search.

      2. From the table, select the renamed metrics listed in the third row of Table 11-2.

      3. In the Severity and Corrective Action Status region, from the Severity list, select an appropriate severity level.

      4. Click OK.

    4. Click Next.

    5. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

    6. On the Review page, click Continue.


Note:

Repeat the procedure for all other incident rules created for the OMS.

Deleting Incident Rules

To remove the decommissioned metrics from the the incident rules, follow these steps:

  1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

  2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

  3. On the Edit Rule Set page, in the Rules tab, select the rule Metric Alerts Event Rule, and click Edit.

    Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

  4. In the Edit Rule Wizard, do the following:

    1. On the Select Events page, select the metrics listed in the last row of Table 11-2, and click Remove.

    2. Click Next.

    3. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

    4. On the Review page, click Continue.


Note:

Repeat the procedure for all other incident rules created for the OMS.