2 Pre-Upgrade Requirements

Before you begin to upgrade Oracle Fusion Middleware Infrastructure 14c (14.1.2.1.0), you must perform pre-upgrade tasks such as backing up, cloning your current environment, and verifying that your system meets certified requirements.

Pre-Upgrade Checklist

The Pre-Upgrade Checklist identifies tasks that can be performed before you begin your upgrade to ensure that you have a successful upgrade and limited downtime.

Upgrades are performed while the servers are down. This checklist is meant to identify important — and often time-consuming — pre-upgrade tasks that you can perform before the upgrade to limit your downtime. The more preparation you can do before you begin the upgrade process, the less time you spend offline.

Note:

The pre-upgrade procedures you perform depend on the configuration of your existing system, the components you are upgrading, and the environment that you want to create at the end of the upgrade and configuration process. Complete only those tasks that apply to your configurations or use cases.

This table describes the Pre-Upgrade Checklist. It lists all the required components and describes them in detail.

Table 2-1 Tasks to Perform Before You Upgrade Oracle Fusion Middleware

Task Description

Required

Create a complete backup of your existing environment.

Back up all system-critical files and databases that contain any schemas that are to be upgraded. If the upgrade fails, you must restore your pre-upgrade environment and begin the upgrade again.

See Creating a Complete Backup.

  • Make sure that your backup includes the schema version registry table. See Backing Up the Schema Version Registry Table.

  • If you have modified or customized any of the startup scripts or any of the configuration files in your existing domain (for example, setting a value for the cookie-path property), you need to copy them to the temporary directory location (outside of the existing domain) during the upgrade, and redeploy them after the upgrade.

Optional

Clone your production environment to use as an upgrade testing platform.

In addition to creating a complete backup of your system files, Oracle strongly recommends that you clone your production environment. This environment can be used to test the upgrade.

Required

Verify that you install and upgrade your product on a supported hardware and software configuration.

CAUTION: Do not attempt an upgrade if you are unable to use the latest supported operating system. As with all supported configurations, failure to comply with these requirements may cause your upgrade to fail.

Verify that your hardware and software configurations (including operating systems) are supported by the latest certifications and requirements documents. Also make sure to use a supported JDK version before you install the product distributions.

Oracle recommends that you verify this information right before you start the upgrade as the certification requirements are frequently updated.

Make sure that you have applied the latest patches to your components before you upgrade.

See Verifying Certification and System Requirements.

Optional

Create a Non-SYSDBA user to run the Upgrade Assistant with necessary privileges.

Oracle recommends that you create the FMW user to run the Upgrade Assistant. The FMW user can run the Upgrade Assistant without any system administration privileges.

See Creating a Non-SYSDBA User to Run the Upgrade Assistant.

Required

If you are using auto_login wallet, you must update wallet files.

Auto_login_only wallets are the only supported wallets in 14c (14.1.2.1.0). Before upgrading to 14c (14.1.2.1.0), you must update all existing 12c (12.2.1.4.0) auto_login wallets to auto_login_only using convert_to_auto_login_only.pl.

See unresolvable-reference.html#GUID-315E9CA9-0200-4690-927B-F5E03EB97D5B.

Required

Linux and UNIX Operating System users must set their DISPLAY environment variables before starting the Fusion Middleware tools.

unresolvable-reference.html#GUID-96635459-410E-4700-8559-55BA40B2DADA

If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter an error.

Creating a Complete Backup

Before you start an upgrade, back up all system-critical files, including the databases that host your Oracle Fusion Middleware schemas.

The backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table so that you can restore the contents back to its pre-upgrade state if the upgrade fails.

The Upgrade Assistant Prerequisites screen prompts you to acknowledge that backups have been performed before you proceed with the actual upgrade. However, note that the Upgrade Assistant does not verify that a backup has been created.

See:

Backing Up the Schema Version Registry Table

Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table or the FMWREGISTRY.SCHEMA_VERSION_REGISTRY$ table.

Each Fusion Middleware schema has a row in the SYSTEM.SCHEMA_VERSION_REGISTRY$ table. If you run the Upgrade Assistant to update an existing schema and it does not succeed, you must restore the original schema before you can try again. Before you run the Upgrade Assistant, make sure you back up your existing database schemas and the schema version registry.

Note:

Before you upgrade a schema using the Upgrade Assistant, you must perform a complete database backup. During the upgrade, you are required to acknowledge that backups have been performed.

Maintaining Customized Domain and Environment Settings

If you have modified any domain-generated, server startup scripts, or configuration files in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations. Save your customized files to a shared library location so that you can continue to use them after the upgrade.

Every domain installation includes dynamically-generated domain and server startup scripts, such as setDomainEnv. These files are replaced by newer versions during the installation and upgrade process. To maintain your custom domain-level environment settings, Oracle recommends that you create a separate file to store the custom domain information before you upgrade, instead of modifying the scripts directly.

For example, if you want to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.cmd (Windows) or setUserOverrides.sh (UNIX) and configure it to add custom libraries to the WebLogic Server classpath, specify additional command-line options for running the servers, or specify additional environment variables. When using the pack and unpack commands, any custom settings that you add to this file are preserved during the domain upgrade operation and are carried over to the remote servers.

The following example illustrates startup customizations in a setUserOverrides file:
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command-line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

If the setUserOverrides file exists during a server startup, the file is included in the startup sequence and any overrides contained within this file take effect. You must store the setUserOverrides file in the EXISTING_DOMAIN_HOME/bin directory.

Note:

If you are unable to create the setUserOverrides script before an upgrade, you need to reapply your settings as described in Re-apply Customizations to Startup Scripts in Upgrading Oracle WebLogic Server.

Cloning Your Production Environment for Testing

Create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.

Cloning your production environment for testing is recommended, but not required.

Upgrades cannot be reversed. In most cases, if an error occurs, you must stop the upgrade and restore the entire environment from backup and begin the upgrade process from the beginning. Identifying potential upgrade issues in a development environment can eliminate unnecessary downtime.

Note:

It is beyond the scope of this document to describe the cloning procedures for all components and operating systems. Cloning procedures are component and operating system-specific. At a high level, you install the pre-upgrade version of your component domain on a test machine, create the required schemas using the Repository Creation Utility (RCU), and perform the upgrade.
Additional benefits of running an upgrade in a cloned production environment include the following:

  • Uncover and correct any upgrade issues.

  • Practice completing an end-to-end upgrade.

  • Understand the upgrade performance and how purge scripts can help.

  • Understand the time required to complete the upgrade.

  • Understand the database resource usage (such as temporary tablespace; PGA, and so on).

Note:

You can run the pre-upgrade Readiness Check on the cloned production environment to help identify potential upgrade issues with your data, but you must perform a complete test upgrade on a cloned environment to ensure a successful upgrade.

Verifying Certification and System Requirements

Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation. You may be required to upgrade your operating system, hardware or other software packages.

Note:

When checking the certification, system requirements, and interoperability information, be sure to check specifically for any operating system requirements. It is important for you to download software specifically designed for your operating system environment, explicitly.

WARNING:

Make sure that your current environment has been patched to the latest patch set before you begin the upgrade. Certifications are based on fully patched environments, unless stated otherwise.

Verify Your Environment Meets Certification Requirements

Oracle has tested and verified the performance of your product on all certified systems and environments. Make sure that you are installing your product on a supported hardware or software configuration.

Whenever new certifications occur, they are added to the appropriate certification document right away. New certifications can occur at any time, and for this reason the certification documents are kept outside of the documentation libraries and are available on Oracle Technology Network. See the Certification Matrix for 14c (14.1.2.1.0).

Verify System Requirements and Specifications

It is important to use both the System Requirements and Specifications document and the Oracle Fusion Middleware Certification Matrix to verify that the system requirements such as disk space, available memory, specific platform packages and patches, and other operating system-specific items are met.

Use the Oracle Fusion Middleware System Requirements and Specifications document to verify that the requirements of the Oracle Fusion Middleware Certification matrix are met. For example, if the Certification Matrix indicates that your product is certified for installation on 64-Bit Oracle Linux 8, the System Requirements and Specifications document should be used to verify that your Oracle Linux 8 system has met the required minimum specifications such as disk space, available memory, specific platform packages and patches, and other operating system-specific items. This document is updated as needed and resides outside of the documentation libraries on the Oracle Technology Network (OTN).

Note:

Do not attempt an upgrade if you are unable to meet the minimum system requirements.

Specifically, you can use the Oracle Fusion Middleware System Requirements and Specifications document to verify the following:
  • Processor Requirements
  • Java Development Kit (JDK) Requirements
  • General Memory and Disk Space Requirements
  • Product-Specific Memory and Disk Space Requirements
  • Network Requirements
  • UNIX Operating System Requirements
  • Windows Operating Systems Requirements
  • Virtualization Requirements
  • Database Requirements

What if my operating system is not supported?

If you are running your environment on an unsupported operating system, you will need to create a supported environment before you begin your upgrade. Do not attempt an upgrade on an unsupported operating system.

Use the migration steps for your environment.

Verify That the Database Hosting Oracle Fusion Middleware is Supported

You must have a supported Oracle database configured with the required schemas before you run Oracle Fusion Middleware 14c (14.1.2.1.0).

Review the Fusion Middleware database requirements before starting the upgrade to ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. See the Certification Matrix for 14c (14.1.2.1.0).

Note:

If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade.

Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware

At the time this document was published, the certified JDK for 14c (14.1.2.1.0) was 17.0.12.

Refer to the Oracle Fusion Middleware Supported System Configurations information on the Oracle Technology Network (OTN) to verify that the JDK you are using is supported.

If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK, from the following website:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

Make sure that the JDK is installed outside of the Oracle home. The Oracle Universal Installer validates that the designated Oracle home directory is empty, and the install does not progress until an empty directory is specified. If you install JDK under Oracle home, you may experience issues in future operations. Therefore, Oracle recommends that you use install the JDK in the following directory: /home/oracle/products/jdk.

For more information on the difference between generic and platform-specific installers, see Understanding the Difference Between Generic and Platform-Specific Distributions in the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files.

Verify the Database User for the WLSSchemaDataSource Data Source

This step is required if your existing domain has a WLSSchemaDataSource data source.

If your domain has the WLSSchemaDataSource data source, then you will need to verify which database user is assigned to it. If <PREFIX>_WLS_RUNTIME is assigned to it, then you need to change that to <PREFIX>_WLS .

This change is necessary due to the following changes:
  • The 14c (14.1.2.1.0) Upgrade Assistant uses the information in the WLSSchemaDataSource data source,when a domain-based schema upgrade is performed. That upgrade will fail if the <PREFIX>_WLS database user is not assigned to the WLSSchemaDataSource, or if <PREFIX>_WLS is not entered as the "Schema User Name" on the "WLS Schema" page of the Upgrade Assistant.
  • Oracle recommends that you use the 12c Oracle WebLogic Administration Console to change the database user to <PREFIX>_WLS in the WLSSchemaDataSource data source. Doing this will avoid the Upgrade Assistant failure, and also allow the Reconfiguration Wizard to pre-populate fields with the correct values.
  • The <PREFIX>_WLS_RUNTIME database user is reserved for use with a new WLSRuntimeSchemaDataSource, which was introduced in 14c (14.1.2.1.0). This new WLSRuntimeSchemaDataSource will be created when the 14c (14.1.2.1.0) Reconfiguration Wizard (reconfig.sh) is used to upgrade the domain.
You can use your Oracle WebLogic 12c Administration Console to change the user in the WLSSchemaDataSource from <PREFIX>_WLS_RUNTIME to <PREFIX>_WLS.
  1. Log in the 12c (12.2.1.4.0) Administration Console.
  2. In the administration console under Domain Structure, expand Services (by clicking the + next to it). Then click Data Sources.
  3. If the user in Properties field contains <PREFIX>_WLS_RUNTIME , change it to<PREFIX>_WLS.
  4. Save the change.
  5. Use the Change Center to commit the change, if your domain is running in production mode.

Updating Policy Files when Using Enhanced Encryption (AES 256)

If you plan to use enhanced encryption, such as Advanced Encryption Standard (AES) 256, in your upgraded environment, Oracle recommends that you apply the latest required policy files to the JDK before you upgrade.

The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code.

Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK. See Java Cryptography Architecture Oracle Providers Documentation.

Note:

If you attempt to use enhanced encryption without applying these policy files to the JDK before you begin the upgrade, the upgrade can fail and you must restore the entire pre-upgrade environment and start the upgrade from the beginning.

Purging Unused Data

Purging unused data and maintaining a purging methodology before an upgrade can optimize the upgrade process.

Some components have automated purge scripts. If you are using purge scripts, wait until the purge is complete before starting the upgrade process. The upgrade may fail if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas.

Creating a Non-SYSDBA User to Run the Upgrade Assistant

Oracle recommends that you create a non-SYSDBA user called FMW to run the Upgrade Assistant. This user has the privileges required to modify schemas, but does not have full administrator privileges.

SYSDBA is an administrative privilege that is required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for a fully empowered database administrator. When you connect with the SYSDBA privilege, you connect with a default schema and not with the schema that is generally associated with your user name. For SYSDBA, this schema is SYS. Access to a default schema can be a very powerful privilege. For example, when you connect as user SYS, you have unlimited privileges on data dictionary tables. Therefore, Oracle recommends that you create a non-SYSDBA user to upgrade the schemas. The privileges listed below must be granted to user FMW before starting the Upgrade Assistant.

Notes:

The non-SYSDBA user FMW is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW user. Note that privileges required for running the Upgrade Assistant may change from release to release. 

Note:

In this example we are using the name FMW for our non-SYSDBA administrator. Substitute FMW with your admin name.
When granting privileges, make sure that you specify your actual user names and password for the schemas in your domain.
CREATE USER FMW IDENTIFIED BY "<FMW password>";
GRANT pdb_dba TO FMW;
GRANT MANAGE SCHEDULER TO FMW;
GRANT USE ON EDITION ORA$BASE TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_LOB TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_OUTPUT TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_STATS TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON sys.dbms_aq TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON sys.dbms_aqadm TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON sys.dbms_aqin TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON sys.dbms_aqjms TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON utl_file TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON dbms_lock TO FMW WITH GRANT OPTION;
GRANT SELECT ON sys.V_$INSTANCE TO FMW WITH GRANT OPTION;
GRANT SELECT ON sys.GV_$INSTANCE TO FMW WITH GRANT OPTION;
GRANT SELECT ON sys.V_$SESSION TO FMW WITH GRANT OPTION;
GRANT SELECT ON sys.GV_$SESSION TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_scheduler_jobs TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_scheduler_job_run_details TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_scheduler_running_jobs TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_aq_agents TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON sys.DBMS_SHARED_POOL TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_2pc_pending TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_pending_transactions TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_FLASHBACK TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON dbms_crypto TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON dbms_job TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_scheduler_job_classes TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.DBA_DATA_FILES TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.V_$ASM_DISKGROUP TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON SYS.DBMS_ASSERT TO FMW WITH GRANT OPTION; 
GRANT EXECUTE ON DBMS_SCHEDULER TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_data_files TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON UTL_RAW TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_XMLDOM TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_APPLICATION_INFO TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_UTILITY TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_SESSION TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_METADATA TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_XMLGEN TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_DATAPUMP TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_MVIEW TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_objects TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_queue_subscribers TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_subscr_registrations TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_RLS TO FMW WITH GRANT OPTION;
GRANT READ ON CTXSYS.CTX_PENDING TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.V_$PARAMETER TO FMW WITH GRANT OPTION;
GRANT CREATE PROCEDURE TO FMW;
GRANT SELECT ON dba_users TO FMW WITH GRANT OPTION;
GRANT ALL ON sys.v_$parameter TO FMW WITH GRANT OPTION;

Note:

Autonomous Database with Oracle Database 23ai users only: You must add this additional grant when upgrading WLS and MDS schemas:
GRANT ADMINISTER ROW LEVEL SECURITY POLICY TO FMW;

Maintaining Your Custom setDomainEnv Settings

Every domain includes dynamically generated domain and server startup scripts, such as setDomainEnv. Oracle recommends that you do not modify these startup scripts, as any changes you make to them will be overwritten during subsequent domain upgrade operations.

Caution:

Changes made to the setDomainEnv script - or any other startup script - before an upgrade are overwritten by the new, regenerated scripts during the domain reconfiguration process. Create a separate file to store your customized domain settings before you upgrade.

For example, if you want to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.cmd (Windows) or setUserOverrides.sh (UNIX) and configure it to add custom libraries to the WebLogic Server classpath, specify additional java command line options for running the servers, or specify additional environment variables, for instance. Any custom settings you add to this file are preserved during domain upgrade operation and are carried over to the remote servers when using the pack and unpack commands.

Following is an example of startup customizations in a setUserOverrides file:
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

If the setUserOverrides file exists during a server startup, the file is included in the startup sequence and any overrides contained within this file take effect. You must store the setUserOverrides file in the domain_home/bin directory.

Note:

If you are unable to create the setUserOverrides script before an upgrade, you need to reapply your settings as described in Re-apply Customizations to Startup Scripts.

Cloning Predefined Documents and Migrating OWSM Policy Attachments

When upgrading, it is important to note that any predefined documents that have not been customized for your environment are replaced with read-only versions, and new, predefined, read-only documents are added. However, any existing predefined documents that have been customized and any user-created custom policies in the repository are not overwritten.

To ensure that you always get all of the latest policies, Oracle recommends that you clone any predefined documents that you have modified and migrate any policy attachments. For details, see Upgrading the OWSM Repository in Securing Web Services and Managing Policies with Oracle Web Services Manager.

Update the Manually Maintained Response File

This step is only required if you use a manually maintained responses.txt file, as opposed to using the one generated by the Upgrade Assistant.

Silent or “hands free” upgrades can be performed using a response file. The response file can only be created after you have provided the information in the Upgrade Assistant screens. If your responses.txt file was not generated using the Save Response File button in the 14c (14.1.2.1.0) Upgrade Assistant, then you will need to manually update it.

A new WLSRuntimeSchemaDataSource data source was introduced in 14c (14.1.2.1.0), which means the responses.txt file will be different than one from an earlier WebLogic Server version. The Save Response File button in the 14c (14.1.2.1.0) Upgrade Assistant knows about the new WLSRuntimeSchemaDataSource data source, so you don't need to do anything if you use a responses.txt file generated by Upgrade Assistant.

Note:

Oracle recommends that you use the response file generated by the 14c (14.1.2.1.0) Upgrade Assistant. When you use the Upgrade Assistant to perform a readiness check before attempting a schema upgrade, click the Save Response File button. This will produce a response.txt file that will include all of the WLS_RUNTIME.XXX properties.

  1. Open the responses.txt file in an editor.
  2. Use the editor's find feature and search for [WLS.WLS] .
  3. Locate the first WLS.XXX property listed (ex: WLS.WLS.databaseType = Oracle Database) 
    ...
WLS.databaseType = Oracle Database
  4. Copy all of the WLS.XXX properties, including the one from above: 
    ...
WLS.databaseType = Oracle Database
WLS.databaseConnectionString = <connect-string>
WLS.schemaConnectionString = <connect-string>
WLS.schemaUserName = <PREFIX>_WLS
WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
WLS.dbaUserName = system
WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  5. Paste the copied WLS.XXX properties beneath the last copied one. 
    ...
WLS.databaseType = Oracle Database
WLS.databaseConnectionString = <connect-string>
WLS.schemaConnectionString = <connect-string>
WLS.schemaUserName = <PREFIX>_WLS
WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
WLS.dbaUserName = system
WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


WLS.databaseType = Oracle Database
WLS.databaseConnectionString = <connect-string>
WLS.schemaConnectionString = <connect-string>
WLS.schemaUserName = <PREFIX>_WLS
WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
WLS.dbaUserName = system
WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  6. Replace the WLS.XXX in the pasted properties with WLS_RUNTIME.XXX
    ...
WLS.databaseType = Oracle Database
WLS.databaseConnectionString = <connect-string>
WLS.schemaConnectionString = <connect-string>
WLS.schemaUserName = <PREFIX>_WLS
WLS.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
WLS.dbaUserName = system
WLS.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


WLS_RUNTIME.databaseType = Oracle Database
WLS_RUNTIME.databaseConnectionString = <connect-string>
WLS_RUNTIME.schemaConnectionString = <connect-string>
WLS_RUNTIME.schemaUserName = <PREFIX>_WLS_RUNTIME
WLS_RUNTIME.encryptedSchemaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
WLS_RUNTIME.dbaUserName = system
WLS_RUNTIME.encryptedDbaPassword = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    NOTE: Be sure to change the value assigned to the WLS_RUNTIME.schemaUserName property. It must be <PREFIX>_WLS_RUNTIME, not <PREFIX>_WLS .

  7. Save the file, which now has the manually added WLS_RUNTIME.XXX properties in it.