A Performing an Out-of-Place Domain Directory Upgrade

By default, Fusion Middleware upgrades are performed in-place, which overwrites the existing domain directory. However, you have the option of upgrading to 12c (12.2.1.3.0) using a different domain directory. This option is called an out-of-place upgrade and it allows you to keep your existing domain directory intact.

Perform these tasks to complete an out-of-place upgrade:

• About Upgrading a Domain Directory Out of Place
  Standard Fusion Middleware upgrades are performed in place which updates and overwrites the existing domain. If you want to preserve your existing domain, then you can perform an out-of-place domain directory upgrade, but your schemas are still upgraded in place.
• Performing an Out-of-Place Domain Directory Upgrade on the Same Host
  Understanding the procedure of performing an out-of-place domain directory upgrade on the same host.
• Performing an Out-of-Place Domain Directory Upgrade on a Different Host
  Understanding the procedure to perform an out-of-place upgrade on a different host.
• Deinstalling the 11g Applications (Optional)
  Procedure to deinstall the 11g applications and domain setup.

About Upgrading a Domain Directory Out of Place

Standard Fusion Middleware upgrades are performed in place which updates and overwrites the existing domain. If you want to preserve your existing domain, then you can perform an out-of-place domain directory upgrade, but your schemas are still upgraded in place.

When upgrading from Oracle Fusion Middleware 11g or a previous 12c release to 12c (12.2.1.3.0), schemas and domain directory upgrades are performed in place which updates the existing 11g or 12c domains during the upgrade.

If you prefer to leave your existing domain directory intact, you can perform an out-of-place domain directory upgrade using a new domain directory on the same - or different - host using the steps described in this chapter.

Caution:

When performing an out-of-place domain directory upgrade to , it is important to note that the existing 11g or 12c (12.1.3.0.0, 12.2.1.0.0, 12.2.1.1.0, and 12.2.1.2.0) schemas will be upgraded in-place. Your pre-upgrade environment must be shut down during the out-of-place domain directory upgrade process.

Performing an Out-of-Place Domain Directory Upgrade on the Same Host

Understanding the procedure of performing an out-of-place domain directory upgrade on the same host.

Perform the following tasks to complete the out-of-place domain directory upgrade on the same host at the existing domain:

Note:

If you are upgrading domain that is on a different host, see Performing an Out-of-Place Domain Directory Upgrade on a Different Host.

Note:

The Fusion Middleware 12c certification matrix includes only 12.1 databases. Hence, the reference to 11 in these procedures is to the Fusion Middleware 11g schemas and not to the Oracle 11g database version.

1. Stop all processes, including the Administration Server, Managed Servers, and Node Manager.
   
2. Create a Complete Backup of all Files from the Existing Domain
   
3. Restore the domain backup files to a new location.
   
4. Install the 12c (12.2.1.3.0) distributions in a new Oracle home.
   
5. Upgrade the cloned environment using the standard upgrade procedures.
   
6. Validate that the newly upgraded domain functions as expected.
   

Stop all processes, including the Administration Server, Managed Servers, and Node Manager.

You must stop all processes, including the Administration Server, Managed Servers, and Node Manager.

Do not stop the database before starting the upgrade.

• 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 and any managed servers.

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 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.

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 system components, such as Oracle HTTP Server, use the stopComponent script:

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

• (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

• (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Step 3: Stop Oracle Identity Management Components

Stop any Oracle Identity Management components, such as Oracle Internet Directory:

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

• (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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.

To stop the Administration Server, use the stopWebLogic script:

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

• (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 5: Stop Node Manager

To stop Node Manager, close the command shell in which it is running.

Alternatively, after setting the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down. See stopNodeManager in WLST Command Reference for WebLogic Server.

Create a Complete Backup of all Files from the Existing Domain

Make sure that you have created a complete backup of your entire pre-upgrade deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

For more information on backing up your files, see Backing Up Your Environmentin the Oracle® Fusion Middleware Administrator's Guide.

During the upgrade you must have “read" access to the files in the backup storage:

• 11g or previous 12c domain home

• The /nodemanager directory located in the MW_HOME/wlserver_10.3/common/

For more information, see Backing Up Your Environmentin the Oracle® Fusion Middleware Administrator's Guide.

Note:

Do not proceed with the upgrade until you have a complete backup.

Restore the domain backup files to a new location.

Copy the files you backed up in Create a Complete Backup of all Files from the Existing Domain to a new location.

You will point to this location in Upgrade the cloned environment using the standard upgrade procedures.

Install the 12c (12.2.1.3.0) distributions in a new Oracle home.

You must obtain and install the12c (12.2.1.3.0) product distributions for the components you will be upgrading. However, you do not need to configure a new12c (12.2.1.3.0) domain.

For detailed instructions, see Planning an Installation of Oracle Fusion Middleware and the component-specific installation guides for the component(s) you are installing.

Upgrade the cloned environment using the standard upgrade procedures.

Perform the upgrade on the domain you created in Restore the domain backup files to a new location..

Each component has an upgrade guide that describes the procedures required to upgrade from your Oracle Fusion Middleware 11g or previous 12c infrastructure topology to the new 12c (12.2.1.3.0) topology. The guides are located in the Upgrade tab of the Oracle Fusion Middleware online library.

• 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.
• Using the Upgrade Assistant to Run a Pre-Upgrade Readiness Check
  For most components, the Upgrade Assistant can be run in -readiness mode to perform a read-only, pre-upgrade check on your domain. If issues are detected, you can correct them before starting the actual upgrade.

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. 

By default, the v$xatrans$ table does not exist. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, the grant select privilege on thev$xatrans$ table is required only by Oracle Identity Governance. If you do not require Oracle Identity Governance for configuration, or if you do not have the v$xatrans$ table, then remove the following line from the script:

   grant select on v$xatrans$ to FMW with grant option;

In the example below, 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;

Using the Upgrade Assistant to Run a Pre-Upgrade Readiness Check

For most components, the Upgrade Assistant can be run in -readiness mode to perform a read-only, pre-upgrade check on your domain. If issues are detected, you can correct them before starting the actual upgrade.

You can run the readiness check while the system is online. Depending on the comprehensiveness of the checks, the readiness checks can take more time to complete. Consider running the check during off-peak hours.

To perform a readiness check on your pre-upgrade environment, launch the Upgrade Assistant in -readiness mode:

1. Change directory to ORACLE_HOME/oracle_common/upgrade/bin. on UNIX operating systems or ORACLE_HOME\oracle_common\upgrade\bin on Windows operating systems.
2. To start the Upgrade Assistant on UNIX operating systems:
   ./ua -readiness
3. To start the Upgrade Assistant on Windows operating systems:
   ua.bat -readiness
4. Provide the required information in each of the Upgrade Assistant screens.

The screens you see will vary depending on the upgrade options you select. Consult your component-specific upgrade documentation for complete details.

Validate that the newly upgraded domain functions as expected.

Perform the usual administration tasks using the new domain and verify that the components work as expected.

You do not need to decommission the 11g Oracle home, however if you would like to remove it, see Deinstalling the 11g Applications (Optional).

Performing an Out-of-Place Domain Directory Upgrade on a Different Host

Understanding the procedure to perform an out-of-place upgrade on a different host.

Perform these steps to compete an out-of-place upgrade on a different host.

The Fusion Middleware 12c certification matrix includes 12.1 databases, therefore, the reference to 11 in this chapter is to the Fusion Middleware 11g schemas and not to the Oracle 11g database version.

1. Stop all processes, including the Administration Server, Managed Servers, and Node Manager. (Host A)
   
2. Create a complete backup of all files from the host machine. (Host A)
   
3. Configure the target machine Host B with the same host name and IP address as Host A.
   
4. Restore from backup the pre-upgrade domain from Host A to Host B.
   
5. Install the product distributions in a new Oracle Home. (Host B)
   
6. Perform the upgrade using the standard upgrade procedures. (Host B)
   
7. Validate that the newly upgraded domain functions as expected.
   

Stop all processes, including the Administration Server, Managed Servers, and Node Manager. (Host A)

You must stop all processes, including the Administration Server, Managed Servers, and Node Manager, if they are started on the host. Do not stop the database at this time.

For example, to stop the Administration Server:

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

Create a complete backup of all files from the host machine. (Host A)

Make sure that you have created a complete backup of your entire pre-upgrade deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

See Backing Up Your Environmentin the Oracle® Fusion Middleware Administrator's Guide.

During the upgrade you must have “read" access to the files in the backup storage:

• Pre-upgrade domain home

• The /nodemanager directory located in the MW_HOME/wlserver_10.3/common/

Configure the target machine Host B with the same host name and IP address as Host A.

The host name and IP address of the target machine (Host B) must be made identical to the source host (Host A). This will require you to change the IP address and name of the source machine or decommission the source machine to avoid conflicts in the network.

The process of changing an IP address and host name vary by operating system. Consult your operating system's administration documentation for more information.

Restore from backup the pre-upgrade domain from Host A to Host B.

Restore the files you backed up in Create a complete backup of all files from the host machine. (Host A) using the same directory structure that was used in the pre-upgrade environment. The directory structure on Host B must be identical to the structure used on Host A.

For detailed information about restoring your files to the target machine, see Recovering Your Environmentin Oracle® Fusion Middleware Administrator's Guide.

Install the product distributions in a new Oracle Home. (Host B)

You must obtain, install and configure the product distributions for the components you will be upgrading.

See Planning an Installation of Oracle Fusion Middleware and the component-specific installation guides for the component(s) you are installing.

Perform the upgrade using the standard upgrade procedures. (Host B)

Each component or suite of components has an upgrade guide that describes the procedures required to upgrade the infrastructure topology to the latest topology. The guides are located on the Upgrade landing page of the Oracle Fusion Middleware 12c (12.2.1) online library.

The Node Manager upgrade procedure requires access to the original Node Manager files. If you are upgrading from a supported 11g release, then use the 11g Node Manger files that were backed up from the source machine as part of Configure the target machine Host B with the same host name and IP address as Host A..

Validate that the newly upgraded domain functions as expected.

Perform the usual administration tasks using the new domain and verify that the components work as expected.

You do not need to decommission the existing Oracle home, however if you would like to remove it, see Deinstalling the 11g Applications (Optional).

Deinstalling the 11g Applications (Optional)

Procedure to deinstall the 11g applications and domain setup.

While not required, you can use these steps to deinstall the 11g application and domain setup after the upgrade. Do not deinstall a domain that is still being referenced by a non-upgraded component. If you are unsure, leave the domain intact.

Note:

The commands mentioned in this section must be run from the 11g Oracle Home that you are removing and not from the new home that was created as part of the 12c upgrade process.

1. Shutdown all the 11g servers and processes (including the Admin Server, Managed Servers and Node Manager). See Starting and Stopping Oracle WebLogic Server Administration and Managed Servers in the Oracle® Fusion Middleware Administrator's Guide.
2. To remove the Oracle Home, start the Oracle Universal Installer in -deinstall mode.

   (UNIX) ORACLE_HOME/oui/bin

   ./runInstaller.sh -deinstall

   (Windows) ORACLE_HOME\oui\

   binsetup.exe -deinstall

3. On the Deinstall screen, specify the 11g Oracle home to deinstall. Click Deinstall to continue.
4. On the Warning screen, select whether or not you want the OUI to remove the Oracle home directory. Click Yes to have the Oracle Universal Installer remove the software and Oracle home. There is no undo.
5. To remove the 11g Oracle common home, start the Oracle Universal Installer in -deinstall mode from the following directory:

   (UNIX) ORACLE_HOME/oracle_common/oui/bin

   ./runInstaller -deinstall -jreLoc JRE_LOCATION

   (Windows) ORACLE_HOME\oracle_common\oui\

   binsetup.exe -deinstall -jreLoc JRE_LOCATION

6. On the Deinstall screen, verify the Oracle common home that is about to be removed is the correct one and click Deinstall to continue.
7. On the Warning screen, select whether or not you want to remove the Oracle Common home directory. Click Yes to remove the software and Oracle common home.
8. To remove the WebLogic Server, start the WebLogic Uninstall program from the following directory:

   (UNIX) ORACLE_HOME/utilw/uninstall

   ./uninstall.sh

   (Windows) ORACLE_HOME\utils\uninstall

   uninstall.exe

9. Click Next to start the uninstall program.
10. Select the components to uninstall by selecting the check boxes next to the installed components. Note that by default, all installed components are selected.
11. After selecting the components to uninstall, click Next to complete the uninstall.