Sharing The Application Tier File System in Oracle E-Business Suite Release 12.2 (Doc ID 1375769.1)

The most current version of this document can be obtained in My Oracle Support Knowledge Document 1375769.1 .
There is a change log at the end of this document.

Note:

• Sharing the application tier file system is not supported on application tier server nodes running Windows.

Contents

Section 1: Overview1.1 Concepts and Terminology1.2 Oracle E-Business Suite Release 12.2 Architecture
1.3 Oracle E-Business Suite Release 12.2 File System Layout for Shared Application Tier
Section 2: Planning Deployment Options
Section 3: Configuring a Shared Application Tier File System with 12.2 Rapid Install
3.1 Install the Database Tier on Node 1
3.2 Install the Primary Application Tier on Node 2
3.3 Execute the Adpreclone Utility on the Run and Patch File System
Section 4: Adding a Node to the Shared Application Tier File System
4.1 Export the Required Application Tier File System From the Primary Application Tier Node
4.2 Mount the Application Tier File System on the Secondary Application Tier Node
4.3 Add the Secondary Application Tier Node to the Farm

Section 1: Overview

1.1 Shared Application Tier File System Concepts and Terminology

You can configure multiple application node machines working with a single Oracle E-Business Suite database node. This creation of a "multi-node" Oracle E-Business Suite instance is frequently done to lower cost of ownership (many small machines are cheaper than one big one), increase fault tolerance (one machine fails, others do not), or scale the instance (support more users and a greater load).
When configuring Oracle E-Business Suite to use a shared application tier file system, the application tier node can be configured to perform any of the standard application tier services, such as Forms, Web, and Concurrent Processing (Batch).
Note the following definitions:

Node

A node is a logical set of processes running on one hardware machine. Sometimes a node is also referred to as a "server" or an "instance". In a single-node installation of Oracle E-Business Suite, all the applications processes (including the database processes) run on one node, whereas in a multi-node installation, the processes are distributed across multiple nodes.A multi-node installation of Release 12.2 supports both shared and non-shared application tier file systems. An application tier file system consists of:

• APPL_TOP file system (APPL_TOP and COMMON_TOP directories).
• Application tier technology stack file system (OracleAS 10.1.2, Oracle WebLogic Server, and WebTier Oracle Homes).
• Instance Home (INST_TOP) file system. Each application tier has a unique Instance Home file system associated with it.
• OraInventory directory, which stores information about all the components installed in various Oracle Homes

Service

A service is a functional set of Oracle E-Business Suite application processes running on one or more nodes. Where applicable, the term 'service' replaces the more traditional term of 'server'.

Application Tier Services

The following are the major application tier services:

• Root services
• Web Entry Point services
• Web Application services
• Batch Processing services
• Other services

Primary Application Tier Node

A primary application tier node is the first (and perhaps only) application tier node where the APPL_TOP, COMMON_TOP, OracleAS 10.1.2 Oracle Home, WebLogic and the WebTier Oracle Home are installed and configured.

Secondary Application Tier Node

A secondary application tier node is an additional application tier node where the APPL_TOP, COMMON_TOP, OracleAS 10.1.2 Oracle Home, Oracle WebLogic Server and WebTier Oracle Homes are visible and configured.

The APPL_TOP, COMMON_TOP, OracleAS 10.1.2 Oracle Home, Oracle WebLogic Server, and WebTier Oracle Home file systems are mounted on this node either from the primary application tier node or from an NFS server.

Instance Home

The Instance Home is the top-level directory that contains all the instance specific files associated with an application tier node (APPL_TOP and OracleAS 10.1.2 Oracle Home files). In a shared file system, each application tier will have a unique Instance Home.

1.2 Shared Application Tier File System Architecture

The Oracle E-Business Suite Release 12.2 architecture is a framework for multi-tiered, distributed computing. In this model, various services are distributed among multiple levels, or tiers, as shown in the figures below. Refer to Oracle Applications Concepts in the Oracle Applications Documentation Library to learn more about Oracle E-Business Suite architecture.
In a shared file system, all application tier files including the instance_top are installed on a shared disk resource, which is mounted on each application tier node. Any application tier node can be configured to perform any of the standard application tier services, such as Forms, Web and Concurrent Processing (Batch) services. All changes made to the shared file system are immediately accessible to all application tier nodes.

Note:

• All application tier nodes in a shared file system must be running the same operating system.
• Shared Application Tier File System can not be a read-only-file system unlike in the previous releases.

Note for customers using OCFS2 File System:

• It is recommended to format the OCFS2 file system for the application tier with the default block size and not use larger block sizes supported by OCFS2. Refer to OCFS2 Best Practices Guide for more information.

 

General Three Tier Architecture

Application/Database Tier Components

Release 12.2 Dual File System Setup on a Single Tier

1.3 Shared Application Tier File System Layout

When setting up Oracle E-Business Suite to use a shared application tier file system, an application tier node can be configured to perform any of the standard application tier services, such as Forms, Web, or Concurrent Processing (Batch).

An application tier will have a unique Instance Home associated with it. The instance home can be placed at the default shared location as configured by rapid install/rapid clone or can be relocated to a local disk on the respective application tier. Oracle recommed the instance home to be configured on the shared disk.

Note: The following must all be true In a shared file system:

• User ID and Group ID should be consistent across all nodes to avoid file access permission issues.
• The same absolute path must be retained for the shared file system mount points on each node.
• The value for the context variable "s_atName" must be same across all the application tier node context files.

Section 2: Planning Deployment Options

Shared Application Tier File System is the preferred deployment model for Oracle E-Business Suite Release 12.2.

In Release 12.2, two application tier file systems are installed on the primary application tier node. Provided to support online patching, they are known as the run file system and the patch file system. The run file system is where the application tier processes are run from. The patch file system is used by the adop (AD Online Patching) utility to update Oracle E-Business Suite code and configuration during an online patching cycle.

Note: The role of the two file systems swaps after each patching cycle, with what was the patch file system becoming the new run file system, and what was the run file system becoming the new patch file system.

For more information about online patching, refer to Oracle E-Business Suite Concepts and Oracle E-Business Suite Maintenance Guide.

Section 3: Configuring Shared Application Tier File System with Release 12.2 Rapid Install

This section describe the steps an administrator need to perform to prepare for a shared file system installation. The Rapid Install utility only lay out a primary application tier . The subsequent nodes that share the file must be added using the add node utility as described in the section 4 of this document.

The 12.2 Rapid Install utility can be used to install a new, fully configured Oracle E-Business Suite system, including the latest certified Oracle E-Business Suite technology stack and all patches, product family release update packs, release update packs, and other updates available at the time of this Oracle E-Business Suite release. Rapid Install employs a wizard (RapidWiz) that guides you through the screens used to carry out the selected task. On the wizard screens, you enter configuration values for your system.

The Rapid Install utility supports single node installations (where the database and the application tier are installed and configured on one machine), and multinode installations (where the database and the application tier nodes are spread across different machines). Refer to Oracle E-Business Suite Installation Guide: Running Rapid Install for more information.

This document describes a two node installation scenario, where the database tier is installed on node 1 (primary database tier node) and the application tier is installed on node 2 (primary application tier node). The steps below show the sequence needed to complete the installation.

Note: It is recommended that you stage the installation software on a remote file system that can be mounted and accessed from the different nodes on where you are going to perform the installation.

3.1 Install the Database Tier on Node 1

Start the RapidWiz utility on node 1. The first screen lists the components that are included in, or supported by, this release of Oracle E-Business Suite. You can see from this list that a new installation includes a fresh Oracle 11g Release 2 (11gR2) database. Enter the appropriate values as prompted by the Installer for the database and the application tier nodes, and complete the database tier installation.

Note: When entering the location of the install directories for the application tier install, you can either enter the location of a local drive on the machine, or an NFS location that is accessible from the primary application tier node. The recommendation is to install the application tier file system on to a remote file system that can be mounted across various application tier nodes.

3.2 Install the Primary Application Tier on Node 2

Start RapidWiz on node 2. The database and associated database tier processes must be running to complete this installation successfully. The first screen lists the components that are included in, or supported by, this release of Oracle E-Business Suite. You can see from the list that a new installation of the application tier includes the Oracle Fusion Middleware Stack (which includes Oracle WebLogic Server and the Web Tier), and the Oracle Application Server stack, which includes the forms and reports and the Oracle E-Business Suite application tier code.

A successful completion of application tier installation on node 2 configures the following services:

• Root Service, comprising the Node Manager.
• Web Administration Service, comprising WebLogic Administration Server and TNS Listener for FNDFS.
• Web Entry Point Services, comprising the Oracle Process Notification Server (OPMN) and the Oracle HTTP Server (OHS).
• Web Application Services, comprising the Managed Servers oacore, forms, oafm and form-c4ws.
• Batch Processing Services, comprising the concurrent processing services, ICSM and JTF fullfillment server.
• Other Services, comprising the Forms services and mobile web application services.

3.3 Execute adpreclone Utility on the Run and Patch File System

Note: Ensure that value of the AutoConfig variable " s_shared_file_system" is set to "true" ( without the quote) on the primary application tier node. This variable will be automatically set to "true" if the shared file system option was chosen during the Rapid Install.

The adpreclone utility shipped with Oracle E-Business Suite packages the required application tier components to a staging directory for subsequent clone and add node operations. You must run this utility before proceeding to Section 4 of this document.

The adpreclone utility requires the WebLogic Administration process to be running from the file system where the utility is run. This is required to package the Oracle Fusion Middleware components and its configuration. Perform the commands shown below on both the run and patch file systems:

On the run file system:

$ cd <inst-top-run-fs>/admin/scripts
$ ./adadminsrvctl.sh start
$ ./adpreclone.pl appsTier

Once the utility completes, shut down the application tier processes:

$ ./adstpall.sh <apps-user-name>/<apps-password>

On the patch file system:

$ cd <inst-top-patch-fs>/admin/scripts
$ ./adadminsrvctl.sh start forcepatchfs
$ ./adpreclone.pl appsTier

Once the utility completes, shut down the application tier processes.

$ ./adstpall.sh <apps-user-name>/<apps-password> forcepatchfs

Follow section 4 after completing the installation of the database tier node and the primary application tier node.

Please note that an administrator can also use the Rapid Clone utlity to lay down the file system, configure the primary application tier node and subsequently add secondary application tier nodes using the share file system.

Note:Please note that an administrator can also use the Rapid Clone utlity to lay down the file system, configure the primary application tier node and subsequently add secondary application tier nodes using the share file system.

Section 4: Adding a Node to the Shared Application Tier File System

The tasks listed in this section assume that you have completed Section 3 of this document. The node to be added now will be known as the secondary application tier node. This node can be configured to run all services except for the Oracle WebLogic Administration Server

Note:

• The fully qualified hostname of the application tier node to be added must be present in the sqlnet.ora file in the <Database_Oracle_ Home>/network/admin/<context-name> directory. (See tcp.invited_nodes parameter.)
• The database and TNS listener must be running before the steps listed below are performed.
• In a shared file system, User ID and group ID should be consistent across all nodes to avoid file access permission issues.
• The same absolute path must be used for the shared file system mount points on each node.
• Ensure that value of the AutoConfig variable "s_atName" is same across all the application tier node context files.
• Ensure that value of the AutoConfig variable " s_shared_file_system" is set to "true" ( without the quote) on the primary application tier node. This variable will be automatically set to "true" if the shared file system option was chosen during the Rapid Install.
• The oraInventory directory from the primary application tier and the oraInst.loc file must be accessible to all nodes sharing the application tier file system.
• It is recommended to keep the Instance Top ( INST_TOP) on the shared file system for 1) Ease of maintenance 2) The number of application tier processes writing to this location is limited when compared with the previous releases.

The following example will be used to explain the provisioning process better.

• Database tier is installed on: db.company.com
• Primary Application tier is installed on: appstier1.company.com
• Secondary Application tier to be added: appstier2.company.com
• Directory location of the application tier file system on the primary Node: /u01/12.2
• Primary Application tier run file system: /u01/12.2/fs1
• Primary Application tier patch file system: /u01/12.2/fs2
• OraInventory Directory: /u01/12.2/oraInventory

Before proceeding with the instructions given below, ensure that steps listed in section 3.3 Execute the Adpreclone Utility on the Run and Patch File System of this document is successfully completed.

4.1 Export the Required Application Tier File System From the Primary Node

The following application tier file systems need to be exported from the primary application tier:

• /u01/12.2/fs1: The file system configured to be the run file system on install
• /u01/12.2/fs2: The file system configured to be the patch file system on install
• /u01/12.2/fs_ne: The file system configured to be the non-edition file system on install
• /u01/12.2/oraInventory: The OraInventory directory

On a Linux system, execute the following commands as the root user to mount the application tier file system on to the secondary node.

1. Add the following lines to the /etc/exports file:
   
   /u01/12.2/fs1 appstier2.company.com(rw,sync,no_root_squash)
/u01/12.2/fs2 appstier2.company.com(rw,sync,no_root_squash)
/u01/12.2/fs_ne appstier2.company.com(rw,sync,no_root_squash)
/u01/12.2/oraInventory appstier2.company.com(rw,sync,no_root_squash)
   Note: The export options described above may need to be adjusted according to the security requirements of your organization. Also, the available options may differ on other platforms.
   
   
2. Check whether the NFS daemons are running:
   
   $ /sbin/service nfs status
3. If the NFS daemons are not running, execute the following command to start them:
   
   $ /sbin/service nfs start
4. Once the NFS daemons are running, execute the following command to export the application tier file system:
   $ $ /usr/sbin/exportfs -a
5. Ensure the application tier file systems are exported by executing the following command:
   $ /usr/sbin/exportfs

4.2 Mount the Application Tier File System on the Secondary Node

The following application tier file system need to be mounted on the secondary application tier node from the primary node.

• /u01/12.2/fs1: The file system configured to be the run file system on install
• /u01/12.2/fs2: The file system configured to be the patch file system on install
• /u01/12.2/fs_ne: The file system configured to be the non-edition file system on install
• /u01/12.2/oraInventory: The OraInventory directory

1. Check whether the NFS daemons are running:
   $ /sbin/service nfs status
2. If the NFS daemons are not running, execute the following command to start them:
   $ /sbin/service nfs start
3. Create directories as follows:
   
   $ /bin/mkdir -p /u01/12.2/fs1$ /bin/mkdir -p /u01/12.2/fs2
$ /bin/mkdir -p /u01/12.2/fs_ne$ /bin/mkdir -p /u01/12.2/oraInventory
4. Change the ownership and group permissions of these directories to be the same as that from the primary application tier node. For example if oracle is the owner of the file system and is in the group dba, you need to execute the commands shown below:
   $ /bin/chown -R oracle /u01/12.2/fs1
$ /bin/chown -R oracle /u01/12.2/fs2
$ /bin/chown -R oracle /u01/12.2/fs_ne
$ /bin/chown -R oracle /u01/12.2/oraInventory
$ /bin/chgrp -R dba /u01/12.2/fs1
$ /bin/chgrp -R dba /u01/12.2/fs2
$ /bin/chgrp -R dba /u01/12.2/fs_ne
$ /bin/chgrp -R dba oraInventory
5. Use the following commands to mount the application tier file system from the primary node to the secondary node:
   $ cd /u01/12.2/fs1
For NFS V3$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp appstier1.company.com:/u01/12.2/fs1 .
For NFS V4
$ /bin/mount -t nfs -o rw,bg,hard,timeo=600,wsize=65536,rsize=65536 appstier1.company.com:/u01/12.2/fs1 .

$ cd /u01/12.2/fs2
For NFS V3
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp appstier1.company.com:/u01/12.2/fs2 .
For NFS V4
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 appstier1.company.com:/u01/12.2/fs2 .

$ cd /u01/12.2/fs_ne
For NFS V3
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp appstier1.company.com:/u01/12.2/fs_ne .
   For NFS V4
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 appstier1.company.com:/u01/12.2/fs_ne .
   
   $ cd /u01/12.2/oraInventory
For NFS V3
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp appstier1.company.com:/u01/12.2/oraInventory .
For NFS V4
$ /bin/mount -t nfs -o rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 appstier1.company.com:/u01/12.2/oraInventory .
   Note: Be sure to include the space and period at the end of each mount command, the period denoting that the current directory is to be used as the mount point.
   
   
   Refer to Appendix A: Mount Options For Network File Systems for the mount option to be used for mounting the application tier file system.
   
6. Prepare to add file system information to the /etc/fstab file, so that the primary application tier file system will be automatically mounted on reboot:
   $ cd /etc$ vi fstab
7. In vi (or an equivalent editor), add lines as per the following example:
   For NFS V3
appstier1.company.com:/u01/12.2/fs1 /u01/12.2/fs1 nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp 0 0
For NFS V4
appstier1.company.com:/u01/12.2/fs1 /u01/12.2/fs1 nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 0 0For NFS V3
appstier1.company.com:/u01/12.2/fs2 /u01/12.2/fs2 nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp 0 0
For NFS V4
appstier1.company.com:/u01/12.2/fs2 /u01/12.2/fs2 nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 0 0

For NFS V3
appstier1.company.com:/u01/12.2/fs_ne /u01/12.2/fs_ne nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp 0 0
For NFS V4
appstier1.company.com:/u01/12.2/fs_ne /u01/12.2/fs_ne nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 0 0
For NFS V3
appstier1.company.com:/u01/12.2/oraInventory /u01/12.2/oraInventory nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp 0 0
For NFS V4
appstier1.company.com:/u01/12.2/oraInventory /u01/12.2/oraInventory nfs rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536 0 0

4.3 Add the Secondary Application Tier Node to the Farm

The primary decision that an administrator need to make before proceeding with the steps given below is to decide what services are going to be configured on the secondary node. The new node that you are planning to add can run any service except for WebLogic Administration Server, which is only configured on the primary application tier node. Follow the steps given below to add a node.

There are additional steps that need to be performed before adding new nodes if the Oracle E-Business Suite System is at ARR 2019 CPU patch level. Please refer to Appendix C of My Oracle Knowledge Support Document 1383621.1 to understand and implement these additional steps.

4.3.1 Prepare the PairsFile for Configuring the Run File System

DELTA 6 Code Level And Below

A sample pairsfile for the run file system is instantiated into the relevant instance home on the primary application tier node. The name of the file is <SID>_<primary_node_name>_<file_edition_type>.txt, located in the <INST_TOP>/appl/admin/ directory. For a configuration with an instance name of VIS, the pairsfile will be /u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1_run.txt.

Carry out the instructions below to prepare the pairsfile for configuring the run file system.

1. Create the required directories, then copy the pairsfile into a directory of your choice on the secondary application tier node. For example:
   $ mkdir -p /u01/12.2/pairsfiles/run
$ cd /u01/12.2/pairsfile/run$ cp /u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1_run.txt myrunpairsfile.txt
2. Make necessary modifications to the pairsfile. Some of the inputs required for the Add Node API are automatically filled in. The sections that you need to fill in are the following.
   
   [Instance Specific] - This is instance specific information for the node you are going to add. Refer to the source context file for reference.
   
   [Services]

4.3.2 Configure the Run File System on the Secondary Node

Carry out the instructions below to configure the run file system on the secondary node.

1. Ensure the correct perl utility is in the $PATH. You must use the perl utility installed in the Fusion Middleware Oracle Home.
   
   For example:
   
   $ export PATH=/u01/12.2/fs1/FMW_Home/webtier/perl/bin:$PATH
2. Ensure the WebLogic Administration Server from the run file system is running on the primary application tier node.
   
3. Execute the Clone Context Utility to configure the run file system. For example:
   $ cd /u01/12.2/fs1/EBSapps/comn/clone/bin
$ /u01/12.2/fs1/FMW_Home/webtier/perl/bin/perl ./adclonectx.pl \
addnode contextfile=/u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1.xml \
pairsfile=/u01/12.2/pairsfile/run/myrunpairsfile.txt \
outfile=/u01/12.2/fs1/inst/apps/VIS_appstier2/appl/admin/VIS_appstier2.xml
4. Review the EBSProvisioner.log file created in the current directory to ensure the add node program completed without any errors.

4.3.3 Prepare the PairsFile for Configuring the Patch File System

Carry out the instructions given below to prepare the pair files for configuring the patch file system.

1. A sample pairsfile each for the patch file system is instantiated into the respective instance home on the primary application tier node. The file is called <SID>_<primary_node_name>_<file_edition_type>.txt, and located in the <inst_top>/appl/admin/ directory. For a configuration with an instance name of VIS, the pairsfile will be /u01/12.2/fs2/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1_patch.txt.
   
2. Create the required directories and copy the pairsfile into a directory of your choice on the secondary application tier node. For example:
   
   $ /bin/mkdir -p /u01/12.2/pairsfiles/patch
$ cd /u01/12.2/pairsfile/patch$ /bin/cp /u01/12.2/fs2/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1_patch.txt mypatchpairsfile.txt
3. Make necessary modifications to the pairsfile. Some of the inputs required for the Add Node API are automatically filled in. The sections that you need to fill in are the following:
   
   [Instance Specific] - This is instance specific information for the node you are going to add. Refer to the source context file for more information.
   
   [Services]

4.3.4 Configure the Patch File System on the Secondary Node

Carry out the instructions given below to configure the patch file system on the secondary node:

1. Ensure the correct perl utility is in the $PATH. You must use the perl utility installed in the Fusion Middleware Oracle Home.
   
   For example:
   
   $ export PATH=/u01/12.2/fs2/FMW_Home/webtier/perl/bin:$PATH
2. Ensure the WebLogic Administration Server from the patch file system is running on the primary application tier node.
   
3. Execute the Clone Context Utility to configure the patch file system. For example:
   $ cd /u01/12.2/fs2/EBSapps/comn/clone/bin
$ /u01/12.2/fs2/FMW_Home/webtier/perl/bin/perl ./adclonectx.pl \
addnode contextfile=/u01/12.2/fs2/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1.xml \
pairsfile=/u01/12.2/pairsfile/patch/mypatchpairsfile.txt \
outfile=/u01/12.2/fs2/inst/apps/VIS_appstier2/appl/admin/VIS_appstier2.xml
4. Review the EBSProvisioner.log file created in the current directory to ensure the add node program completed without any errors.
   
5. Shutdown any application tier processes that may have been started while configuring the patch file system.

DELTA 7 Code Level And Above

The AD/TXK D7 patch introduce a new flow that adds both the run and patch edition file system with a single command. The steps given below configures both Run and Patch edition file system for a new node that is going to be added to the farm.

1. Ensure the correct perl utility is in the $PATH. You must use the perl utility installed in the Fusion Middleware Oracle Home.

For example:

$ export PATH=/u01/12.2/fs1/FMW_Home/webtier/perl/bin:$PATH

2. Ensure the WebLogic Administration Server is running from both run and Patch file system on the primary application tier node.

3. A sample pairsfile for the run/patch file system is instantiated into the instance home on the primary application tier node. The file is called <SID>_<primary_node_name>_.txt, and located in the <inst_top>/appl/admin/ directory. For a configuration with an instance name of VIS, the pairsfile will be /u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1.txt.

4.Create the required directories and copy the pairsfile into a directory of your choice on the secondary application tier node. For example:

$ /bin/mkdir -p /u01/12.2/pairsfiles
$ cd /u01/12.2/pairsfile
$ /bin/cp /u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1.txt mypairsfile.txt

Make necessary modifications to the pairsfile. Some of the inputs required for the Add Node API are automatically filled in. The sections that you need to fill in are the following:

[Instance Specific] - This is instance specific information for the node you are going to add. Refer to the source context file for more information.

[Services]

5. Execute adclonectx utility to configure both run and Patch file system

$ cd /u01/12.2/fs1/EBSapps/comn/clone/bin
$ /u01/12.2/fs1/FMW_Home/webtier/perl/bin/perl ./adclonectx.pl \
addnode contextfile=/u01/12.2/fs1/inst/apps/VIS_appstier1/appl/admin/VIS_appstier1.xml \
pairsfile=/u01/12.2/pairsfile/mypairsfile.txt \
dualfs=yes

4. Review the log files displayed by the add node utility to ensure that the add node operation has gone through successfully.

4.3.5 Register the new Topology [Required]

Follow the instructions given in section 5.3.2.4-5.3.2.7 ( Register the new topology from the newly added application tier node) of My Oracle Support Note Knowledge document Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1) to register the new topology after adding the nodes.

4.3.6: SSH Connectivity Requirements for Online Patching (Required)

The 12.2 online patching tool adop requires ssh connectivity between the primary application tier node often called as the master node configured in the intranet with other application tier nodes configured in both the Intranet and in the DMZ. This connectivity is required for the remote invocation of the patching procedures on all the nodes. See Set up Secure Shell on Application tier Nodes in the Oracle E-Business Suite Maintenance Guide for more information.

Section 5: References

• Rapid Clone
  Rapid Clone automates and simplifies the process of cloning an Oracle E-Business Suite Release 12.2 system. For details, refer document 406982.1=""to Oracle E-Business Suite Setup Guide.
  
• AutoConfig
  AutoConfig is a tool to configure an Oracle E-Business Suite Release 12.2 instance. For details, refer to Oracle E-Business Suite Setup Guide.

• Oracle Fusion Middleware on Shared Storage : Best Practices

• Oracle E-Business Suite on Oracle Engineered Systems

Appendix A: Mount Options For Network File Systems

The recommendation given below are based on the testing performed by Oracle Development on commodity hardware running Linux operating system. The parameters listed below may not apply to Oracle Engineered systems. Please refer to Oracle E-Business Suite on Oracle Engineered Systems for more details on the mount options to be used.These parameters also may need to be tuned depending on various attributes related to network setup between the application tier machines , shared storage used, load on the storage server etc. Please contact your storage vendor to tune the NFS parameters for best throughput.

Platform	NFS Mount Options for Application Tier	NFS Mount Options for Database Oracle Home	NFS Mount Options for Database Files
Linux	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,nfsvers=3,tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536	For NFS V3 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=3,tcp For NFS V4 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=3,tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768
Solaris	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536	For NFS V3 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768
IBM AIX	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536	For NFS V3 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768
HP Itanium	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=65536,rsize=65536	For NFS V3 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,intr,bg,hard,timeo=600,wsize=32768,rsize=32768	For NFS V3 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768,vers=3,proto=tcp For NFS V4 rw,nointr,bg,hard,timeo=600,wsize=32768,rsize=32768

Please note that the nfs mount options " intr" and "nointr" mount options are deprecated with Oracle Linux re deprecated in Oracle Unbreakable Enterprise Linux and Oracle Linux kernels, 2.6.32 and later.

Additional Setup Requirements for NFS File Systems

• Updating the configuration Oracle HTTP Server configuration files for shared file systems
• Oracle JVM JIT mount option requirements for tmpfs file system
• Mount Options for Oracle files when used with NFS on NAS devices (Doc ID 359515.1)

Appendix B: Known Issues

Date	Known Issue	Resolution	Fixed In
November 11, 2013	Oracle E-Business Suite Domain creation fails on certain NFS storage with weblogic.security.SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag -Djava.security.debug=jpspolicy to get more information.	The workaround is to ensure that the storage is mounted with "noacl" NFS mount option.

Change Log

Date	Description
MAY 01, 2019	APR 2019 CPU Requirements added to the Add Node Section
MAY 21 , 2016	Updates for AD/TXK D7 and OCFS2 file system
FEB 23, 2015	NFS mount options for application tier file system updated ( removed nolock, intr changed to nointr , rsize and wsize changed to 65536) , Added additional shared storage requirements.
AUG 25, 2014	Removed acregmax,acregmin NFS parameters from the mount options for better peformance.
JUL 24, 2014	Note updated based on suggestions from remarks and bugs.
FEB 21, 2014	Note section updated to highlight shared file system variable need to be set to true
NOV 25, 2013	Updates in sections 4.3.1, 4.3.3, 4.3.4, and 4.3.5.
AUG 14, 2013	Edited in readiness for publication.
MAR 13, 2012	Initial document creation.

My Oracle Support Knowledge Document 1375769.1 by Oracle E-Business Suite Development
Copyright © 2016, Oracle

Oracle 18c - Complete Checklist for upgrading Oracle 12.x Container Database (CDB) to Oracle Database 18c (18.x) using DBUA (Doc ID 2421552.1)

In this Document

Purpose

Scope

Details

Database Upgrade Assistant (DBUA)

About Read-Only Oracle Homes

Upgrade Path / Compatibility Matrix for 18.x Oracle Database

Requirements and Recommendation for source database

Requirements and Recommendations for Target database

Prerequisites for Preparing Oracle Home on Windows

Pre Upgrade

Check for Invalid Objects / Components

Gathering Optimizer Statistics to Decrease Oracle Database Downtime

Verifying Materialized View Refreshes are Complete Before Upgrade

Check of TIMESTAMP WITH TIMEZONE Datatype

Ensuring That No Files Are in Backup Mode and no files need media recovery Before Upgrading

Purging Recycle Bin before upgrade

Databases That Use Oracle Label Security and Oracle Database Vault

Copying Transparent Encryption Oracle Wallets

Check the accounts use Case-Insensitive password version

About Password Case Sensitivity

Invoke DBUA

DBUA ( Step 1 of 10 )

DBUA ( Step 2 of 10 )

DBUA ( Step 3 of 10 )

DBUA ( Step 4 of 10 )

DBUA ( Step 5 of 10 )

DBUA ( Step 6 of 10 )

DBUA ( Step 7 of 10 )

DBUA ( Step 8 of 10 )

DBUA ( Step 9 of 10 )

DBUA ( Step 10 of 10 )

Post Upgrade

Known Issues

---

APPLIES TO:

Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.

PURPOSE

 The purpose of this article is to help DBA's / Support Teams to perform the upgrade of a database using DBUA to 18.x.

SCOPE

 DBA, Support

DETAILS

Database Upgrade Assistant (DBUA)

Database Upgrade Assistant (DBUA) provides a graphical user interface to guide you through the upgrade of Oracle Database.

DBUA works for CDB and non-CDB database systems. It is the recommended method for performing a major release upgrade or patchset release upgrade.
You can use DBUA to upgrade multitenant architecture container databases (CDB), pluggable databases (PDBs), and non-CDB databases.
The procedures are the same, but the choices you must make and the behavior of DBUA are different, depending on the type of upgrade.
DBUA automates the upgrade process by performing all of the tasks.
DBUA provides support for Oracle Real Application Clusters (Oracle RAC) databases. In an Oracle RAC environment,
DBUA upgrades all the database and configuration files on all nodes in the cluster.
DBUA, graphical user interface must be invoked within the new Oracle home where the Oracle Database 18c software has been installed.
For windows, Only an Administrator or Installed owner should invoke DBUA for Windows systems.
DBUA runs the Pre-Upgrade Information Tool as part of the prerequisite checks it performs before starting the upgrade.
However, to reduce downtime, Oracle recommends that you run the Pre-Upgrade Information Tool as part of your upgrade planning, so that you can analyze the database,
and take proactive steps before your planned upgrade date.
Once, you address / fix the pre-upgrade recommendation / warnings /errors and continue with the upgrade, DBUA shows the progress of the upgrade for each component of source database.
As with previous releases of DBUA, 18c DBUA restricts the carry over of hidden parameters since Oracle recommends not to have hidden parameters other than those suggested
via support during the upgrade.
To view existing hidden parameters execute the following command while connected AS SYSDBA:

SELECT name,description from SYS.V$PARAMETER WHERE name LIKE '\_%' ESCAPE '\';

DBUA performs some of the checks before actually starting the database upgrade. Some of the checks can be done manually to reduce downtime for the upgrade.
DBUA provides below options:
- Upgrade timezone. The default timezone vetrsion in 18.x is 26.
- Gather dictionary statistics before upgrade.
- Make user tablespaces read only.
- Take RMAN backup before upgrade.
- Create Restore Point for Database Flashback
- Restore database backup to rollback upgrade
- Option to execute Custom scripts before and after upgrade
- show the location of DBUA logs and Alert log files.
- Option to upgrade existing listener to 18.x home or create a new listener in 18.x target home.

About Read-Only Oracle Homes

Starting with Oracle Database 18c, you can configure an Oracle home in read-only mode.
In a read-only Oracle home, all the configuration data and log files reside outside of the read-only Oracle home. This feature allows you to use the read-only Oracle home as a software image that can be distributed across multiple servers.

Upgrade Path / Compatibility Matrix for 18.x Oracle Database

DBUA can upgrade only supported versions of direct upgrade.

Direct Upgrade to 18.x:

Source Database	Target Database
12.1.0.x (12.1.0.1 - 12.1.0.2)	18.x
12.2.0.1	18.x

  

Requirements and Recommendation for source database

- Ensure that all database components/objects provided by Oracle are VALID in the source database prior to starting the upgrade.
- Before you start an upgrade or downgrade process, Oracle strongly recommends that you update both your earlier release and your new release (18.x) Oracle Database to the latest Oracle bundle patch or patch set update (BP or PSU).
- Ensure that you do not have duplicate objects in the SYS and SYSTEM schema. For 1 and 2 refer to:
      Doc Id 556610.1 - Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
- dbupgdiag.sql script is a set of sql statements intended to provide a user friendly output to diagnose the status of the database either before (or) after upgrade. The script will create a output file called db_upg_diag_<sid>_<timestamp>.log
- IF APEX is installed then it is recommended to upgrade APEX in the source DB first before upgrading DB
- Timezone should less than or equal to target database timezone version.
- Make sure to have a valid backup of source database prior to upgrade.
- Disable any custom triggers that would get executed before / after DDL statements. Re-enable after the upgrade.
- Check the database server upgrade/downgrade compatibility matrix before upgrading the database.
- Set Archive Log ON during upgrade. Oracle recommends that you set Archive Log ON in order for DBUA to create and update the log file for the upgrade process.
- For Oracle RAC, if you upgrade a cluster database using DBUA, then you must leave the CLUSTER_DATABASE initialization parameter set to TRUE.
- Ensure to run the pre-upgrade utility prior to upgrading the database.
- Examine and follow the recommendation given in the preupgrade log file.
- Materialized views in source database should be stopped before upgrade
     Doc ID 1406586.1 - How to Handle Materialized Views When You Upgrade or Clone a Database
- Disable scheduled database custom jobs / cron jobs.
- Make sure you have COMPATIBLE parameter is set to 12.1.0 or greater

Requirements and Recommendations for Target database

- Verify whether your operating system / platform is certified for 18.x release.

- Download and Install Oracle 18c (18.x) in a new Oracle_Home and make sure there are no binary relinking errors.

- Download and Install the latest available RU or RUR from My Oracle Support (MOS).

- Make sure to set the ORACLE_HOME, PATH, LD_LIBRARY_PATH, LIBPATH etc. to 18.x target home.

- Review patch recommendations as given in the article "Patches to apply before upgrading Oracle GI and DB to 18c (Doc ID 2414935.1)"

- Apply patch 29213893 on target ORACLE_HOME to avoid ORA-01422 error - refer: Database Upgrade to 12.2, 18c, 19c fails with ORA-01422, ORA-06512 for SYS.DBMS_STATS (Doc ID 2525596.1)

Prerequisites for Preparing Oracle Home on Windows

Your system must meet these requirements before you can upgrade Oracle Database on Microsoft Windows platforms. For security reasons, different Microsoft Windows user accounts configured as Oracle
home users for different Oracle homes are not allowed to share the same Oracle Base.
- Database upgrade is supported when the same Windows user account is used as the Oracle home user in both the source and destination Oracle homes.
- Database upgrade is supported when the Oracle home from which the database is being upgraded uses the Windows Built-in Account. Releases earlier than Oracle Database 12c (release 11.2 and earlier) only supported the built-in account option for the Oracle home user on Windows.
- The Oracle home user may not have access to files outside its own Oracle Base and Oracle home. If that is the case, then if you choose a different Oracle Base during upgrade, it is possible that Oracle Database services cannot access files in the older Oracle Base. Using DBUA for database upgrade ensures that the Oracle home user has access to files outside of its own Oracle Base and its own Oracle home.

Pre Upgrade 

$Earlier_release_Oracle_home/jdk/bin/java -jar $New_release_Oracle_home/rdbms/admin/preupgrade.jar [FILE|TERMINAL] [TEXT|XML] [DIR output_dir]

FILE|TERMINAL - Use this option to direct script output to a file. Use TERMINAL to direct output to the terminal. If it is not specified then defaultr is FILE.
TEXT - Use this option to specify log should be in Text format. Use TEXT to specify text output. Use XML to specify XML output. If you do not specify an output type, then the default is text.
DIR - Logs will be created under <output_dir>. Directs the output to a specific directory. If you do not specify an output directory with the DIR option, then the output is directed to one of the default locations: If you define ORACLE_BASE environment variable then the generated scripts and log files will be created under $ORACLE_BASE/cfgtoollogs/<dbname>/preupgrade/ location else it will create under $ORACLE_HOME/cfgtoollogs/db_name/preupgrade/.

For example,
source Oracle Home : /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1
target Oracle Home : /refresh/home/oracle/ora_base/product/18.1

$ export ORACLE_SID=orcl
$ export ORACLE_BASE=/refresh/home/oracle/ora_base
$ export ORACLE_HOME=/refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1
$ $ORACLE_HOME/jdk/bin/java -jar /refresh/home/oracle/ora_base/product/18.1/rdbms/admin/preupgrade.jar FILE TEXT

==================
PREUPGRADE SUMMARY
==================
/refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade.log
/refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql
/refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/postupgrade_fixups.sql
Execute fixup scripts across the entire CDB:
Before upgrade:
1. Execute preupgrade fixups with the below command
$ORACLE_HOME/perl/bin/perl -I$ORACLE_HOME/perl/lib -I$ORACLE_HOME/rdbms/admin $ORACLE_HOME/rdbms/admin/catcon.pl -l /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/ -b preup_ORCL /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql
2. Review logs under /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/
After the upgrade:
1. Execute postupgrade fixups with the below command
$ORACLE_HOME/perl/bin/perl -I$ORACLE_HOME/perl/lib -I$ORACLE_HOME/rdbms/admin $ORACLE_HOME/rdbms/admin/catcon.pl -l /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/ -b postup_ORCL /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/postupgrade_fixups.sql
2. Review logs under /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/
 You may find the below scripts :

$ ls -l /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/
-rw-r--r-- 1 oracle oinstall 8237 Jul 10 05:37 postupgrade_fixups_CDB_ROOT.sql
-rw-r--r-- 1 oracle oinstall 8221 Jul 10 05:38 postupgrade_fixups_PDB1.sql
-rw-r--r-- 1 oracle oinstall 8221 Jul 10 05:38 postupgrade_fixups_PDB2.sql
-rw-r--r-- 1 oracle oinstall 8221 Jul 10 05:38 postupgrade_fixups_PDB3.sql
-rw-r--r-- 1 oracle oinstall 8237 Jul 10 05:37 postupgrade_fixups_PDB_SEED.sql
-rw-r--r-- 1 oracle oinstall 28440 Jul 10 05:39 postupgrade_fixups.sql
-rw-r--r-- 1 oracle oinstall 8778 Jul 10 05:37 preupgrade_fixups_CDB_ROOT.sql
-rw-r--r-- 1 oracle oinstall 8693 Jul 10 05:38 preupgrade_fixups_PDB1.sql
-rw-r--r-- 1 oracle oinstall 8693 Jul 10 05:38 preupgrade_fixups_PDB2.sql
-rw-r--r-- 1 oracle oinstall 8693 Jul 10 05:38 preupgrade_fixups_PDB3.sql
-rw-r--r-- 1 oracle oinstall 8709 Jul 10 05:37 preupgrade_fixups_PDB_SEED.sql
-rw-r--r-- 1 oracle oinstall 36645 Jul 10 05:39 preupgrade_fixups.sql

  
Examine the preupgrade.log file and follow the recommendation. Execute the preupgrade_fixups_<pdb_name>.sql against all or respective pluggable database

cd $ORACLE_HOME/rdbms/admin/
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b /tmp/preupgrade_fixups /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql
or
$ORACLE_HOME/perl/bin/perl catcon.pl -n 2 -e -b /tmp/preupgrade_fixups /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql

  
Above command will run the preupgrade_fixups.sql against all the pluggable databases.
To run the preupgrade_fixups.sql against individual pluggable database, below command can be used:

cd $ORACLE_HOME/rdbms/admin/
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'CDB$ROOT' -n 1 -e -b /tmp/preupgrade_fixups /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups_CDB_ROOT.sql
or
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'PDB1' -n 1 -e -b /tmp/preupgrade_fixups /refresh/home/oracle/ora_base/product/12.1.0.2/dbhome_1/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups_CDB_PDB1.sql

  

The latest preupgrade utility for 18.x can be found from :
How to Download and Run Oracle's Database Pre-Upgrade Utility (Doc ID 884522.1)

Check for Invalid Objects / Components 

set pagesize500
set linesize 100
select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;
select substr(object_name,1,40) object_name,substr(owner,1,15) owner,object_type from dba_objects where status='INVALID' order by owner,object_type;
select owner,object_type,count(*) from dba_objects where status='INVALID' group by owner,object_type order by owner,object_type ;

If you find invalid objects and/or database components then try to VALIDATE the invalid objects and/or database components by executing the following steps:

Run utlrp.sql to validate the invalid objects in the database. You can execute the utlrp.sql scripts multiple times to validate the invalid objects.

From 12.1 home,execute the utlrp.sql against the container and all the pluggable databases.

cd $ORACLE_HOME/rdbms/admin/
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql
$ sqlplus "/ as sysdba"
SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql

using -b utlrp, the log file utlrp0.log is generated as the script is run. The log file provides results of the recompile.

Gathering Optimizer Statistics to Decrease Oracle Database Downtime

Oracle strongly recommends that you use this procedure to gather statistics before performing Oracle Database upgrades.Oracle recommends that you use the DBMS_STATS.GATHER_DICTIONARY_STATS   procedure to gather these statistics. For example, enter the following SQL statement:     

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

Above command gather dictionary statistics for all PDBs in a container database.

you can use the below command to gather statistics against a particular PDB.

For PDB1 pluggable database :

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c 'PDB1' -b pdb1_gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

For CDB$ROOT container:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c 'CDB$ROOT' -b root_gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

  

Verifying Materialized View Refreshes are Complete Before Upgrade

  Use this procedure to query the system to determine if there are any materialized view refreshes still in progress. Before upgrading Oracle Database, you must wait until all materialized views have
completed refreshing.

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b mview_refresh -- --x"SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8"

  It will verify against all the pluggable databases or below query can be used:

SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;

How to Handle Materialized Views When You Upgrade or Clone a Database (Doc ID 1406586.1)

Check of TIMESTAMP WITH TIMEZONE Datatype

The time zone files that are supplied with Oracle Database 12c release 2 (18.x) is version 26.

Case 1 Timezone version of source database is lower or equal 26.

If the source database is using a timezone file lower than version 26 then there is no DST patch to apply in source oracle home or target 12cR2 home.

Case 2 Timezone version of source database is higher than 26.

If the source database uses a Timezone version higher than 26 then BEFORE the upgrade you MUST patch the target 12cR2 $ORACLE_HOME with a timezone data file of the SAME version as the one used in the source release database.

Ensuring That No Files Are in Backup Mode and no files need media recovery Before Upgrading

Execute below query to check for the status of the backup:
SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
Ensure that no files require media recovery:
SQL> SELECT * FROM v$recover_file;

Purging Recycle Bin before upgrade

Below command can be used to purge from all the pdbs:

 $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b purge_recyclebin -- --x"PURGE DBA_RECYCLEBIN"
or
 SQL> PURGE DBA_RECYCLEBIN;

we can purge the recycle bin via DBUA.

Databases That Use Oracle Label Security and Oracle Database Vault

Audit Table Preupgrade and Archive Requirements

For Oracle Database releases earlier than 12.1 using Oracle Label Security and Oracle Database Vault, you must run the OLS preprocess script before you upgrade.

If you are upgrading from a database earlier than Oracle Database release 12.1 that uses Oracle Label Security (OLS) and Oracle Database Vault, then you must first run the OLS preprocess script, olspreupgrade.sql, to process the aud$ table contents. The OLS upgrade moves the aud$ table from the SYSTEM schema to the SYS schema. The olspreupgrade.sql script is a preprocessing script required for this move.

Running the olspreupgrade.sql script before upgrading is mandatory for upgrading databases earlier than Oracle Database release 12.1 that use Oracle Label Security and Oracle Database Vault. Once you have upgraded to Oracle Database release 12.1, you do not have to perform the OLS preprocessing procedure going forward to patch or upgrade the database.

Granting the DV_PATCH_ADMIN Role to SYS for Oracle Database Vault

If Oracle Database Vault is enabled, then to perform checks for Oracle Data Vault, the upgrade process requires running three SQL scripts - olspreupgrade.sql, emremove.sql, catnoamd.sql

   Start SQL*Plus and connect as DVOWNER to the database that you want to upgrade.

    Run the following statement:

    SQL> GRANT DV_PATCH_ADMIN to SYS;

Copying Transparent Encryption Oracle Wallets

If you use Oracle wallet with Transparent Data Encryption (TDE), and you use Database Upgrade Assistant (DBUA) to upgrade the database, then copy the sqlnet.ora and wallet file to the new 18.x Oracle home.

You must copy the sqlnet.ora and the wallet file manually before starting the upgrade.
1. Log in as an authorized user.
2. Manually copy the sqlnet.ora file, and the wallet file, ewallet.p12, to the new release Oracle home.
3. Open the Oracle wallet in mount.

For example:
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN;

Check the accounts use Case-Insensitive password version

Log in to SQL*Plus as an administrative user, and enter the following SQL query
SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

If there are any 10g versions, suggest you to refer Oracle documentation to fix 10g versions, failing to do so, user accounts with LOCKED after upgrade is completed.

About Password Case Sensitivity

Ensure that you do not have the deprecated parameter SEC_CASE_SENSITIVE_LOGON set to FALSE.

Invoke DBUA

DBUA ( Step 1 of 10 )

Select the database to be upgrade , as there is only 1 database in example , it is auto selected -- ORCL 

 

DBUA ( Step 2 of 10 )

We can prioritize the upgrade of the pluggable database. in the given screen, the ORCL container database is having three pdbs : pdb1, pdb2, pdb3. The priority of pdb1 is set to 1 whereas for pdb2,pdb3 it is 2. Based on this selection DBUA will upgrade pdb1 first followed by pdb2, pdb3.

DBUA ( Step 3 of 10 )

Once the selection is done, DBUA will perform the pre-upgrade steps. It will execute the preupgrade scripts against all the pdbs and show errors / warnings. Choose "Show All Container" for the reported errors. If the errors are fixable than click on "Fix & Check Again". If there are any errors which can not be fixed by DBUA then manually fix and verify that there are no errors in the prerequisite checks page.

  

DBUA ( Step 4 of 10 )

Once the preupgrade warnings / errors has been addressed, In step 4, we can choose options like Enable Parallel upgrade, Recompile Invalid Objects in post-upgrade, Timezone upgrade for all the pdbs (The timezone version on 18.x is 26), Gather statistics for all the pdbs.

DBUA ( Step 5 of 10 )

In the given screen, there are recovery options available. you can choose to Create a Guaranteed Restore Point or RMAN backup in case of failure of upgrade.

DBUA ( Step 6 of 10 )

We can configure new listener or upgrade the existing "LISTENER_ORCL" listener which is running from 12.1.0.2 home to Target 18.x home.

DBUA ( Step 7 of 10 )

This screen is to configure EM express or register the upgraded database with EM Cloud control.

DBUA ( Step 8 of 10 )

DBUA will show the summary of what actions it will perform

 

DBUA ( Step 9 of 10 )

The DBUA will start the upgrade process of ORCL database. Once the upgrade starts, DBUA will first perform the upgrade of CDB$ROOT container. it will perform the pre-upgrade steps and then it will start upgrading Oracle Server,XML component followed by other components except Oracle APEX ( which is not upgraded as a part of Database Upgrade , you need to do it separately )

Once the upgrade completed for CDB$ROOT, database will be restarted and DBUA will perform the post upgrade steps like running catuppst.sql, configuring listener for 18.x home, recompile invalid objects and upgrading timezone,configuring EM Express.

Once the CDB$ROOT gets upgraded successfully, DBUA will use the priority list where the PDB1 will be upgraded first. The PDB1 priority is set to 1.So based on the priority, DBUA will consider priority list "P1" for pluggable database PDB$SEED and PDB1 to be upgraded first. In below screen, DBUA will parallely perform the upgrade for PDB$SEED and PDB1. It will perform the upgrade of components viz Oracle Server, XDB, Workspace Manager component for both PDB$SEED, PDB1 pdbs.

Note that the CDB$ROOT and PDB$SEED has highest priority.

 

After completing the upgrade of PDB$SEED and PDB1, DBUA will start the post upgrade process for "P1" priority list for PDB$SEED and PDB1 pdbs. DBUA will bounce back both the pdbs PDB$SEED and PDB1 for post upgrade steps.

 

Once the upgrade of P1 list gets completed, DBUA will start the upgrade of P2 priority list which contains PDB2 and PDB3. In the below screen we can see that the PDB2 and PDB3 pdbs are getting upgraded parallely.Followed by the post upgrade steps for both the PDB's respectively.

 

DBUA ( Step 10 of 10 )

The final screen will show the result of the container database upgraded to 18.x. It will show the list of pluggable databases upgraded. It will show the detailed summary for the time taken by DBUA to complete the upgrade of individual PDBs

 

It will show the timezone upgrade details for CDB$ROOT and all the pluggable databases.

 

Post Upgrade

Execute dbupgdiag.sql script against the CDB$ROOT container and all the pluggable databases PDB1, PDB2, PDB3 to verify the status of objects and components . If there are invalid objects then run utlrp.sql to recompile the invalid objects as follows:

cd $ORACLE_HOME/rdbms/admin/
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql                  ===> To run the utlrp.sql against all the PDBs.
or
$ORACLE_HOME/perl/bin/perl catcon.pl -l /tmp -n 2 -e -b utlrp -c 'PDB1' utlrp.sql         ===> To recompile invalid objects for PDB1 pluggable database.

sql> connect / as sysdba
sql> @?/rdbms/admin/utlrp.sql

Known Issues