This chapter describes the postinstallation tasks you must perform. In particular, this part covers the following:
Upgrade to 13c Release 1 is an out-of-place upgrade, and therefore, any custom configuration done on the earlier release of the Enterprise Manager system and any customization done on the WebLogic Server, which is configured with the earlier release of the Enterprise Manager system, are not carried over by the upgrade process. You will have to redo the customization on the upgraded system.
Note:This section is applicable only for Oracle WebLogic Server custom certificates, and not applicable for Enterprise Manager Console certificates. The Enterprise Manager Console certificates are automatically copied over during upgrade.
If custom certificates were configured for Oracle WebLogic Servers (admin server as well as managed servers), then after upgrading to 13c Release 1, the custom certificates are not carried over. Instead, the Oracle WebLogic Servers are configured with Demo Certificates. Therefore, after upgrading, make sure you reconfigure the Oracle WebLogic Servers with custom certificates. To do so, follow these steps:
Run the following command on all the OMS instances. For information on the command and the options you can pass, see the Oracle Enterprise Manager Cloud Control Security Guide.
$<ORACLE_HOME>/bin/emctl secure wls <options>
Stop all the OMS instances:
$<ORACLE_HOME>/bin/emctl stop oms -all
Start all the OMS instances:
$<ORACLE_HOME>/bin/emctl start oms
After upgrading the first OMS, Oracle strongly recommends that you immediately upgrade the central agent on that host as described in Section 6.2.
However, if you did not upgrade the central agent on that host, and instead proceeded with the upgrade of an additional OMS to 13c Release 1, then verify the version of that upgraded additional OMS on the Managed Services page. To do so, from the Setup menu, select Manage Cloud Control, then select Management Services. Verify the OMS version.
If it still shows the older version and not the upgraded version, then restart the Management Agent on the additional OMS host.
This section describes the following:
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:Canceling or stopping of a running DDMP job is not recommended.
Do not shut down or restart the OMS or the Management Repository while DDMP jobs are running.
After upgrade, check the status of the deferred data migration jobs. Ensure that the FLAT Association build task in particular is completed successfully.
To track the status of deferred data migration jobs, follow these steps:
In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.
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.
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.
Ensure that you upgrade your Oracle Exalogic System targets.
To do so, from the Enterprise menu, select Job, then select Library.
On the Job Library page, select the job name UPGRADE EXALOGIC SYSTEMS TO FUSION MIDDLEWARE 220.127.116.11.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 the following supported release so that they contain 18.104.22.168 or later versions of the Oracle Fusion Middleware Plug-in.
If you upgraded from Enterprise Manager Cloud Control 12c Release 5 (22.214.171.124), and if you had not performed this step when you upgraded to 12c Release 5 (126.96.36.199), then perform this step now in 13c Release 1. Ensure that the Management Agent in this case is either 13c Release 1, 12c Release 5 (188.8.131.52), 12c Release 4 (184.108.40.206), or 12c Release 3 (220.127.116.11).
If you upgraded from Enterprise Manager Cloud Control 12c Release 4 (18.104.22.168), and if you had not performed this step when you upgraded to 12c Release 4 (22.214.171.124), then perform this step now in 13c Release 1. Ensure that the Management Agent in this case is either 13c Release 1, 12c Release 4 (126.96.36.199), or 12c Release 3 (188.8.131.52).
If one or more such Management Agents are not upgraded yet to any of these supported releases, 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.
After upgrading your Enterprise Manager system completely (either a full release or an additional OMS), you can choose to delete your old OMS home. For instructions, see Appendix D.
After upgrading from 10g Release 5 (10.2.0.5) or 11g Release 1 (184.108.40.206) to 12c Release 3 (220.127.116.11), 12c Release 4 (18.104.22.168), or 12c Release 5 (22.214.171.124), you should ideally delete the old central agent, which was not switched over. However, if you did not delete the unwanted central agent at that point for some reason, and if you upgraded from 12c Release 3 (126.96.36.199), 12c Release 4 (188.8.131.52), or 12c Release 5 (184.108.40.206) to 13c Release 1, then you might continue to see the old, unwanted 10g or 11g central agent in Activation Pending state in the 13c Release 1 Enterprise Manager Cloud Control Console.
If you do see such unwanted central agents in Activation Pending state, then delete by following these steps:
Identify the unwanted central agents to be deleted by running the following query as SYSMAN user in the upgraded Management Repository. The query reports central agents and the targets monitored by them, but make note of only the central agent names. Deleting the central agents anyway deletes the targets monitored by them.
SELECT ag.target_name agent_name, t.target_name target_name, t.target_type target_type FROM sysman.mgmt_targets ag, sysman.em_current_availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm, sysman.mgmt_targets t WHERE ag.target_guid = eca.target_guid AND eca.current_status = 4 AND eca.current_sub_status = 1 AND ag.target_type='oracle_emd' AND puasm.target_guid = ag.target_guid AND puasm.UPGRADE_STATUS !='IGNORE_UPGRADE' AND ag.emd_url NOT IN (SELECT emd_url FROM sysman.mgmt_targets WHERE target_type='oracle_emrep') AND t.emd_url = ag.emd_url ORDER BY ag.target_name, t.target_type, t.target_name
Delete the unwanted central agents:
On the upgraded OMS host, from the Oracle home of the OMS, log in to the EM CLI client. EM CLI Client is available by default with every OMS installation, so you need not install the client separately.
$<ORACLE_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>
Synchronize EM CLI:
Delete the unwanted central agents. Here,
agentName is the name of the central agent you want to delete.
$<ORACLE_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_emd -delete_monitored_targets
$/u01/software/oracle/middleware/oms/bin/emcli delete_target -name=example.com:4567 -type=oracle_emd -delete_monitored_targets
Deleting the central agents also deletes the targets monitored by them. However, if you want to continue to monitor those targets, then install a new Management Agent of 13c release on the host and discover the targets all over again.
If you plan to migrate the SYSMAN schema to a database configured with CDB and PDB, then ensure that you meet the following requirements:
Upgrade the database to a non-CDB-based database. During the database upgrade process, ensure that the character set of the non-CDB-based database is the same as the CDB. Then, migrate the SYSMAN schema from the upgraded non-CDB-based database to a new PDB in the CDB.
Correct the connect descriptor with updated database details. To do so, follow these steps on each OMS instance:
Stop the OMS.
emctl stop oms
Start the administration server on the first OMS. Skip this step when you are following these instructions on every other OMS in your environment.
emctl start oms -admin_only
Modify the connect descriptor for the Management Repository:
emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<service_name>)))"
emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.example.com)(PORT=1522))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=pdb2.example.com)))"
Stop and start all the OMS instances.
emctl stop oms -all
emctl start oms
Modify the monitoring configuration of the OMS and the Management Repository target.
emctl config emrep -conn_desc "<TNS_connect_descriptor>"
If you have any JVM targets associated with the old OMS, then even after you refresh the WebLogic domain, on the WebLogic domain home page, you will continue to see the JVM target that was associated with the old OMS. This is an expected behavior.
You can choose to either retain it for viewing historical data or delete it. To delete it, right-click the orphaned JVM target, and select Remove Target.
If you had selectively skipped or postponed the upgrade of certain job types as described in Section 4.15, then after upgrading the Enterprise Manager system, make sure you clear the values you inserted into the MGMT_PARAMETERS table.
To do so, as a SYSMAN user, log in to the database that houses the Oracle Management Repository, and run the following query:
DELETE FROM MGMT_PARAMETERS WHERE parameter_name LIKE 'mgmt_job_skip_job_type_upg%');
In addition, as the SYSMAN user, create a SQLPlus session against the Oracle Management Repository and run the following:
Do not include the job types
ExecLoaderCallbacks to the list.
FOR c IN (SELECT job_type_id
WHERE job_type IN ('<job type 1>', '<job type 2>', ...))