3 Upgrading Oracle Access Manager Single Node Environments
You can upgrade Oracle Access Manager from Release 11g Release 2 (11.1.2.3.0)
to Oracle Access Manager 12c (12.2.1.3.0) .
Complete the steps in the following topics to perform the upgrade:
- About the Oracle Access Manager Single Node Upgrade Process
Review the roadmap for an overview of the upgrade process for Oracle Access Manager single node deployments. - Completing the Pre-Upgrade Tasks for Oracle Access Manager
Complete the pre-upgrade tasks described in this section before you upgrade Oracle Access Manager. - Installing Product Distributions
Before beginning your upgrade, download Oracle Fusion Middleware Infrastructure and Oracle Access Manager 12c (12.2.1.3.0) distributions on the target system and install them using Oracle Universal Installer. - Installing the Latest Stack Patch Bundle
After you install the product distributions, Oracle strongly recommends you to apply the latest IDM Stack Patch Bundle (SPB) 12.2.1.3.0 before proceeding with the upgrade process. You can apply the patch by using the Opatch tool. Applying the SPB helps eliminate most of the upgrade issues or workarounds. - Creating the Required 12c Schemas Using RCU
When upgrading from 11g, you must create extra schemas required for 12c. If your setup has non-SSL ports open, you can use the Upgrade Assistant to create schemas by using the default schema settings. In case of SSL enabled setup, you can use the Repository Creation Utility (RCU) to create customized schemas. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures. - Integrating Access Federation with BI Publisher
Update to the required or latest patches to seamlessly integrate and view Oracle Access Manager audit information on BI Publisher. - Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success. - Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server, Node manager, and any managed servers. - Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware. - About Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.3.0). - Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration. - Performing Post-Upgrade Tasks
After performing the upgrade of Oracle Access Manager to 12c (12.2.1.3), you should complete the tasks summarized in this section, if required. - Performing the Post-Patch Install Steps
After completing the upgrade, you have to perform the post-patch installation steps.
Parent topic: In-Place Upgrade of Oracle Access Manager
About the Oracle Access Manager Single Node Upgrade Process
Review the roadmap for an overview of the upgrade process for Oracle Access Manager single node deployments.
The steps required to upgrade an existing domain will vary depending on how the domain is configured and which components are being upgraded.
Table 3-1 Tasks for Upgrading Single Node Oracle Access Manager Deployments
Task | Description |
---|---|
Optional If you have not done so already, review the introductory topics in this guide and complete the required pre-upgrade tasks. |
See: |
Required Complete the necessary pre-upgrade tasks specific to Oracle Access Manager. |
See Completing the Pre-Upgrade Tasks for Oracle Access Manager. |
Required Install Fusion Middleware Infrastructure and Oracle Access Manager 12c (12.2.1.3.0) in a new Oracle home. |
Install Fusion Middleware Infrastructure and Oracle Access Manager in a new Oracle home on the same host as the 11g production deployment before you begin the upgrade. In 12c, Oracle home is used to describe the 11g Middleware home. |
Required Apply the latest bundle patches. |
|
Required Start the Repository Creation Utility (RCU) to create the required 12c database schemas. |
The schemas you create will vary depending on your existing schema configuration. |
Required Run a pre-upgrade readiness check. |
|
Required Shut down the 11g environment (stop all Administration and Managed Servers). Ensure that the Database is up during the upgrade. |
WARNING: Failure to shut down your servers during an upgrade may lead to data corruption. |
Required Start the Upgrade Assistant to upgrade the 11g database schemas and to migrate all active (in flight) instance data. |
See Upgrading Product Schemas. NOTE: The upgrade of active instance data is started automatically when running the Upgrade Assistant. Once the data is successfully upgraded to the new 12c (12.2.1.3.0) environment, you can close the Upgrade Assistant. The closed instances will continue to upgrade through a background process. |
Required Start the Reconfiguration Wizard to reconfigure the domain. |
During an upgrade, the Configuration Wizard is run in reconfiguration mode to update the existing domain to use the newly installed software. See Reconfiguring the Domain Using the Reconfiguration Wizard. |
Required Start the Upgrade Assistant (again) to upgrade Oracle Access Manager domain component configurations. |
The Upgrade Assistant is used to update the reconfigured domain’s component configurations. |
Required Complete any necessary post-upgrade tasks. |
These tasks are optional. See Performing Post-Upgrade Tasks. |
Required Perform the post-patch install steps. |
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Completing the Pre-Upgrade Tasks for Oracle Access Manager
Complete the pre-upgrade tasks described in this section before you upgrade Oracle Access Manager.
- Checking the Supported Starting Point for Oracle Access Manager Upgrade
The Oracle Access Manager version that is supported for upgrade is11g Release 2 (11.1.2.3.0)
. - Checking if OAM is in a Different Domain to OAAM and OIM
In the case of Oracle Access Manager (OAM), Oracle Adaptive Access Management (OAAM), and Oracle Identity Manager (OIM) integrated setup, where OAM and OAAM are in same domain, and OIM is in a separate domain, the OAM domain needs to be cloned that works with OAAM and OIM in the source domain. - Removing the IAMSuiteAgent Deployment
TheIAMSuiteAgent
deployment is not supported in 12c. Therefore, undeploy theIAMSuiteAgent
before you proceed with the upgrade. - Upgrading Java JSE Policy
Upgrade Java JSE Policy, if required.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Checking the Supported Starting Point for Oracle Access Manager Upgrade
The Oracle Access Manager version that is supported for upgrade is 11g Release 2 (11.1.2.3.0)
.
11g Release 2 (11.1.2.3.0)
first, and then to 12c.
Checking if OAM is in a Different Domain to OAAM and OIM
In the case of Oracle Access Manager (OAM), Oracle Adaptive Access Management (OAAM), and Oracle Identity Manager (OIM) integrated setup, where OAM and OAAM are in same domain, and OIM is in a separate domain, the OAM domain needs to be cloned that works with OAAM and OIM in the source domain.
Note:
Ensure that Oracle Access Manager and Oracle Identity Manager are in different domains. If they are in the same domain, then you need to separate them into multiple domains. For more information, see Separating Oracle Identity Management Applications Into Multiple Domains.To separate the OAM and OAAM domain, do the following:
If OIM is installed in a separate domain, and is integrated with OAM and OAAM, do the following:
-
Update the following Oracle Identity Manager properties to contain the details of the new OAAM host:
OIM.ChangePasswordURL
OIM.ChallengeQuestionModificationURL
For information about setting the Oracle Identity Manager properties for OAAM, see Setting Oracle Identity Manager Properties for Oracle Adaptive Access Manager in the Integration Guide for Oracle Identity Management Suite for 11g Release 2 (11.1.2.3.0).
-
Restart the Oracle Identity Manager server.
Note:
You must upgrade the OAM domain whose Managed Server is in the running state after the domain separation.
For example, if you have followed the steps in this section, you will have to upgrade OAM that resides on machine-1, to 12c.
Removing the IAMSuiteAgent Deployment
The IAMSuiteAgent
deployment is not supported in
12c. Therefore, undeploy the IAMSuiteAgent
before you proceed
with the upgrade.
Removing IAMSuiteAgent
from the OAM Console
Note:
Before you delete IAMSuiteAgent
from the OAM console,
complete the following tasks:
- Replace
IAMSuiteAgent
with an 11g WebGate. See Replacing the IAMSuiteAgent with an 11g WebGate. RemovingIAMSuiteAgent
without replacing it with an 11g WebGate may result in a loss of the OAM functionalities in the 11g server. - Back up the OAM configuration.
- Log in to the OAM console.
- Go to the Application Security tab, click Agents, and then Managed single sign-on agents.
- From the list of SSO agents, select
IAMSuiteAgent
, and then click Delete. - Confirm the deletion.
Upgrading Java JSE Policy
Upgrade Java JSE Policy, if required.
Note:
This is required if any of the Identity Management components like Oracle Access Management (OAM), Oracle Identity Manager (OIM), Oracle Adaptive Access Manager (OAAM), or Oracle Access Manager Webgates of a data center are yet to be upgraded to 12c (12.2.1.3.0). This is for the phased transition to 12c (12.2.1.3.0).
For a Multi Data Center setup, this is required if any of the data centers has 12c (12.2.1.2.0) components (OAM, OIM, OAAM, OAM Webgates).
The jar files local_policy.jar
and US_export_policy.jar
are present in the directory $JAVA_HOME/jre/lib/security
. You can upgrade Java JSE policy by overwriting these jar files with the specified versions. To do this, complete the following steps:
Installing Product Distributions
Before beginning your upgrade, download Oracle Fusion Middleware Infrastructure and Oracle Access Manager 12c (12.2.1.3.0) distributions on the target system and install them using Oracle Universal Installer.
Note:
- The 12c binaries are installed in a different location from the previous 11g binaries. You can install 12c binaries before any planned downtime for upgrade.
- If you are using Redundant binary locations, ensure that you install the software into each of those redundant locations.
Note:
- If your 11.1.2.3.0 setup was deployed using Life Cycle Management (LCM) tool, you must install Oracle HTTP Server 12c (12.2.1.3.0) in the 12c Middleware home. See Preparing to Install and Configure Oracle HTTP Server in Installing and Configuring Oracle HTTP Server.
- By using the opatch tool, apply the latest recommended patchsets from Oracle Support. Complete only the binary installation of patchsets and follow any post-patch steps after the upgrade process is complete. This provides the latest known fixes for upgrade process, if any.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Installing the Latest Stack Patch Bundle
After you install the product distributions, Oracle strongly recommends you to apply the latest IDM Stack Patch Bundle (SPB) 12.2.1.3.0 before proceeding with the upgrade process. You can apply the patch by using the Opatch tool. Applying the SPB helps eliminate most of the upgrade issues or workarounds.
- Initial Preparation: In this phase, you stage the software, read the
README.txt
file, and verify and/or update the Opatch tool to the appropriate versions. - Analysis Phase: In this phase, you run the
prestop
command with the variables from theREADME.txt
file to determine if the system is ready for patching. - Patching Phase: In this phase, you backup MW_HOME and
DOMAIN_HOME, run the downtime command for OIG with the
variables from the
README.txt
file, and then clear any temporary files.
Note:
At this point, you will not restart the servers. There is currently no link between the schemas, the local configuration, and the new bits. The remainder of the patching process will happen after the bootstrap.config.xml
for the
com.oracle.cie.comdev_7.8.2.0
and
com.oracle.cie.xmldh_3.4.2.0
libraries:<name>com.oracle.cie.comdev#3.0.0.0@7.8.2.0</name>
com.oracle.cie.comdev_7.8.2.0.jar
<name>com.oracle.cie.xmldh#2.0.0.0@3.4.2.0</name>
com.oracle.cie.xmldh_3.4.2.0.jar
<library>
<name>com.oracle.cie.comdev#3.0.0.0@7.8.2.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.comdev_7.8.2.0.jar
</source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
<library>
<name>com.oracle.cie.xmldh#2.0.0.0@3.4.2.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.xmldh_3.4.2.0.jar<
/source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
<library>
<name>com.oracle.cie.comdev#3.0.0.0@7.8.4.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.comdev_7.8.4.0.jar
</source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
<library>
<name>com.oracle.cie.xmldh#2.0.0.0@3.4.4.0</name>
<target>oim_cluster</target>
<source-path><MW_HOME>/oracle_common/modules/com.oracle.cie.xmldh_3.4.4.0.jar<
/source-path>
<deployment-order>511</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
This update to the config.xml
file changes the name of the libraries and
version of the jar file in each library to the one that will be used post the patching
process. If it is a cluster, ensure that both nodes have these settings.
For more information on the patching process, see Doc ID 2657920.1.
Note:
If you are using Windows or Solaris OS, download the individual Bundle Patches (BPs) from Doc ID 2457034.1.After completing the upgrade, you have to perform the post-patch install steps. See Performing the Post-Patch Install Steps.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Creating the Required 12c Schemas Using RCU
When upgrading from 11g, you must create extra schemas required for 12c. If your setup has non-SSL ports open, you can use the Upgrade Assistant to create schemas by using the default schema settings. In case of SSL enabled setup, you can use the Repository Creation Utility (RCU) to create customized schemas. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.
Note:
You must use the 12c Repository Creation Utility (RCU) to create the 12c schemas. 12c RCU is located atORACLE_HOME
/oracle_common/bin
directory, where ORACLE_HOME
is the 12c Oracle Home.
-
Common Infrastructure Services Service Table (prefix_STB)
-
WebLogic Services (prefix_WLS)
-
User Messaging Service (prefix_UMS)
The existing schemas such as Oracle Access Manager (OAM), Oracle Platform Security Services (OPSS) will be upgraded, and therefore, you do not have to create new ones.
The following schemas must exist before you upgrade to 12c. If you are upgrading from 11g, and you are not sure which schemas you currently have, refer to the steps below to identify the existing schemas in your domain. You do not need to re-create these schemas if they already exist.
-
Service Table schema (
prefix_STB
). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas.Note:
If the Service Table schema does not exist, you may encounter the error message
UPGAST-00328 : The schema version registry table does not exist on this database. If that happens it is necessary to create the service table schema in order to run Upgrade Assistant
-
Oracle Platform Security Services (OPSS) schema (
prefix_OPSS
). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically.Note:
The 12c OPSS database schema is required so that you can reference the 12c schema during the reconfiguration of the domain. Your domain continues to use the OID-based security store after the upgrade is complete.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Integrating Access Federation with BI Publisher
Update to the required or latest patches to seamlessly integrate and view Oracle Access Manager audit information on BI Publisher.
Task 1: Integrate Access Audit with OPSS Store [IAU Schema]
Apply the latest patch for Oracle Access Manager 12c (12.2.1.3.0) or upgrade to 12c (12.2.1.4).
Task 2: Integrate Access Audit with BI Publisher
For Oracle Platform Security Services (OPSS), apply patch 12.2.1.3.181016 or later.
Task 3: Intergrate Access Federation Audit
For Oracle Platform Security Services (OPSS), apply patch 12.2.1.3.201013 or later.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.
- About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in-readiness
mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file. - Starting the Upgrade Assistant in Readiness Mode
Use the-readiness
parameter to start the Upgrade Assistant in readiness mode. - Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check. - Understanding the Readiness Report
After performing a readiness check for your domain, review the report to determine whether you need to take any action for a successful upgrade. - OAM Configuration Upgrade Readiness Checks
The Upgrade Assistant (UA), when run in the readiness mode, performs several configuration upgrade validation checks. Ensure that each of these validation checks are successful before you proceed with the upgrade process.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in -readiness
mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.
The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.
The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.
You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.
You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.
Note:
To prevent performance from being affected, Oracle recommends that you run the readiness check during off-peak hours.
Parent topic: Running a Pre-Upgrade Readiness Check
Starting the Upgrade Assistant in Readiness Mode
Use the -readiness
parameter to start the Upgrade Assistant in readiness mode.
Upgrade Assistant Parameters
When you start the Upgrade Assistant from the command line, you can specify additional parameters.
Table 3-6 Upgrade Assistant Command-Line Parameters
Parameter | Required or Optional | Description |
---|---|---|
|
Required for readiness checks
Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server). |
Performs the upgrade readiness check without performing an actual upgrade. Schemas and configurations are checked. Do not use this parameter if you have specified the |
|
Optional |
Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas. The value must be a positive integer in the range 1 to 8. The default is 4. |
|
Required for silent upgrades or silent readiness checks |
Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
Optional |
Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files. The default locations are: (UNIX)
(Windows)
|
|
Optional |
Displays all of the command-line options. |
Parent topic: Starting the Upgrade Assistant in Readiness Mode
Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.
Parent topic: Running a Pre-Upgrade Readiness Check
Understanding the Readiness Report
After performing a readiness check for your domain, review the report to determine whether you need to take any action for a successful upgrade.
The format of the readiness report file is:
readiness_timestamp.txt
where timestamp
indicates the date and time of when the readiness check was run.
A readiness report contains the following information:
Table 3-7 Readiness Report Elements
Report Information | Description | Required Action |
---|---|---|
Overall Readiness Status: SUCCESS or FAILURE | The top of the report indicates whether the readiness check passed or completed with one or more errors. | If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade. |
Timestamp |
The date and time that the report was generated. |
No action required. |
Log file location
|
The directory location of the generated log file. |
No action required. |
Readiness report location
|
The directory location of the generated readiness report. |
No action required. |
Names of components that were checked |
The names and versions of the components included in the check and status. |
If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, do not attempt an upgrade. |
Names of schemas that were checked |
The names and current versions of the schemas included in the check and status. |
Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, do not attempt an upgrade. |
Individual Object Test Status: FAIL |
The readiness check test detected an issue with a specific object. |
Do not upgrade until all failed issues have been resolved. |
Individual Object Test Status: PASS |
The readiness check test detected no issues for the specific object. |
If your readiness check report shows only the PASS status, you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade. |
Completed Readiness Check of <Object> Status: FAILURE | The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index, or datatype. | Do not upgrade until all failed issues have been resolved. |
Completed Readiness Check of <Object> Status: SUCCESS | The readiness check test detected no issues. | No action required. |
Upgrade readiness check completed with one or more errors.
This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt
Starting readiness check of components.
Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0. Readiness checks will now be performed.
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test: TEST_REQUIRED_PROCEDURES Test that the schema contains all the required stored procedures
EXCEPTION Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test: TEST_REQUIRED_TRIGGERS Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test: TEST_UNEXPECTED_PROCEDURES Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test: TEST_UNEXPECTED_VIEWS Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test: TEST_UNEXPECTED_TRIGGERS Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test: TEST_UNEXPECTED_COLUMNS Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.
If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from 11g (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:
Starting index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ FAIL
Note:
You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.Parent topic: Running a Pre-Upgrade Readiness Check
OAM Configuration Upgrade Readiness Checks
The Upgrade Assistant (UA), when run in the readiness mode, performs several configuration upgrade validation checks. Ensure that each of these validation checks are successful before you proceed with the upgrade process.
Note:
For UA to perform the config upgrade readiness checks described below, ensure that you apply the latest bundle patch that contains the fix for Bug 32081498.The UA performs the following validation checks:
- Validation of the OPSS and OAM Keystores (Check Name:
OAM_OPSS_KEYSTORE_CHECK)
The UA extracts the Credential Store Framework (CSF) key from both the OPSS keystore and the OAM keystore and compares them. If either of these keystores is corrupted, the read operation fails and consequently, the readiness check also fails. If the CSF keys are read successfully, they must be identical. Otherwise, the readiness check fails.
Reasons for the readiness check failure and suggestions to resolve them:
- If the readiness check fails because the
jks key
or thekeystore-csf-key
is not present in the CSF (the OAM keystore validation fails), modify or add the keystore password. See Doc ID 2710662.1 or Doc ID 2642638.1. - If the readiness check fails because the
values of the
jks key
and thekeystore-csf-key
are not equal, correct thekeystore-csf-key
value to be same as thejks key
value. See Doc ID 2710664.1 or Doc ID 2642638.1. - If the readiness check fails because the OAM
keystore file (
.oamkeystore
) is not present, restore the file from a backup, and then restart the OAM administration server and the managed server to re-create the.oamkeystore
file. See Doc ID 2710664.1. - If the readiness check fails to decrypt
sslGlobalPassphrase
, which is present in theoam-config.xml
file, see Doc ID 2710716.1.
- If the readiness check fails because the
- Validation of OAM Configuration Version Consistency
(Check Name: OAM_CONFIG_VERSION_CHECK)
The UA verifies that the OAM configuration version that is set in the
oam-config.xml
file system is consistent with the version set in the database. The UA extracts the schema credentials and database connection details to fetch theoam-config
version from the database. It then reads the version ofoam-config.xml
in the file system and compares the version with theoam-config
version it fetched from the database. If the two versions match, the readiness check succeeds; otherwise, it fails.The version mismatch occurs when OAM uses the incorrect datasource name. Configure the correct OAM datasource to resolve the issue. See Doc ID 2492188.1.
- Validation of the Default Keystore File (Check Name:
OAM_DEFAULT_KEYSTORE_CHECK)
The UA checks the existence and validity of the default keystore file,
default-keystore.jks
. If the file is not present before the upgrade, readiness check fails. Restart the OAM server to generate thedefault-keystore.jks
file.If the file exists, but fails to open using the CSF key, it is considered as invalid. The invalid file causes the readiness check to fail. This failure is shown as a failure to decrypt
sslGlobalPassphrase
, which is present inoam-config.xml
.The invalid
default-keystore.jks
file may be due to the corrupt OAM key (oamKey
). To resolve this issue, take a backup of the.oamkeystore
file, remove it from<domain_home>/config/fmwconfig
, restore the file from a backup, and then restart the OAM administration server and the managed server to re-create the.oamkeystore
file. See Doc ID 2710664.1. - Check for the Existence of Unsupported Agents (Check Name:
OBSOLETE_AGENT_CHECK)The UA checks the existence of the following agents in the environment:
- 10g OSSO agent
- OpenSSO agent
- OAM 10g WebGate agent
- Coexistence agent
If any of these agents exist, the readiness check requirement is not met. For a description of the unsupported agents, see Features Not Supported in Access Manager 12.2.1.3.0 in Release Notes for Oracle Identity Management.
Remove the unsupported agents before you start the upgrade.
- Validation of the Coherence Keystore (Check Name:
COHERENCE_KEYSTORE_CHECK)
The UA extracts the CSF key from the keystore and loads the Coherence keystore. It then checks the presence of the key alias
admin
and the certificate aliasassertion-cert
in the Coherence keystore. Both the key values must be present in the keystore. This readiness check succeeds if the Coherence keystore is loaded properly and both the keys are present in it. Otherwise, the check fails.If the check fails, create the missing keys and values in the Coherence keystore, and then validate the keystore. See Doc ID 1986560.1.
Here is a sample Readiness Report file. This report shows the portion relevant to OAM schema and configuration upgrade readiness checks:
Upgrade readiness check completed with one or more errors.
This readiness check report was created on Wed Sep 16 15:50:33 PDT 2020
Log file is located at: /scratch/idmqa/tmp/ua2020-09-16-15-40-18PM.log
Readiness Check Report File: /scratch/idmqa/tmp/readiness2020-09-16-15-50-33PM.txt
Domain Directory: /scratch/idmqa/work/mw35/user_projects/domains/WLS_IDM
Starting readiness check of components.
...
Oracle Access Management Suite (Schema Upgrade)
Starting readiness check of Oracle Access Management Suite.
Schema User Name: UPG_OAM
Database Type: Oracle Database
Database Connect String: slc11ykm.us.oracle.com:1521:db6844
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Starting schema test: OAM_CONFIG_VERSION_CHECK Test to check OAM Config version in Database and XML file are equal or not
INFO OAM Config version from Database: 105
INFO OAM Config version from XML: 105
INFO OAM Config version in Database and oam-config.xml are equal
Completed schema test: OAM_CONFIG_VERSION_CHECK --> Test to check OAM Config version in Database and XML file are equal or not +++ PASS
Finished readiness check of Oracle Access Management Suite with status: SUCCESS.
...
Oracle Access Management Suite (Config Upgrade)
Starting readiness check of Oracle Access Management Suite.
Starting config test: CUSTOM_AUTH_PROVIDER_CHECK Check that custom auth provider exist.
Completed config test: CUSTOM_AUTH_PROVIDER_CHECK --> Check that custom auth provider exist. +++ PASS
Starting config test: SOURCE_CONFIG_CHECK Test that OAM System configuration is valid.
Completed config test: SOURCE_CONFIG_CHECK --> Test that OAM System configuration is valid. +++ PASS
Starting config test: OAM_OPSS_KEYSTORE_CHECK. Test that OAM and OPSS keys are valid.
Completed config test: OAM_OPSS_KEYSTORE_CHECK. --> Test that OAM and OPSS keys are valid. +++ PASS
Starting config test: OAM_DEFAULT_KEYSTORE_CHECK Check that the default keystore is present and valid
INFO Checking default keystore file: /scratch/idmqa/work/mw35/user_projects/domains/WLS_IDM/config/fmwconfig//default-keystore.jks
INFO Default keystore file exists and is valid
Completed config test: OAM_DEFAULT_KEYSTORE_CHECK --> Check that the default keystore is present and valid +++ PASS
Starting config test: POLICY_PROVIDER_CHECK Check that policy provider is valid
Completed config test: POLICY_PROVIDER_CHECK --> Check that policy provider is valid +++ PASS
Starting config test: OBSOLETE_AGENT_CHECK Check that no obsolete agent exist in oam-config.xml.
INFO OAM agent co-existence setting is disabled.
INFO No OpenSSO agent instance exist.
INFO No OSSO agent instance exist.
WARNING Please remove following 10G webgate agent before upgrade: IAMSuiteAgent.
Completed config test: OBSOLETE_AGENT_CHECK --> Check that no obsolete agent exist in oam-config.xml. +++ FAIL
Finished readiness check of Oracle Access Management Suite with status: FAILURE.
...
Finished readiness check of components.
Parent topic: Running a Pre-Upgrade Readiness Check
Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server, Node manager, and any managed servers.
An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the correct order.
Note:
The procedures in this section describe how to stop the existing, pre-upgrade servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager.Note:
Stop all of the servers in your deployment, except for the Database. The Database must be up during the upgrade process.To stop your pre-upgrade Fusion Middleware environment, navigate to the pre-upgrade domain and follow the steps below.
Step 1: Stop System Components
To stop 11g system components, such as Oracle HTTP Server, use the opmnctl
script:
Note:
If the Oracle HTTP server is shared with other services, then you can choose not to stop the Oracle HTTP server.-
(UNIX)
OHS_INSTANCE_HOME/bin/opmnctl stopall
-
(Windows)
OHS_INSTANCE_HOME\bin\opmnctl stopall
You can stop system components in any order.
Step 2: Stop the Managed Servers
Depending on the method you followed to start the managed servers, follow one of the following methods to stop the WebLogic Managed Server:
-
(UNIX)
DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
- Log into Weblogic console as a
weblogic
Admin. - Go to Servers > Control tab.
- Select the required managed server.
- Click Shutdown.
wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'AdminServerHostName','5556','domain_name',
'DOMAIN_HOME')
wls:/offline>nmKill('ManagedServerName')
Step 3: Stop the Administration Server
When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
Follow one of the following methods to stop the Administration Server:
-
(UNIX)
DOMAIN_HOME/bin/stopWebLogic.sh
-
(Windows)
DOMAIN_HOME\bin\stopWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
- Log into Weblogic console as a
weblogic
Admin. - Go to Servers > Control tab.
- Select the required admin server.
- Click Shutdown.
wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'AdminServerHostName','5556','domain_name',
'DOMAIN_HOME')
wls:/offline>nmKill('AdminServer')
Step 4: Stop Node Manager
To stop Node Manager, run the following command:
kill $(ps -ef | grep nodemanager | awk '{print $2}')
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.
The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.
- Identifying Existing Schemas Available for Upgrade
This optional task enables you to review the list of available schemas before you begin the upgrade by querying the schema version registry. The registry contains schema information such as version number, component name and ID, date of creation and modification, and custom prefix. - Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time. - Upgrading Oracle Access Manager Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas. - Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version inschema_version_registry
has been properly updated.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Identifying Existing Schemas Available for Upgrade
This optional task enables you to review the list of available schemas before you begin the upgrade by querying the schema version registry. The registry contains schema information such as version number, component name and ID, date of creation and modification, and custom prefix.
You can let the Upgrade Assistant upgrade all of the schemas in the domain, or you can select individual schemas to upgrade. To help decide, follow these steps to view a list of all the schemas that are available for an upgrade:
-
If you are using an Oracle database, connect to the database by using an acount that has Oracle DBA privileges, and run the following from SQL*Plus:
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID;
-
Examine the report that is generated.
If an upgrade is not needed for a schema, the
schema_version_registry
table retains the schema at its pre-upgrade version. -
Note the schema prefix name that was used for your existing schemas. You will use the same prefix when you create new 12c schemas.
Notes:
-
If you used an OID-based policy store in 11g, make sure to create a new OPSS schema before you perform the upgrade. After the upgrade, the OPSS schema remains an LDAP-based store.
-
You can only upgrade schemas for products that are available for upgrade in Oracle Fusion Middleware release 12c (12.2.1.3.0). Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.3.0).
Parent topic: Upgrading Product Schemas
Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
Note:
Before you start the Upgrade Assistant, make sure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.
To ensure that UTF-8 is used by the JVM, use the JVM option -Dfile.encoding=UTF-8
.
- Go to the
oracle_common/upgrade/bin
directory:- (UNIX)
ORACLE_HOME
/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME
\oracle_common\upgrade\bin
- (UNIX)
- Start the Upgrade Assistant:
- (UNIX) ./ua
- (Windows) ua.bat
Note:
In the above command,ORACLE_HOME
refers to the 12c (12.2.1.3.0) Oracle Home.
For information about other parameters that you can specify on the command line, such as logging parameters, see:
Parent topic: Upgrading Product Schemas
Upgrade Assistant Parameters
When you start the Upgrade Assistant from the command line, you can specify additional parameters.
Table 3-8 Upgrade Assistant Command-Line Parameters
Parameter | Required or Optional | Description |
---|---|---|
|
Required for readiness checks
Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server). |
Performs the upgrade readiness check without performing an actual upgrade. Schemas and configurations are checked. Do not use this parameter if you have specified the |
|
Optional |
Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas. The value must be a positive integer in the range 1 to 8. The default is 4. |
|
Required for silent upgrades or silent readiness checks |
Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
Optional |
Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files. The default locations are: (UNIX)
(Windows)
|
|
Optional |
Displays all of the command-line options. |
Parent topic: Starting the Upgrade Assistant
Upgrading Oracle Access Manager Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.
Caution:
You can skip this step if you have already upgraded your schemas using RCU.Note:
-
If the pre-upgrade environment has Audit schema (IAU), you must first upgrade Audit schema only, using the Individually Selected Schema option on the Selected Schemas screen, and selecting Oracle Audit Services schema. Ensure that you select the appropriate IAU schema from the list of available IAU schemas. The upgrade assistant will not detect the corresponding IAU schema from the provided domain directory automatically. Hence, you must select it manually. Once the IAU schema is upgraded, run the Upgrade Assistant again to upgrade the remaining schemas using the All Schema Used by a domain option on the Selected Schemas screen.
-
If there is no Audit schema (IAU) in your pre-upgrade environment, use the All Schema Used by a Domain option on the Selected Schemas screen and proceed.
-
To check whether the pre-upgrade environment has the IAU schema, run the following SQL command using the user with sysdba privileges:
select username from dba_users where username like '%IAU%';
This command lists the IAU schemas available in your configured database.
Parent topic: Upgrading Product Schemas
Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry
has been properly updated.
If you are using an Oracle database, connect to the database as a user having Oracle DBA privileges, and run the following from SQL*Plus to get the current version numbers:
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
In the query result:
-
Check that the number in the
VERSION
column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.3.0.Note:
However, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.
-
The
STATUS
field will be eitherUPGRADING
orUPGRADED
during the schema patching operation, and will becomeVALID
when the operation is completed. -
If the status appears as
INVALID
, the schema update failed. You should examine the logs files to determine the reason for the failure. -
Synonym objects owned by
IAU_APPEND
andIAU_VIEWER
will appear asINVALID
, but that does not indicate a failure.They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these
INVALID
objects.
Note:
Undo any non-SSL port changes and any non-SYSDBA user that you made when preparing for the upgrade.Parent topic: Upgrading Product Schemas
About Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.3.0).
When you reconfigure a WebLogic Server domain, the following items are automatically updated, depending on the applications in the domain:
-
WebLogic Server core infrastructure
-
Domain version
Note:
Before you begin the domain reconfiguration, note the following limitations:
-
The Reconfiguration Wizard does not update any of your own applications that are included in the domain.
-
Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.
-
The domain version number in the
config.xml
file for the domain is updated to the Administration Server's installed WebLogic Server version. -
Reconfiguration templates for all installed Oracle products are automatically selected and applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version.
-
Start scripts are updated.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.
Note:
When the domain reconfiguration process starts, you can’t undo the changes that it makes. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. If an error or other interruption occurs while running the Reconfiguration Wizard, you must restore the domain by copying the files and directories from the backup location to the original domain directory. This is the only way to ensure that the domain has been returned to its original state before reconfiguration.- Backing Up the Domain
- Starting the Reconfiguration Wizard
- Reconfiguring the Oracle Access Manager Domain
Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing 11g domain.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Backing Up the Domain
Before running the Reconfiguration Wizard, create a backup copy of the domain directory.
To create a backup of the Administration server domain directory:
Parent topic: About Reconfiguring the Domain
Starting the Reconfiguration Wizard
Note:
Shut down the administration server and all collocated managed servers before starting the reconfiguration process. See Stopping Servers and Processes.To start the Reconfiguration Wizard in graphical mode:
Parent topic: About Reconfiguring the Domain
Reconfiguring the Oracle Access Manager Domain
Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing 11g domain.
Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Where, primary node is the Administration Server. Use the pack/unpack utility to apply the changes to other cluster members in the domain.Parent topic: About Reconfiguring the Domain
Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.
- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time. - Upgrading Oracle Access Manager Domain Component Configurations
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain. - Removing the Oracle Mobile Security Manager Servers Footprint
This activity applies only to Oracle Access Manager 11g (OAM 11.1.23.x) environments that used the Oracle Mobile Security Manager (OMSM) application and have been upgraded to Oracle Access Manager 12c (12.2.1.3.0). - Starting Servers and Processes
After a successful upgrade, start all processes and servers, including the Administration Server and any Managed Servers. - Verifying the Domain-Specific-Component Configurations Upgrade
To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.3.0.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
Note:
Before you start the Upgrade Assistant, make sure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.
To ensure that UTF-8 is used by the JVM, use the JVM option -Dfile.encoding=UTF-8
.
- Go to the
oracle_common/upgrade/bin
directory:- (UNIX)
ORACLE_HOME
/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME
\oracle_common\upgrade\bin
- (UNIX)
- Start the Upgrade Assistant:
- (UNIX) ./ua
- (Windows) ua.bat
Note:
In the above command,ORACLE_HOME
refers to the 12c (12.2.1.3.0) Oracle Home.
For information about other parameters that you can specify on the command line, such as logging parameters, see:
Upgrade Assistant Parameters
When you start the Upgrade Assistant from the command line, you can specify additional parameters.
Table 3-9 Upgrade Assistant Command-Line Parameters
Parameter | Required or Optional | Description |
---|---|---|
|
Required for readiness checks
Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server). |
Performs the upgrade readiness check without performing an actual upgrade. Schemas and configurations are checked. Do not use this parameter if you have specified the |
|
Optional |
Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas. The value must be a positive integer in the range 1 to 8. The default is 4. |
|
Required for silent upgrades or silent readiness checks |
Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
Optional |
Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files. The default locations are: (UNIX)
(Windows)
|
|
Optional |
Displays all of the command-line options. |
Parent topic: Starting the Upgrade Assistant
Upgrading Oracle Access Manager Domain Component Configurations
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.
After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.3.0), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.
Parent topic: Upgrading Domain Component Configurations
Removing the Oracle Mobile Security Manager Servers Footprint
This activity applies only to Oracle Access Manager 11g (OAM 11.1.23.x) environments that used the Oracle Mobile Security Manager (OMSM) application and have been upgraded to Oracle Access Manager 12c (12.2.1.3.0).
Oracle Mobile Security Manager (OMSM) application is not supported in OAM 12c (12.2.1.3.0). Therefore, Oracle recommends you to remove all components of OMSM. Removing all components will avoid any potential issues if the WebLogic Server Managed Server that runs the OMSM application gets started accidentally.
- The WebLogic Server Managed Server(s)
- The product's directory structure
- The database schema
- Removing the WebLogic Server OMSM Managed Server(s) From the Domain
- Removing the WebLogic Server OMSM Managed Server(s) From the Directory Structure
- Removing the OMSM Server Schema Objects From the Database
Parent topic: Upgrading Domain Component Configurations
Removing the WebLogic Server OMSM Managed Server(s) From the Domain
Removing the WebLogic Server OMSM Managed Server(s) From the Directory Structure
Starting Servers and Processes
After a successful upgrade, start all processes and servers, including the Administration Server and any Managed Servers.
The components may be dependent on each other so they must be started in the correct order.
Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.To start your Fusion Middleware environment, follow the steps below.
Step 1: Start Node Manager
-
(UNIX)
nohup ./startNodeManager.sh > DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &
-
(Windows)
nohup .\startNodeManager.sh > DOMAIN_HOME\nodemanager\nodemanager.out 2>&1 &
Step 2: Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start the Administration Server, use the startWebLogic
script:
-
(UNIX)
DOMAIN_HOME/bin/startWebLogic.sh
-
(Windows)
DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 3: Start the Managed Servers
- Log into Weblogic console as a
weblogic
Admin. - Go to Servers > Control tab.
- Select the required managed server.
- Click Start.
Method 2: Start a WebLogic Server Managed Server by using the startManagedWebLogic
script:
-
(UNIX)
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Note:
- The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.
- The Mobile Security Manager (MSM) servers are not supported in 12c. After restarting the servers, the 11g configurations of MSM servers, like
omsm_server1
orWLS_MSM1
, might remain. Ignore these configurations and do not restart the MSM servers.
Parent topic: Upgrading Domain Component Configurations
Verifying the Domain-Specific-Component Configurations Upgrade
To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.3.0.
To sign in to the Administration Console, go to: http://administration_server_host:administration_server_port/console
To sign in to the Administration Console in an EDG deployment, see Validating the Virtual Server Configuration and Access to the Consoles.
To sign in to Oracle Enterprise Manager
Fusion Middleware Control Console, go to: http://administration_server_host:administration_server_port/em
Note:
- After upgrade, ensure you run the administration tools from the new 12c Oracle home directory and not from the previous Oracle home directory.
- During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.
- In the site-specific configuration, the WebLogic and EM consoles must be accessible with the URLs either directly or through proxy URLs.
Parent topic: Upgrading Domain Component Configurations
Performing Post-Upgrade Tasks
After performing the upgrade of Oracle Access Manager to 12c (12.2.1.3), you should complete the tasks summarized in this section, if required.
This section includes the following tasks:
- WebGates Configuration Fails during Authentication
WebGates configured with thehmacEnabled=true
in environments whereglobalHMACEnabled
is not set totrue
fails during authentication. - Updating the java.security File
If you have multiple components of Oracle Identity and Access Management (Oracle Access Manager, Oracle Identity Manager, WebGates and so on) deployed, until you upgrade all of the components to 12c (12.2.1.3.0), you must update thejava.security
file with the changes described in this section.
Parent topic: Upgrading Oracle Access Manager Single Node Environments
WebGates Configuration Fails during Authentication
WebGates configured with the hmacEnabled=true
in environments where globalHMACEnabled
is not set to true
fails during authentication.
For more information, see Upgrading to OHS/OTD 12c WebGate.
Parent topic: Performing Post-Upgrade Tasks
Updating the java.security File
If you have multiple components of Oracle Identity and Access Management (Oracle Access Manager, Oracle Identity Manager, WebGates and so on) deployed, until you upgrade all of the components to 12c (12.2.1.3.0), you must update the java.security
file with the changes described in this section.
Parent topic: Performing Post-Upgrade Tasks
Performing the Post-Patch Install Steps
After completing the upgrade, you have to perform the post-patch installation steps.
The post-patch installation steps comprises the following:
- Running the Poststart Command to Confirm Successful Binary Patching
- Performing a Clean Restart of the Servers
Parent topic: Upgrading Oracle Access Manager Single Node Environments
Running the Poststart Command to Confirm Successful Binary Patching
poststart
command for your product, as shown below:
$ ./spbat.sh -type oig -phase poststart -mw_home /<INSTALLATION_DIRECTORY>/IAM12c -spb_download_dir /<DOWNLOAD_LOCATION>/IDM_SPB_12.2.1.4.200714 -log_dir /<DOWNLOAD_LOCATION>/OIGlogs
For details, see Doc ID 2657920.1.
Parent topic: Performing the Post-Patch Install Steps
Performing a Clean Restart of the Servers
Restart all the servers including the Administration Server and any Managed Servers. See Starting Servers and Processes.
Parent topic: Performing the Post-Patch Install Steps