2 Pre-Upgrade Requirements
Before you begin to upgrade Oracle Internet Directory 14c (14.1.2.1.0), you must perform pre-upgrade tasks such as backing up, creating a replica of 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 you have a successful upgrade and limited downtime. - 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. - Creating a Replica of Your Production Environment for Testing
Create a replica of your actual production environment, upgrade the replicated environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment. - 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. - Verify the Database User for the WLSSchemaDataSource Data Source
This step is required if your existing domain has aWLSSchemaDataSource
data source. - Purging Unused Data
Purging unused data and maintaining a purging methodology before an upgrade can optimize the upgrade process. - Creating a Non-SYSDBA User to Run the Upgrade Assistant
To run the Upgrade Assistant, Oracle recommends that you create a non-SYSDBA user calledFMW
, within your PDB. This user has the privileges required to modify schemas, but does not have full administrator privileges. - Shutting Down the Node Managers
Ensure that you have shut down all the local and remote Node Managers before starting the upgrade process.
Pre-Upgrade Checklist
The Pre-Upgrade Checklist identifies tasks that can be performed before you begin your upgrade to ensure 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 will spend offline.
Note:
The pre-upgrade procedures you perform will depend on the configuration of your existing system, the components you are upgrading, and the environment 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.Table 2-1 Tasks to Perform Before You Upgrade to Oracle Fusion Middleware 14c (14.1.2.1.0)
Task | Description |
---|---|
Required Create a complete backup of your existing environment. |
Back up all system-critical files and database(s) 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.
|
Optional Create a replica of 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 create a replica of your production environment. This environment can be used to test the upgrade. See Creating a Replica of Your Production Environment for Testing. |
Required Verify that you are installing and upgrading your product on a supported hardware and software configuration. 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 14c (14.1.2.1.0) product distributions. See Verifying Certification and System Requirements. Oracle recommends that you verify this information right before you start the upgrade as the certification requirements are frequently updated. Note: Make sure that you have applied the latest patches to your components before you upgrade. Review the Oracle Fusion Middleware Infrastructure release notes to see if there are any mandatory patches required for the software products that you are installing. See Install and Configure in Release Notes for Oracle Fusion Middleware Infrastructure. |
Optional Purge any outdated or unused data before you upgrade. |
To optimize performance, Oracle strongly recommends that you purge data and objects that will not be used in the upgraded environment. See Purging Unused Data. |
Required Change the database user assigned to the
|
If the database user for the
This step is required only if your existing domain has a
See Verify the Database User for the WLSSchemaDataSource Data Source |
Optional Create a Non-SYSDBA user to run the Upgrade Assistant. |
Oracle recommends that you create the FMW user to run Upgrade Assistant. User FMW can run the Upgrade Assistant without system administration privileges. |
Optional Shut down all the local and remote Node Managers before starting the upgrade process. |
Parent topic: Pre-Upgrade Requirements
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.
-
Backing Up Your Environment in Administering Oracle Fusion Middleware
-
Upgrading and Preparing Your Oracle Databases for 14c (14.1.2.1.0) in Planning an Upgrade of Oracle Fusion Middleware
- Backing Up the Schema Version Registry Table
Your system backup must include theSYSTEM.SCHEMA_VERSION_REGISTRY$
table or theFMWREGISTRY.SCHEMA_VERSION_REGISTRY$
table. - 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.
Parent topic: Pre-Upgrade Requirements
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.Parent topic: Creating a Complete Backup
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.
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.
Parent topic: Creating a Complete Backup
Creating a Replica of Your Production Environment for Testing
Create a replica of your actual production environment, upgrade the replicated environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.
Creating a replica of your production environment for testing is recommended, but not required.
Note:
It is beyond the scope of this document to describe the procedures to create a replica for all components and operating systems. These 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.-
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 replicated production environment to help identify potential upgrade issues with your data, but you must perform a complete test upgrade on a replicated environment to ensure a successful upgrade.Parent topic: Pre-Upgrade Requirements
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. - 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. - 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). - Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware
If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK before you begin.
Parent topic: Pre-Upgrade Requirements
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).
Parent topic: Verifying Certification and System Requirements
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.
- 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.
Parent topic: Verifying Certification and System Requirements
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).
Note:
If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade.Parent topic: Verifying Certification and System Requirements
Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware
If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK before you begin.
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.
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
.
Parent topic: Verifying Certification and System Requirements
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
.
- 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 theWLSSchemaDataSource
, 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 theWLSSchemaDataSource
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 newWLSRuntimeSchemaDataSource
, which was introduced in 14c (14.1.2.1.0). This newWLSRuntimeSchemaDataSource
will be created when the 14c (14.1.2.1.0) Reconfiguration Wizard (reconfig.sh) is used to upgrade the domain.
<PREFIX>_WLS_RUNTIME
to
<PREFIX>_WLS
.
- Log in the 12c (12.2.1.4.0) Administration Console.
- In the administration console under Domain Structure, expand Services (by clicking the + next to it). Then click Data Sources.
- If the user in Properties field contains
<PREFIX>_WLS_RUNTIME
, change it to<PREFIX>_WLS
. - Save the change.
- Use the Change Center to commit the change, if your domain is running in production mode.
Parent topic: Pre-Upgrade Requirements
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.
Parent topic: Pre-Upgrade Requirements
Creating a Non-SYSDBA User to Run the Upgrade Assistant
To run the Upgrade Assistant, Oracle recommends that you create a non-SYSDBA user called FMW
, within your PDB. This user has the privileges required to modify schemas, but does not have full administrator privileges.
Note:
If you run the commands incdb
, it fails to create some of the grants successfully.
Note:
The non-SYSDBA userFMW
is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW
user. The privileges required for running the Upgrade Assistant may change from release to release.
By default, the v$xatrans$
table does not exist. You must run the XAVIEW.SQL
script to create this table before creating the user.
Before creating the user, confirm whether the v$xatrans$
table was created by a prior upgrade. As a system user, run the following command from sqlplus
:
select object_name, owner, object_type from dba_objects where object_name like '%XATRANS%'
If the v$xatrans$
table was created by a prior upgrade, you will see that the four objects are already available.
password
is the password that you set for the FMW user. When granting privileges, make sure that you specify your actual password.create user FMW identified by password;
grant dba to FMW;
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_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 sys.dbms_aq 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_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to FMW with grant option;
grant select on sys.DBA_TABLESPACE_USAGE_METRICS 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 select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system 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 ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option;
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;
If you are upgrading Oracle Identity Manager (OIM) schema, ensure that the FMW user has the following additional privileges:
grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;
Parent topic: Pre-Upgrade Requirements
Shutting Down the Node Managers
Ensure that you have shut down all the local and remote Node Managers before starting the upgrade process.
The Node Managers should remain shut down until you start the WebLogic Administration Server after completing the upgrade. When the WebLogic Administration Server is up and running, start the Node Managers, followed by the Managed Servers.
Parent topic: Pre-Upgrade Requirements