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 12c in Planning an Upgrade of Oracle Fusion Middleware
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.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.