0% found this document useful (0 votes)

52 views101 pages

Practical Oracle E-Business Suite - An Implementation and Management Guide (PDFDrive) - Compressed-178-278

The document discusses the file system architecture in Oracle E-Business Suite 12.2. It introduces the dual file system architecture using directories fs1 and fs2 to support online patching. It also describes the nonedition file system fs_ne that stores files not changed during patching. Key directories like EBSapps, inst, and FMW_Home are located within these file systems.

Uploaded by

devang

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

52 views101 pages

Practical Oracle E-Business Suite - An Implementation and Management Guide (PDFDrive) - Compressed-178-278

Uploaded by

devang

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 101

CHAPTER 4

Oracle E-Business Suite 12.2

File System

The file system in EBS 12.2 is a crucial topic, so it is impossible not to mention it in this book. In earlier
chapters, we introduced the file system structure of EBS 12.2, as well as the EBS environment variables,
which are tightly related with the file system directories used in EBS 12.2. This chapter is dedicated to the
file system; having a deeper understanding of the file system will give you a better understanding of all the
technology components of EBS 12.2.
Specifically, we will explain the application file system, including the Fusion Middleware directory
structure (in addition, we will be focusing on FMW in EBS 12.2 in Chapter 7). We will also cover the
environment variables used in EBS 12.2 and give you the directory navigations and log file locations.
We’ll start by defining the important environment variables used in EBS 12.2 so you know which
directory to use for specific file system operations.

Oracle E-Business Suite File System Architecture Overview

The EBS file system architecture4 is based on an application file system and a database file system, as
mentioned in Chapter 1. The database file system is delivered as a standard Oracle Home, with a directory
named appsutil residing it. The data files, control files, redo log files, and the parameter file that contributes
Oracle Database can be placed anywhere in the database file system as well as in the ASM file system.
In the RAC installations, there is also a Grid Home in the database tier that gets delivered with the EBS
installation. The Grid Home can be considered part of the database file system, as it supplies the clustering
and it hosts other critical utilities such as listeners and ASM. So, EBS’s database file system is a typical Oracle
Database file system that any core DBA can understand and manage (with the exception of the application-
related database management activities such as using AD utilities in the database tier).
The EBS application file system architecture, on the other hand, has become a bit more complex with
the 12.2 release. A dual file system and the noneditioned file system were introduced with this release, and
there are also new technologies such as Fusion Middleware delivered with the standard installation.
Moreover, online patching was introduced in this release, and also some of the application tier
technologies such as 10.1.3 Oracle Home have been retired.
As a result of these changes, EBS 12.2 has become more powerful than its ancestors, but its file system
architecture, especially for the application tier, has become complex.

© Syed Zaheer and Erman Arslan 2016 155

S. Zaheer and E. Arslan, Practical Oracle E-Business Suite, DOI 10.1007/978-1-4842-1422-0_4
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

With Release 12.2, there are two file systems, named fs1 and fs2, representing the dual file system
architecture. The dual file system is used for supporting online patching, as only one of these file systems
can be active (run) at a certain time. The patching activities are done in the inactive file system, which can
also be called the patch file system because it provides the ability to patch the EBS system online without
disturbing the applications in use.
For supporting online patching properly, EBS houses two identical file systems, synchronized using the
new online patching tools in its application tier. These file systems host most of the EBS files including the
directories. These directories include the directory hosting Fusion Middleware, APPL_TOP, COMMON_TOP,
and INST_TOP.
That means there are two application file systems, two sets of binaries, and two editions (the run and
patch) but one EBS database. So, the binaries that reside on these two application file systems connect to the
same EBS database but see the database objects differently according to their roles at a certain time.
That is, there is an isolation mechanism in the EBS database that makes binaries that reside in the
active (run) file system use the runtime database objects and makes the binaries that reside in the patch
file system use the copies of the runtime database object without interrupting the database work that active
applications do. This database-level isolation mechanism is the edition-based redefinition (EBR) feature
that comes with the Oracle Database 11g R2 and 12c. EBR is in the EBS database, so it is not part of the
database file system, but it is tightly integrated with the application tier, so we will explain it while we are
explaining the file system architecture in EBS 12.2.
There is also a non-edition file system called fs_ne to store the non-editioned objects such as the
concurrent request log and out files as well as the adop log files, which are not changed according to the
active (run) file system being fs1 or fs2.
Figure 4-1 represents the synchronized file system architecture that is used in the EBS application
tier, as well as the usage of EBR for database-level isolation for supporting the online patching in the
database tier.

156
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Figure 4-1. EBS file system architecture

Understanding the Application Dual and Noneditioned

File Systems
The file system architecture in the EBS application tier is based on the dual and nonedition file systems. It
is a completely new file system architecture compared to EBS 12.1, 12.0, and 11i, and it is also a unique file
system architecture design compared to the file system design of any other Oracle product.
While the concepts of the dual file system and nonedition file system are new, calling the file systems
that constitute the dual file system architecture the run and patch file systems according to their roles at a
certain time is exciting. Also, the noneditioned file system, which gets its name from not being required to be
synchronized, is also part of the file system design.

■ Note The run file system is used by the Oracle applications in runtime. The patch file system is a copy of
the run file system and is there to support online patching. The noneditioned file system is a file system that
stores the files needed by both the run and patch file systems but is not patched during the online patching
cycles; thus, it does not need to be synchronized.

157
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

The directory name of the nonedition file system is fs_ne, and the directory names of the run and patch
file systems are fs1 and fs2.
fs1 and fs2 are the directories that constitute the dual file system in EBS, and their roles change when a
patch cycle is completed (actually when an adop cutover operation is triggered). In other words, at any one
time fs1 can be the patch edition and fs2 can be the run edition, but if you apply a patch and complete the
online patching cycle for it, you’ll see that fs2 becomes the patch and fs1 becomes the run edition. So, the
roles of fs1 and fs2 may change, and this interchanging of roles is part of the design to support the online
patching mechanism introduced in EBS 12.2.
Figure 4-2 shows the dual file system architecture used in EBS 12.2, as well as the main top directories
named EBSapps, inst, and FMW_Home that reside in both of the file systems.

Figure 4-2. EBS dual file system architecture

So, all the application files and directories that constitute the application file system architecture of
EBS 12.2 are located in the subdirectories of these three directories (run file system, patch file system, and
noneditioned file system), as shown in Figure 4-2.
These three top-level directories, however, are also located in a directory called the base directory,
which you define by specifying the application base directory (the Apps Base Dir box) during the installation
or cloning of EBS 12.2.
Figure 4-2 also shows the usage and output of the EBSapps.env script used to set the runtime
environment. From the output of the EBSapps.env script provided in the bottom-right corner of Figure 4-2,
you can see the current run, patch, and the noneditioned file system directories as well as the database SID
of the environment.

158
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

So, as shown with the example tree command output in Listing 4-1, the base directory /u01/install/APPS
consists of three directories: fs1, fs2, and fs_ne. It also consists of an environment file named EBSapps.
env, which can be used to source the run or patch environment files easily. As we explained earlier, fs1 and
fs2 may change roles, and that’s why there cannot be a fixed environment file to source the run and patch
environments.
However, EBSapps.env is intelligent; thus, you can set your environment using it. You can use EBSapps.
env to set your environment to the run edition for administrating the running EBS services; likewise, you can
set your environment to be the patch environment for doing some patching activities.
Listing 4-1 shows a tree command and its output that lists the base directory and its main subdirectories.

■ Note tree is a tool for Linux OS that lists the contents of directories in a tree-like structure. It is widely used
in this chapter to display the directory structures in a simple tree format.

Listing 4-1. tree Command Output Representing the base directory

tree /u01/install/APPS -L 1 --charset=ANSII -l

APPS
|-- EBSapps.env
|-- fs1
|-- fs2
|-- fs_ne

Inside the fs1 and fs2 folders, you see the same directory structures because they are copies of each
other. There are three top-level directories in fs1 and fs2.
EBSapps is the key directory for Oracle EBS applications, and it stores three main directories: appl,
10.1.2, and comn. The famous $APPL_TOP environment variable points to the directory named appl in
EBSapps, as this directory stores the EBS product files in its subdirectories named with the product short
names. The files that belong to the custom applications that are defined for enabling the customizations
inside EBS are also stored in the subdirectories located in the directory named appl. There are also
environment variables for defining for these custom directories; it is a rule of thumb to name these
environment variables and directories with XX (for stating that it is a custom directory) followed by the EBS
style of three-letter short names for the companies. For a company named EXAMPLE, the names for the
environment variable and the corresponding custom directory would be XXEXP_TOP and xxexp.

■ Note Adding custom applications will be explained in Chapter 8.

The comn directory pointed at by the $COMMON_TOP environment variable stores the files used
by several different Oracle E-Business Suite products and third-party products. The 10.1.2 directory also
known as Oracle Application Server 10.1.2 Oracle Home is pointed at by the $ORACLE_HOME environment
variable, and as the name implies, it stores the Oracle Home files that are there for executing processes such
as frmweb, which plays a part in enabling forms services for the clients.
FMW_Home is the base directory for Fusion Middleware that is present in EBS 12.2. It stores the files
that constitute the WebLogic domain, WebLogic Server, and Oracle HTTP Server used in EBS 12.2.
The inst directory pointed at by the $INST_TOP environment variable is called Instance Home. Oracle
Application Server 10.1.2 ORACLE_HOME configuration files, the application’s context file pointed at by the
$CONTEXT_FILE, application control script pointed at by $ADMIN_SCRIPTS_HOME, and log files such as
AutoConfig log files are stored in this directory.

159
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Listing 4-2 shows an example tree command and its output displaying the directory structures of fs1
and fs2. Notice that fs1 and fs2 have the same subdirectory structures because they are copies of each other.

Listing 4-2. tree Command Output Representing the Contents of fs1 and fs2 Directories
tree fs1/ fs2/ -d -L 1 --charset=ANSII

Of course, the fs_ne directory pointed at by the $NE_BASE environment variable has a different set of
subdirectories than fs1 and fs2, as the fs_ne is the noneditioned file system. There are two main directories
under the fs_ne directory: EBSapps and inst. In the EBSapps directory, there are three subdirectories named
appl, log, and patch.
In the appl directory, there are two important wrapper scripts named adop and adopreports for
executing the adop utility (the patching tool) and the adop reports (the AD reporting tool). adop_sync.drv,
the custom synchronization driver that is called during the prepare phase of adop is also located here. This
driver file is used by adop for syncing the custom apps objects across the editioned file systems (fs1 and fs2).

160
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

■ Note We will explain the usage of adop_sync.drv in detail while we are explaining the customizations in
Chapter 9.

Some code signing/JAR signing–related files such as adkeystore.dat and appltop.cer are also located in
this directory.
The log directory stores the log and output files used by the patch-related AD utilities. This includes the
log files produced by the adop utility, the log and output files of the adadmin utility, and the log files of AD
workers (which are used by adop while patching). In addition, the status outputs of adop status commands
are stored in this directory.
The directory named patch stores the zip files and the unzipped states of these files, as this directory
can be reached by the cd $APPL_TOP_NE/../patch command; it is the default directory where you as an
apps DBA uploads and unzips patches to be applied and also where adop, when executed, looks for the
patches to be applied. The inst directory is the location where concurrent request logs and output files are
stored. The log files of concurrent managers and the workflow notification mailer’s log, both inbound and
inbound threads, are also stored in this directory.
If you need a little more detail, the log files are stored in inst/<SID>_<hostname>/logs/appl/conc/log,
and the outputs are located in the inst/<SID>_<hostname>/logs/appl/conc/out directory.
Listing 4-3 shows the fs_ne directory and its contents.

Listing 4-3. tree Command Output Representing the Contents of fs_ne

We already explained these directories and the type of files stored in them, as well as the purposes of
these directories. Now we will give you some details about them. In this context, the 10.1.2 directory in the
EBSapps directory is the 10.1.2 Oracle Home, and the subdirectories of this directories are the same as you
can find almost in any 10.1.2 Oracle Home.
The appl and comn subdirectories of the EBSapps directory are EBS-specific directories, as mentioned
earlier, and by just looking at the subdirectories residing in them, you can probably understand their
purposes. As shown in the tree command output, in the appl directory you have all the EBS product
directories, and in the comn directory you have directories such as utils and shared_libs that are there to be
used by the application stack.
The FMW_Home directory delivers the Fusion Middleware technology, with its subdirectories that
contain the EBS domain, web tier, and WebLogic-related utilities. So, FMW_Home delivers the Fusion
Middleware that comes bundled with EBS 12.2 and has the classic FMW directory structure inside of it.
Lastly, the inst directory is another EBS-specific directory, which was introduced with EBS R12. The inst
directory, as explained earlier, stores some of the configuration files, the context file, and application service
control scripts.
When you take a deeper look at one of the dual file system directories with the tree command, which
produces more detailed output (as shown in Listing 4-4), you see that there are also several directories under
the main subdirectories; they are named EBSapps, appl, comn, FMW_Home, and inst.
Listing 4-4 shows the output of a tree command that is used for listing the subdirectories of the fs1 file
system; this is what the directory structure of the EBS dual file system looks like.

161
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Listing 4-4. Directory Structure for Representing the Subdirectories of fs1

fs1/
|-- EBSapps
| |-- 10.1.2
| | |-- Apache
| | |- appsutil
| | |-- bin
| | |-- j2ee
| | |-- javacache
| | |-- javavm
| | |-- network
| | |-- OPatch
| | |-- opmn
| | |-- sqlplus
| | |-- ....
| | |-- .......
| | |-- ..........

| |-- appl
| | |-- ad
| | |-- admin
| | |-- ap
| | |-- ar
| | |-- as
| | |-- asp
| | |-- ast
| | |-- au
| | |-- fnd
| | |-- gl
| | |-- ....
| | |-- .......
| | |-- ..........

162
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

As shown in the tree command output, many directories are present in the EBS 12.2 application file
system architecture. In fact, there are more directories than displayed in the previous tree command output,
as the tree command output used for producing the previous output shows the directory level with only a
depth of 3.
Nevertheless, you don’t need to memorize all these directories, their full paths, and their usages. You
don’t even need to cd to most of these directories during your daily administration work. The only thing
you need to know is the environment variables that are set when the EBS environment file (in other words,
EBSapps.env) is sourced.
The database tier has a simpler file system architecture that core DBAs are already familiar with, as
shown in Listing 4-5.
In Listing 4-5, you see a tree command and its output, which displays the database tier base directory
with all of its main subdirectories. The output in Listing 4-5 is a bit consolidated, and some of the directories
that reside in Oracle Home have been extracted, as these directories are not special for EBS 12.2 and can be
found in any Oracle Database installation. Also in Listing 4-5, we focus on EBS-specific database directories
and describe critical directories near their directory names.

Listing 4-5. tree Command Output Representing the Contents of Database File System
[oracle@somehost /u01]$ cd install
[oracle@somehost install]$ tree -A -L 4 oraInventory PROD

163
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

| |-- appsutil : appsutil directory that accommodate the application utilities

164
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

165
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

As shown in the directory tree represented in Listing 4-5, there are two main directories named
oraInventory and PROD that reside in the main installation directory (in this example /u01/install) in the
database tier.
If you take a look at the directory structure represented in Listing 4-5 more specifically, you see that
the database tier consists of an Oracle Home (PROD/11.2.0) directory for supplying the Oracle RDBMS
software, an inventory (oraInventory) directory for storing the inventory information of the EBS database,
and database files (PROD/data) that contribute Oracle Database.
Inside these directories, you have lots of subdirectories such as TNS configuration files, control scripts,
and database files, which will be known, used, and managed by you.
It is important to know that the paths for the main directories can be specified during the installation of
EBS 12.2, so the directory names may differ according to the installation. Also, if you use ASM to store your
database files, then naturally the database files are placed in the ASM disk groups rather than traditional
operating system directories. So, if ASM is used for storing the database files, you can’t see the database file
on your traditional file systems. And if that’s the case, then you can only see the database files by using the
asmcmd command or by querying the respective v$ views, which can be used to get information from the
ASM file system.
Lastly, it is important to mention that most of the EBS configuration files such as TNS files or
environment file can be re-created using the AutoConfig utility, which is explained in Chapter 8.
The appsutil directory can also be re-created in the application tier using the admkappsutil.pl script
and then can be transferred to the database tier, as explained in Chapter 3.
As explained earlier, EBS has a complex directory structure consisting of several subdirectories. It is
complex because it has several subdirectories, and you use the files and scripts stored in these subdirectories
in your daily administration works. It is hard to memorize these directory paths, and it is also not necessary
to memorize them, as they may change according to the EBS installations. Thanks to Oracle, you have
environment variables that point to the relevant directories and that save you from memorizing the whole
directory structure of EBS 12.2 with all the subdirectories.
That is, using EBS environment variables, it is much easier to navigate to both the application and
database file systems, as you can directly cd to the directories using the environment files or open a file such
as the context file using the environment variable called $CONTEXT_FILE, rather than dealing with long
directory paths and trying to find where the directory or file that you need to work with is located.
Let’s now take a look at these environment variables, see how to set them, and get to know the most
important environment variables that you will use in your daily administration work.

Oracle EBS 12.2 Environment Variables

As mentioned while explaining the directory structures previously in this chapter, there are environment
variables both in the application tier and in the database tier, and they are defined to make your job easier
while dealing with the file system directories and files.
These environment variables are set by apps DBAs using the relevant scripts that come with the
EBS installations. You usually execute or source these environment scripts just after logging in to the
environment with the relevant application or database OS user. Alternatively, you sometimes add these
scripts to the bash files that are sourced automatically by the operating system during every login operation.
The advantage of using these bash files for automatic execution or sourcing these scripts and files is that
it also automates the settings needed for the environment variables; thus, you can log in to the operating
system and start using an environment variable without a need to source or execute any environment scripts
or files. Using such an automated environment setting method eases your job as an apps DBA because it
saves you from executing a script to set the relevant environment in every login.
So, let’s start with the application tier by getting the know the script that sets the environment variables,
the descriptions of most important environment variables themselves, and the automated method for
setting these environment variables in every login.

166
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

In the application tier, the environment variables are set using the EBSapps.env file, which resides in the
base directory at the same directory level as fs1, fs2, and fs_ne, as shown in Listing 4-6.

Listing 4-6. tree Command Output Displaying the EBSapps.env Script, Which Is Located Under the base directory
|-/u01/install/APPS/ (The base directory)
|------ EBSapps.env (Script that is used for setting application Tier environment variables)
|------ fs1
|------ fs2
|------ fs_ne

We already explained the EBSapps.env file in previous chapters, but we will give an example of its usage
because it is the main file that sets the application environment in EBS 12.2.
To set all the application tier environment variables at once, the EBSapps.env file can be executed,
and it must be executed with an argument. The argument can be patch or run. That is, if you source the
environment file with the command . EBSapps.env run, it sets the run environment. Alternatively, if you
execute it with the command . EBSapps.env patch, it sets the patch environment.
The patch environment should be set in cases when you as the apps DBA wants to operate on the patch
file system. In other words, when the patch environment is set, the environment variables are defined to
point to the directories or files that reside in the patch file system. So, if you use the APPL_TOP environment
variable to cd to the directory that stores the EBS product files, then you will find yourself in the EBSapps/
appl directory that resides in the patch file system environment. Similarly, if you use the CONTEXT_FILE
environment variable to reach the context file of the environment, you will reach the context file that resides
in the patch file system. Moreover, if you use sqlplus command to connect to the database, you will find
yourself in the patch edition of the EBS database.
Listing 4-7 shows the values of the APPL_TOP, CONTEXT_FILE, and TWO_TASK environment variables
as well as the TNS entry that is defined for the patch edition after setting the patch environment using the
EBSapps.env script.
Also in Listing 4-7, you can see that if you use sqlplus, it directly tries to connect to the patch edition in
the EBS database; however, it can’t connect to the database because there is no patch edition because the
system in Listing 4-7 is not in a patching cycle (adop patching cycle).
The way to make sqlplus connect to the patch edition is using the TWO_TASK environment variable,
which is the default environment variable used by the sqlplus utility to retrieve the database connection
information. When TWO_TASK is set to the TNS alias that points to the patch edition service name defined
in tnsnames.ora, sqlplus will try to connect to the patch edition of the EBS database.
That is, as the patch environment sets TWO_TASK to be the TNS alias defined for the patch edition
of the database, sqlplus tries to connect to the database patch edition if it is invoked without specifying a
connect identifier. This behavior of sqlplus should not be your focus, but it clearly shows the effect of setting
the patch environment, as shown in Listing 4-7.

Listing 4-7. The environment Variables, the TNS Entry for the Patch Edition and the behavior of sqlplus
when the patch environment is set
[applmgr@somehost ~]$ . /u01/install/APPS/EBSapps.env patch

E-Business Suite Environment Information

----------------------------------------
RUN File System : /u01/install/APPS/fs1/EBSapps/appl
PATCH File System : /u01/install/APPS/fs2/EBSapps/appl
Non-Editioned File System : /u01/install/APPS/fs_ne

DB Host: somehost.somedomain Service/SID: TEST

167
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Sourcing the PATCH File System ..

[applmgr@somehost ~]$ echo $APPL_TOP

/u01/install/APPS/fs2/EBSapps/appl

[applmgr@somehost ~]$ echo $CONTEXT_FILE

/u01/install/APPS/fs2/inst/apps/TEST_somehost/appl/admin/TEST_somehost.xml

[applmgr@somehost ~]$ echo $TWO_TASK

TEST_patch

Contents of tnnames.ora stating the TEST_patch(TWO_TASK) TNS entry:

TEST_patch=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.somedomain.)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=ebs_patch)
(INSTANCE_NAME=TEST)
)
)

[applmgr@somehost ~]$ sqlplus apps/apps

sqlplus: Release 10.1.0.5.0 - Production on Sat Aug 22 16:15:05 2015

Copyright (c) 1982, 2005, Oracle. All rights reserved.

ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-20099: E-Business Suite Patch Edition does not exist.
ORA-06512: at line 29

Setting the patch environment is needed only in rare cases. Investigating a patch failure or
implementing a DMZ configuration are some examples where you would set the patch environment, but
normally you won’t use the patch environment often.
So, you normally do your administration work using the run environment, which can be set by sourcing
EBSapps.env with the run argument, as mentioned earlier.
Listing 4-8 shows how to set the run file system using EBSapps.env, as well as the values of the
environment variables and behavior of sqlplus after setting the run environment.

Listing 4-8. The environment Variables, the TNS Entry for the Run Edition and the behavior of sqlplus when
the run environment is set
[applmgr@somehost APPS]$ . EBSapps.env run

E-Business Suite Environment Information

DB Host: somehost.somedomain Service/SID: TEST

168
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Sourcing the RUN File System ...

[applmgr@somehost APPS]$ echo $APPL_TOP

/u01/install/APPS/fs1/EBSapps/appl
[applmgr@somehost APPS]$ echo $CONTEXT_FILE
/u01/install/APPS/fs1/inst/apps/TEST_somehost/appl/admin/TEST_somehost.xml
[applmgr@somehost APPS]$ echo $TWO_TASK
TEST

Contents of tnsnames.ora stating the TEST(TWO_TASK) TNS entry:

TEST=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.somedomain(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=TEST)
(INSTANCE_NAME=TEST)
)
)
[applmgr@somehost APPS]$ sqlplus apps/apps
SQL>

As shown, the directory and file paths for the environment variables shown in Listing 4-2 and Listing 4-1
differ from each other. That is, as the patch edition is in fs2 and the run edition is in fs1, you see the directory
pointed at by APPL_TOP and the file pointed at by the CONTEXT_FILE environment variables are different
from each other. Also, you see a similar difference in TWO_TASK that points to the default TNS entry used by
sqlplus to get the connection information for the EBS database.
Moreover, you see a failure in the sqlplus output as shown in Listing 4-7, as it tries to connect to the
patch edition that does not even exist, and you see a successful sqlplus connection in Listing 4-8, as TWO_
TASK is set to the service that is defined for connecting to the current/run edition of the database.
So, we have explained how to set the environment variables in the EBS 12.2 application tier, and we
have shown the difference between the run and patch edition environments by providing you with the
values of some of the environment variables and by showing the situation in sqlplus connections after
setting each of these environments.
Let’s now take a closer look at the environment variables used in the EBS 12.2 application tier and
get to know their values and descriptions. As every standard product has its own directory named with its
short name and pointed at by an environment variable in the form of SHORTNAME_TOP and also as there
are several technologies and tools used in EBS 12.2, there are several environment variables used in EBS
application tier.
Fortunately, it is not required that you know every single environment variable and the cases where
they may be needed; usually apps DBAs do not need to use most of them.
But know that you can use the env command at any time to the display the environment variables that
are set by executing the EBSapps.env file, just to satisfy your curiosity. Listing 4-9 shows a truncated env
command output that shows a bunch of environment variables set by the EBSapps.env script.

Listing 4-9. env Command Output That Shows Application Tier Environment Variables
[applmgr@somehost APPSDEVEL]$ env|more
PRP_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/prp/12.0.0
OA_DOC=/u01/install/APPSDEVEL/fs2/EBSapps/comn/doc
PJI_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/pji/12.0.0
IGC_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/igc/12.0.0

169
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

FPA_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/fpa/12.0.0
EGO_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/ego/12.0.0
ASG_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/asg/12.0.0
APPL_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl
AFJSMARG=-server -Xmx384m -Doracle.apps.fnd.common.Pool.leak.mode=stderr:off -verbose:gc
APPLLIB=lib
IRC_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/irc/12.0.0
ANT_CONTRIB=/u01/install/APPSDEVEL/fs2/FMW_Home/modules/net.sf.antcontrib_1.1.0.0_1-0b2
APPLSQL=sql
INV_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/inv/12.0.0
IEC_TOP=/u01/install/APPSDEVEL/fs2/EBSapps/appl/iec/12.0.0
....
.......
......... list continues...

Although we already mentioned that apps DBAs should not memorize every single environment
variable in EBS 12.2 as most of the environment variables are not used during the administration work, this
does not mean that most of the environment variables in EBS 12.2 are not critical.
In fact, most of these environment variables are used internally by EBS applications for actions such
as setting their class paths or realizing the places where their binaries reside. That’s why if an application or
technology component cannot use an environment variable that it needs to use, then it may not behave well
and will probably crash.
In addition, there are some environment variables that every apps DBA should know by heart. You can
cd to the directories they point at and use the files residing in the directories they point at when needed
during your daily administration work. Some of these environment variables, such as the CONTEXT_FILE
environment file, point directly to the files rather than that directories, and also some of them such as FILE_
EDITION can be used only for getting information about the environment.
Also, it is important to remind you that these environment variables are set automatically when you
execute the EBSapps.env script. So, the directories or files that are pointed at by the environment variables
can differ according to the environment being patched or run. That is, if the EBSapps.env script is executed
with the run argument, it sets the run edition, and if the EBSapps.env script is executed with the patch
argument, it sets the patch edition. So, naturally the environment variables are set accordingly.
The most important environment variables that an apps DBA will use during daily administration
work are listed in Table 4-1. Table 4-1 summarizes the environment variables for both the run edition and
the patch edition, provides the associated directories, and describes the environment variables. Note that
the term <base> in Table 4-1 is used for describing the base directory that is specified by installing EBS 12.2
using the Rapidwiz Install Wizard. So, it is the root directory for EBS, where all the other directories reside.

170
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Table 4-1. Environment Variables, Directories, and Descriptions

Environment Variable Directory/File/Value Description

RUN_BASE <base>/fs1 or <base>/fs2 (it can point Base directory of the run edition file
to fs1 or fs2, according to the fact that it system.
points to the current run file system)
PATCH_BASE <base>/fs1 or <base>/fs2 (it can point Base directory of the patch edition file
to fs1 or fs2, according to the fact that it system.
points to the current patch file system)
CONTEXT_NAME Example: TEST_somehost Context name of the environment in
the form of <SID>_<hostname>.
NE_BASE <base>/fs_ne Base directory of the noneditioned file
system (fs_ne).
APPL_TOP Run edition: Directory that stores the EBS product
$RUN_BASE/EBSapps/appl files. Product directories pointed at
Patch edition: by the PRODUCT_TOP environment
$PATCH_BASE/EBSapps/appl variables are also located in this
directory.
APPL_TOP_NE $NE_BASE/EBSapps/appl Noneditioned APPL_TOP directory.
COMMON_TOP Run edition: Directory that stores their common
$RUN_BASE/EBSapps/comn libraries.
Patch edition:
$PATCH_BASE/EBSapps/comn
INST_TOP Run edition: Directory that stores the configuration
$RUN_BASE/ inst/apps/$CONTEXT_NAME files and also files like application
Patch edition: service control scripts.
$PATCH_BASE/inst/apps/$CONTEXT_
NAME
ORACLE_HOME Run edition: 10.1.2 Oracle Home directory.
$RUN_BASE/EBSapps/10.1.2
Patch edition:
$PATCH_BASE/EBSapps/10.1.2
FMW_HOME Run edition: Fusion Middleware Home directory.
$RUN_BASE/EBSapps/FMW_Home
Patch edition:
$PATCH_BASE/EBSapps/FMW_Home
JAVA_TOP $COMMON_TOP/java/classes Resides in the directory pointed at by
COMMON_TOP and stores the Java
classes used by the applications.
EBS_DOMAIN_HOME $FMW_HOME/ FMW_Home/user_ Directory that stores the EBS WebLogic
projects/domains/EBS_domain_<SID> domain.
ADMIN_SCRIPTS_ $INST_TOP/apps/$CONTEXT_NAME/ Directory that stores the application
HOME admin/scripts service control scripts.
FND_TOP $APPL_TOP/fnd/12.0.0 Foundation top directory.
AD_TOP $APPL_TOP/ad/12.0.0 Applications DBA directory.

(continued)

171
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Table 4-1. (continued)

Environment Variable Directory/File/Value Description
CUSTOM_TOPS $APPL_TOP/<custom_module_short_ Custom products directories.
Ex: XXABC_TOP name>12.0.0
CONTEXT_FILE $INST_TOP/ apps/$CONTEXT_NAME/ Application context file.
appl/admin/$CONTEXT_NAME.xml
PRODUCT_TOPS $APPL_TOP/<standard_module_short_ Standard EBS product directories.
Ex: PO_TOP name/12.0.0
Example: $APPL_TOP/po/12.0.0
LOG_HOME $INST_TOP/apps/$CONTEXT_NAME/logs Directory that stores application
service control script log files, as well
as 10.1.2 Oracle Home–related forms
log files.
ADOP_LOG_HOME $NE_BASE/EBSapps/log/adop Directory that stores the log file of the
adop utility.
IAS_ORACLE_HOME $FMW_HOME/webtier FMW web tier Home directory.
FORMS_TRACE_DIR $INST_TOP/ apps/$CONTEXT_NAME/ Directory that stores the forms traces
logs/ora/10.1.2/forms produced when forms runtime
diagnostics is enabled.
APPLCSF/$APPLLOG $NE_BASE/inst/$CONTEXT_NAME/ Directory that stores the concurrent
logs/appl/conc request and manager log files.
FILE_EDITION Returns “run” or “patch” according to the Shows current file system in use (patch
environment that is set or run).

As shown in Table 4-1, even if you consolidated the list of environment variables and make it
include only the environment variables that you use often, there are actually more than 300 application
tier environment variables that are set by sourcing the environment file (EBSApps.env) in the EBS 12.2
application tier.
One thing that may attract your attention is that the files or directories the environment variables
point at when the environment is set to the patch edition. As shown in Table 4-1, it is not hard to guess
the corresponding patch edition value of an environment variable, because for most of the environment
variables that point to an application directory, the only difference between the patch and run edition values
of them is the root directory in the path being fs1 or fs2, in other words, the run base or patch base. That is, if
the run file system is fs2 and if a run edition environment variable is defined to point to a directory /u01/fs2/
directory_name, then its corresponding patch edition version should be pointing to /u01/fs1/directory_name.
In the next sections, you will see how to use these environment variables and strengthen your
knowledge about them, but before going there, let’s take a look at the database tier and explain how to set
the environment variables for working in the database node. We will also describe the database environment
variables. The database tier relies on a simpler file system architecture, as mentioned earlier. It is simpler
because it is based on the classic Oracle RDBMS file system that every Oracle core DBA and even Oracle
database operators are familiar with.
So, just like a stand-alone Oracle database node, the EBS database node is based on an Oracle Home,
an Oracle inventory (oraInventory), and a file system that stores the database files. The database files in EBS
12.2 may be put on a cooked file system that is supported by the underlying operating system (for example,
ext3, ext4 for Linux, or NTFS for Windows).

172
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

The database files may also be placed on ASM, which is based on the Grid Infrastructure; in other
words, it comes with the Grid Installation, which is available in the EBS 12.2 Rapidwiz Install Wizard.
Using ASM is a requirement for multinode database installations, in other words, for EBS Real
Application Clusters (RAC) installations. Using ASM to store the database files is preferred for single-node
installations too.
In this manner, if you use ASM to store your database files, you definitely need to add the Grid Home to
the directories that contribute the EBS database file system.
So if you use ASM to store your database files, then you can say that the database file system in EBS 12.2
is based on an Oracle Home, a Grid Home (optional), an Oracle inventory (oraInventory), and a file system(a
cooked file system or ASM) that stores the database files.
As mentioned, there are three or four main directories in the EBS 12.2 database file system, which
looks like a classic Oracle RDBMS Home. There are also some additional directories in the EBS database file
system not found in standard Oracle Home installations.
The appsutil directory and the directory pointed at by the TNS_ADMIN environment variable are the
additional directories. These EBS database-related directories reside in the Oracle Home directory, which is
the main directory that constitutes the biggest part of the EBS 12.2 database file system architecture.
Let’s take a look at the environment variables in the EBS 12.2 database tier, learn how to set them, see
their values, and understand what they are used for. The database tier environment variables are set using
the env script named <SID>_<hostname>.env (for example, TEST_somehost.env) that resides in the Oracle
Home.
The environment script is created by AutoConfig and can be sourced after logging in to the database
node operating system with the Oracle Database owner OS user account (for example, oracle), as shown in
Listing 4-10. Note that, in this example, the Oracle Home directory is /u01/install/TEST/11.2.0.

Listing 4-10. Setting the Database Environment

[oracle@somehost ~]$ . /u01/install/TEST/11.2.0/TEST_somehost.env

After sourcing the environment file that resides in the ORACLE_HOME, if you use the env command
to display the environment variables defined for your operating system terminal session, you will see the
environment variables shown Listing 4-11.
Note that the env command output in Listing 4-11 is truncated to discard the unnecessary environment
variables such as the environment variables named term or SHELL that are by default set by the operating
system because they are not your focus since they are not related to EBS 12.2.

Listing 4-11. env Output Showing the Database Environment Variable Set After Sourcing the EBS Database
Environment File
[oracle@somehost ~]$env | sort
ADJREOPTS=-Xms128M -Xmx512M
ADJVAPRG=/u01/install/TEST/11.2.0/appsutil/jre/bin/java
ADPERLPRG=/u01/install/TEST/11.2.0/perl/bin/perl
CONTEXT_FILE=/u01/install/TEST/11.2.0/appsutil/TEST_somehost.xml
CONTEXT_NAME=TEST_somehost
LANG=en_US.UTF-8
LD_LIBRARY_PATH=/u01/install/TEST/11.2.0/lib:/usr/X11R6/lib:/usr/openwin/lib:/u01
/install/TEST/11.2.0/lib:/usr/dt/lib:/u01/install/TEST/11.2.0/ctx/lib
LIBPATH=/u01/install/TEST/11.2.0/lib:/usr/X11R6/lib:/usr/openwin/lib:/u01
/install/TEST/11.2.0/lib:/usr/dt/lib:/u01/install/TEST/11.2.0/ctx/lib
NLS_DATE_FORMAT=DD-MON-RR
NLS_LANG=American_America.US7ASCII
NLS_NUMERIC_CHARACTERS=.,

173
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

NLS_SORT=binary
ORA_NLS10=/u01/install/TEST/11.2.0/nls/data/9idata
ORACLE_HOME=/u01/install/TEST/11.2.0
ORACLE_SID=TEST
PATH=/u01/install/TEST/11.2.0/perl/bin:/u01/install/TEST/11.2.0/bin:/usr/bin:/usr/sbin:/u01
/install/TEST/11.2.0/appsutil/jre/bin:/bin:/usr/bin/X11:/usr/local/bin:/u01/install/
TEST/11.2.0/perl/bin:/u01
/install/TEST/11.2.0/bin:/usr/bin:/usr/sbin:/u01/install/TEST/11.2.0/appsutil/jre/bin:/bin:/
usr/bin/X11:/usr
/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/
sbin:/home/oracle/bin:.:.
PERL5LIB=/u01/install/TEST/11.2.0/perl/lib/5.10.0:/u01/install/TEST/11.2.0/perl/lib/site_
perl/5.10.0:/u01
/install/TEST/11.2.0/appsutil/perl
SHLIB_PATH=/u01/install/TEST/11.2.0/lib:/usr/lib:/u01/install/TEST/11.2.0/ctx/lib
TNS_ADMIN=/u01/install/TEST/11.2.0/network/admin/TEST_somehost

The environment variables that are highlighted with bold in Table 4-2 are the environment variables
you use during your daily administration work, and the remaining list of environment variables such as
ADPERLPRG, LANG, and PERL5LIB, are the environment variables that are transparent but still needed in
order to administer the database tier components properly.
Table 4-2 explains these environment variables, Table 4-2 explains these environment variables, with
corresponding example values and descriptions.

Table 4-2. Environment Variables, the Example Environment Variable Values, and Descriptions

Environment Variable Example Directory/File/Value Description

NLS_SORT Binary Environment variable to specify the sort
mechanism for enabling the linguistic sorting
of results. It can be used by any operating
system tool and also by some scripts residing
in appsutil to set their environments and
produce their outputs accordingly.
ADJREOPTS -Xms128M -Xmx512M This is used for specifying Java command-
line options. Scripts like adconfig.pl use this
environment variable for executing their Java
commands with the desired options.
NLS_LANG American_America.US7ASCII Oracle’s standard environment variable in
the form of language_territory.character set.
It is used for specifying the locale for Oracle
tools running on the database node. It is
used by most of the Oracle binaries, libraries,
and scripts that reside in Oracle Home. For
example, sqlplus produces its output in the
language specified by NLS_LANG.
PERL5LIB /u01/install/TEST/11.2.0/ Environment variable that specifies the list of
perl/lib/5.10.0:/u01/install/ directories that store Perl library files. Since Perl
TEST/11.2.0/perl/lib/ is used often in Oracle products, the PERL5LIB
site_perl/5.10.0:/u01/install/ environment variable is required for the Perl
TEST/11.2.0/appsutil/perl scripts residing in Oracle Home to run properly.

(continued)
174
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Table 4-2. (continued)

Environment Variable Example Directory/File/Value Description

LD_LIBRARY_PATH /u01/install/TEST/11.2.0/lib:/ The LD_LIBRARY_PATH environment
usr/X11R6/lib:/usr/openwin/lib:/ variable is used for specifying the linker in
u01/install/TEST/11.2.0/lib:/usr/ Linux OS to search for libraries. It is used by
dt/lib:/u01/install/TEST/11.2.0/ OS, and it is set to include the directories in
ctx/lib Oracle Home that store the Oracle libraries.
It is used by the OS linker to find the needed
shared libraries, as these shared libraries are
used widely in the Oracle RDBMS.
ORA_NLS10 /u01/install/TEST/11.2.0/nls/ ORA_NLSXX environment variables are
data/9idata used to indicate where the Oracle RDBMS/
client software can locate the definitions of
character sets stored in .nlb files in ORA_
NLS** directories.
EBS has a requirement for ORA_NLS10 to set
the directory where the needed nlb files are
located, as well as the $ORACLE_HOME/nls/
data/9idatis that directory used in all of the
EBS 12.2 installations.
ORACLE_SID TEST Database SID of the EBS database that is used
by command-line tools like sqlplus when
executed in your terminal sessions.
LIBPATH /u01/install/TEST/11.2.0/lib:/ LIBPATH is used in AIX and is the equivalent
usr/X11R6/lib:/usr/openwin/lib:/ of the LD_LIBRARY_PATH environment
u01/install/TEST/11.2.0/lib:/usr/ variable in Linux. Although you are focused
dt/lib:/u01/install/TEST/11.2.0/ on Linux OS in this book and although
ctx/lib it is unnecessary, you can see that the
environment script sets the LIBPATH for
Linux too.
TNS_ADMIN /u01/install/TEST/11.2.0/network This environment variable points to the
/admin/TEST_somehost directory where the sqlnet configuration
file for the EBS database is stored. Tools like
sqlplus or the listener use this environment
variable to get the network configuration
information for use in their operations.
PATH /u01/install/TEST/11.2.0/perl/ Standard Linux PATH environment variable
bin: /u01/install/TEST/11.2.0/ that is used by the shell (for example, bash)
bin: /u01/install/TEST/11.2.0/ to determine the directories to search for
appsutil/jre/bin :/bin: /usr/local/ executable files. It is appended to include the
bin . . . binary directories in Oracle Home.
ADJVAPRG /u01/install/TEST/11.2.0/ Environment variable set to Java in the
appsutil/jre /bin/java appsutil directory. It is used by AD scripts
located in appsutil to run Java commands
with the appropriate Java version that comes
bundled with appsutil.

(continued)

175
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Table 4-2. (continued)

Environment Variable Example Directory/File/Value Description
CONTEXT_NAME TEST_somehost The context name that is used for naming
the subdirectories of some main directories
residing in Oracle Home. It is in the form
of <SID>_<db_hostname>. The directory
pointed at by TNS_ADMIN is an example
of its usage. In a standard installation, the
sqlnet configuration files are placed in the
$ORACLE_HOME/network/admin directory.
On the other hand, in an EBS database
node, the sqlnet configuration files are
put in to the $ORACLE_HOME/network/
admin/$CONTEXT_NAME directory.
CONTEXT_FILE /u01/install/TEST/11.2.0/ The environment variable that points to
appsutil/TEST_somehost.xml the database context file that is used by
AutoConfig.
ADPERLPRG /u01/install/TEST/11.2.0/perl/ The environment variable that points to the
bin/perl Perl executable, which should be used for
executing the Perl scripts that reside in Oracle
Home.
NLS_NUMERIC_ ., Environment variable that specifies the
CHARACTERS characters to use as the group separator and
decimal character. It is used commonly by the
tools in Oracle Home.
ORACLE_HOME /u01/install/TEST/11.2.0 Environment variable that points to the
directory where the Oracle software is
installed.
NLS_DATE_FORMAT DD-MON-RR Environment variable that specifies the
default date format to use with the TO_CHAR
and TO_DATE database functions. It is used
commonly by the tools and binaries in Oracle
Home to set the date format used in database
sessions.

Although the environment variable list given in Table 4-2 seems a little long, there are actually a few
environment variables that are used in your daily administration work in the database tier. That is, apps
DBAs mostly use the ORACLE_HOME, ORACLE_SID, and TNS_ADMIN environment variables to connect
and administer the database tier components. The work done varies according to the situation, but mostly
the database tier work is based on standard maintenance operations such as patching the database tier and
stopping or starting the database and listeners.
At this point, we have explained the EBS file systems by giving an overview of both the application
and database file system architectures, including the file system concepts such as dual and nonedition file
systems in the application tier. We also introduced the important environment variables and gave general
information about the environment variables used in EBS 12.2. Now that you have gotten to know the file
system architecture and the environment variables used in both the EBS application and the database tiers,
let’s continue with some examples so you can learn how to navigate the application and database tiers and
accomplish certain administration tasks.

176
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Working with Environment Variables on the Application Tier

and Navigating the Application File System
As mentioned earlier, you just need to use the environment variables to accomplish your admin tasks in
EBS 12.2. Using environment variables rather than memorizing and navigating the directories and files is
a more efficient way to perform administration work. When you need to use the OS terminal to do some
maintenance work such as stopping/starting the EBS services, running AutoConfig, executing cloning
scripts, and so on, environment variables ease your job, because they save you from dealing with several
important factors such as complex directory names, paths, and file names.
In addition to environment variables’ general handiness, dealing with the directory names or file
names may be a headache in multitier EBS 12.2 environments, which consists of multiple applications and/
or multiple database nodes. Also, if there are multiple EBS environments for you to administer such as
the DEV, TEST, and PROD environments, actions such as navigating in the varying directory paths will be
troublesome. That is, although the directory skin that comes with the standard installation may seem similar,
it actually differs because most of the directory paths in EBS 12.2 contain the context name that is derived by
the application server’s hostname and the database SID of the EBS environments.
In this manner, the directory names, important file names (for example, context file), and paths in
a TEST EBS instance may not be the same as the directories names, important file names, and paths in
a PROD EBS instance. So, you are probably responsible for administrating all the EBS instances in your
corporate networks, and using the environment variables is a more logical way for you to deal with these
varying directory and file names.
In EBS 12.2 almost all the technology components and scripts use these environment files; it is
impossible to administer these components or run these scripts without an environment (like a shell or
terminal) where the EBS environment variables are set. So, as using the environment variables are crucial
for administrating EBS 12.2, we’ll give you a better understanding of their usages and see how they ease your
jobs in the OS terminal by walking through the following scenarios.
Scenario 1, Scenario 2, and Scenario 3 in the following sections show how to use the environment
variables in the EBS 12.2 application tier for accomplishing certain administration tasks.

Scenario 1: Starting the Application Services

Log in as the applmgr user, set your runtime environment using the EBSapps.env script, and then change
your current working directory to the administration scripts.
Set your runtime environment using EBSapps.env, which is located in the base directory as follows.
Suppose the base directory is /u01/install.

[applmgr@somehost ~]$cd /u01/install

[applmgr@somehost ~]$. EBSapps.env run

E-Business Suite Environment Information

----------------------------------------
RUN File System : /u01/install/TEST/fs2/EBSapps/appl
PATCH File System : /u01/install/TEST/fs1/EBSapps/appl
Non-Editioned File System : /u01/install/TEST/fs_ne

DB Host: somehost.somedomain Service/SID: TEST

Sourcing the RUN File System ...

177
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

At this point, your runtime environment is set, and you can start using EBS-specific environment variables.
For this example, you need to change your working directory where the administration script is located.
So, you use the $ADMIN_SCRIPTS_HOME environment variable with the cd command.

[applmgr@somehost ~]$ cd $ADMIN_SCRIPTS_HOME

[applmgr@somehost scripts]$

Your current working directory is set to the directory where the administration scripts are located. As
shown by the following pwd command, you can use the ADMIN_SCRIPTS_HOME environment variable to
set the actual directory without knowing the full path of it.

[applmgr@somehost scripts]$
pwd
/u01/install/TEST/fs2/inst/apps/TEST_somehost/admin/scripts

As mentioned earlier, the administration scripts are located in the directory pointed at by ADMIN_
SCRIPTS_HOME, and the following ls command output lists these scripts as a confirmation. Note that the
following ls output is truncated to exclude some unnecessary files.

[applmgr@somehost scripts]$ ls
adadminsrvctl.sh adapcctl.sh adcmctl.sh adformsrvctl.sh adnodemgrctl.sh
adpreclone.pl adstrtal.sh jtffmctl.sh mwactl.sh
adalnctl.sh adautocfg.sh adexecsql.pl admanagedsrvctl.sh adopmnctl.sh adstpall.sh
gsmstart.sh java.sh mwactlwrpr.sh

Before going forward and using some of these scripts in the remaining part of this example, it is
worthwhile to take a look at these administration scripts by going through their definitions and usages, as
shown in Table 4-3.

Table 4-3. application Tier Administration Scripts Located in the $ORACLE_HOME/appsutil/

scripts/$CONTEXT_NAME Directory

Script Definition Usage

adadminsrvctl.sh Script for controlling WebLogic sh adadminsrvctl.sh {start|stop|status}
admin server. [forcepatchfs] [-nopromptmsg] [-silent]
adalnctl.sh Script for controlling applications sh adalnctl.sh {start|stop|status}
RPC listener.
adapcctl.sh Script for controlling Oracle sh adapcctl.sh {start|stop|status}
HTTP Server.
adautocfg.sh Applications AutoConfig script. sh adautocfg.sh
adcmctl.sh Script for controlling concurrent sh adcmctl.sh {start|stop|abort|status} <apps_
managers. username>/<apps_password> or <Applications
username/Applications password>
There are additional parameters normally not
used but may also be required in some fine-
grained configurations:
[sleep=<seconds>] [restart=<N|minutes>]
[pmon=<iterations>] [quesiz=<pmon_
iterations>] [diag=Y|N] [wait=Y|N]
(continued)

178
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Table 4-3. (continued)

Script Definition Usage
adformsrvctl.sh Script for controlling forms server sh adformsrvctl.sh {start|stop|status}
in socket mode.
admanagedsrvctl.sh Script for controlling WebLogic sh admanagedsrvctl.sh
managed servers. {start|adminmode|resume|suspend|force_
suspend|stop|abort|status} <managed_server_
name> [-nopromptmsg]
Or for starting all the managed servers that are
parts of a service type at once:
sh admanagedsrvctl.sh {startall|stopall}
<servicetype> [-nopromptmsg]
adnodemgrctl.sh Script for controlling the Node sh adnodemgrctl.sh {start|status|stop}
Manager. [-nopromptmsg]
adopmnctl.sh Script for controlling opmn. sh adopmnctl.sh {start|stop|status}
adstpall.sh Script for stopping all the sh adstpall.sh <apps_username>/<apps_
application services at once. password>
adstrtal.sh Script for starting all the sh adstrtal.sh <apps_username>/<apps_
application services at once. password>
gsmstart.sh Script for starting FNDSM. This must not be run from the command line.
This script is referenced in the application
tier’s listener configuration file ($TNS_
ADMIN/listener.ora).
java.sh Java script used by opmn and Java This is used by opmn and Java concurrent
concurrent programs. It is used programs, so is not used by apps DBAs.
like a wrapper for calling Java with
additional arguments.
jtffmctl.sh Script for controlling the sh jtffmctl.sh {start|stop}
fulfillment server.
mwactl.sh Script for starting and stopping the sh mwactl.sh start/stop <PORT>
Telnet server used in EBS mobile There are additional parameters normally not
applications. used but may also be required in some fine-
grained configurations:
[-java_config "VM Settings"] [-mwatop MWA_
TOP] [-login username/password]
adpreclone.pl Script for executing the preclone, perl adpreclone.pl { appsTier | atTechStack
which is a critical prerequisite | dev10gHome | fmwHome | wlsConfig |
operation for cloning EBS ohsConfig | appltop }
environments.
adexecsql.pl Script used by AutoConfig for We as apps DBAs don’t use this, but
executing the SQL scripts that nevertheless the usage is as follows:
update the application profiles. perl adexecsql.pl sqlfile=<file> <apps_user>
<apps_password>

179
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

So, once you reach the appsutil directory, where all the application control scripts listed in Table 4-3
reside, you use the relevant administration script to accomplish the required administration task.
As shown in Table 4-3, while you can stop, start, and check the statuses of all the application services
using the application administration scripts, you can also take some critical action such as taking a preclone
or executing an AutoConfig using the relevant application administration scripts.
In this example scenario, you use adstrtal.sh script for starting all the application services, as follows:

[applmgr@somehost scripts]$ sh adstrtal.sh apps/apps_password

Note that, as the security best practice, you can just execute the sh adstrtal.sh command without
providing the apps/apps_password value.
The adstrtal.sh script will request the password for the apps user when it starts its execution, as shown
next. This way, you can prevent the apps password from being saved in the Linux command history from
which the password could be retrieved later.

[applmgr@somehost scripts]$ sh adstrtal.sh

You are running adstrtal.sh version 120.24.12020000.10
Enter the APPS username: apps
Enter the APPS password:
Enter the WebLogic Server password:

Scenario 2: You Want to Check the SMTP Server Settings in

CONTEXT_FILE
Again, you log in as the applmgr user, set your runtime environment using the EBSapps.env script, and then
change your current working directory to the directory that stores the administration scripts. You then just
use the $CONTEXT_FILE environment variable to open the context file whose name may differ according to
the environment and that is located in the $INST_TOP/ apps/$CONTEXT_NAME/appl/admin/ directory.
So, you use your favorite editor (vi for us) to open the context file and view its contents accordingly. In
Figure 4-3, we see the part of the context file, which is related to the workflow mailer’s smtp server(outbound)
configuration.

[applmgr@somehost ~]$ vi $CONTEXT_FILE

Figure 4-3. Applications context file

180
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Scenario 3: You Want to Connect to the EBS Database Remotely from

the EBS Application Tier Node
Let’s first try to connect to the database without setting the environment.

[applmgr@somehost ~]$ sqlplus apps/apps

-bash: sqlplus: command not found

As shown, the shell can’t find the sqlplus executable without the environment settings.
Let’s set the ORACLE_HOME variable and then set the PATH environment variable to include the
$ORACLE_HOME/bin directory where sqlplus resides and try connecting to the database.

[applmgr@somehost bin]$ export ORACLE_HOME=/u01/install/APPS/fs1/EBSapps/10.1.2

[applmgr@somehost bin]$ export PATH=$PATH:$ORACLE_HOME/bin

[applmgr@somehost bin]$ sqlplus apps/apps

sqlplus: Release 10.1.0.5.0 - Production on Tue Aug 25 11:23:27 2015
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ERROR:
ORA-12162: TNS:net service name is incorrectly specified
Enter user-name:

Now, the problem is the TNS names, as you did not pass the TNS entry or any connection string to
sqlplus, so it could not find the service name and thus could not connect to the database.
You know that the TNS entry of the EBS database is defined in the tnsnames.ora file located in the $INST_
TOP/ora/10.1.2/network/admin directory, which is pointed at by the TNS_ADMIN environment variable, but
you don’t have the TNS_ADMIN or INST_TOP environment variable set for your shell environments.
Pretend you somehow navigate to the directory where the tnsnames.ora file resides manually without
using environment variables, open tnsnames.ora, and get the EBS database connection information
presented to you like in the example tnsnames.ora file shown in Figure 4-4.

[applmgr@somehost ~] cd /u01/install/APPS/fs1/inst/apps/TEST_somehost/ora/10.1.2/network/admin
[applmgr@somehost admin]$ vi tnsnames.ora

Figure 4-4. A part of the tnsnames.ora file located in the application tier, showing the EBS database
connection information
181
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

After getting the database connection information, let’s retry executing sqlplus by supplying the
connection string to it.

[applmgr@somehost admin]$ sqlplus apps/oracleR12@somehost:1521/TEST

sqlplus: Release 10.1.0.5.0 - Production on Tue Aug 25 11:39:18 2015

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL>

At last, you reached your goal and connected to the database. But you have taken a lot of actions to
accomplish such an easy task like connecting to the database from the application tier. This is not acceptable
and fortunately not the case in an apps DBA’s life, as you use the environment variables and set them all at
once using the EBSapps.env script.
Let’s do the same database connection with sourcing the environment file and see how easy it actually is.

[applmgr@somehost ~]$ . /u01/install/APPS/EBSapps.env run

E-Business Suite Environment Information
----------------------------------------
RUN File System : /u01/install/APPS/fs1/EBSapps/appl
PATCH File System : /u01/install/APPS/fs2/EBSapps/appl
Non-Editioned File System : /u01/install/APPS/fs_ne
DB Host: somehost.somedomain Service/SID: TEST
Sourcing the RUN File System ...

[applmgr@somehost ~]$ sqlplus apps/apps

SQL>

As shown in the previous code, after sourcing EBSapps.env to set the EBS-related environment variables
in the application tier, there is no need to set PATH manually, no need to check the tnsnames.ora file for
getting the database connection information, and no need to specify the connection string while executing
sqlplus for connecting to the EBS database. Actually, the environment variables PATH, ORACLE_HOME,
TNS_ADMIN, TWO_TASK, and several more are set by the EBSapp.env script, and they are used when you
execute sqlplus to connect to the database from your application tier terminal connection.
So, as shown in the previous scenarios, you just use the environment variables to navigate the
application file system. Using the environment variables, you don’t even need to know things like the
directory that stores the application tier administration scripts or the full path of the context file in which
you make some modifications for AutoConfig. Moreover, you don’t even know the database SID of the EBS
database to establish a sqlplus connection to it.
As the bottom line, as explained earlier, in addition to the example scenarios, almost any
administration task that needs some navigation in the application tier can be done using the environment
variables. You have seen how the environment variables eases your job while working in applications’
OS terminals. In addition, you have seen that there are some tasks that can be done only when the
environment is set properly.
Let’s continue with the database tier and see how the environment variables used in the database tier
nodes accomplish administration tasks.

182
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Working with Environment Variables on the Database Tier

and Navigating the Database File System
Like in the application tier, environment variables are widely used for doing the administration work in the
database tier. Although there are a few environment variables present in the database tier, they are crucial
for administrating the most important technology, Oracle Database, which resides in the database tier of
EBS 12.2 environments.
As mentioned earlier, the biggest part of an EBS 12.2 database tier is Oracle Database. Looking from
the OS side, excluding the EBS database model, which resides in EBS database, you can say that EBS 12.2
delivers a standard Oracle Database Enterprise Edition hosted by a database file system that includes a
standard Oracle Home, with the exception of some additional tools and some additional directories.
So, the EBS database consists of an Oracle Home that all the Oracle core DBAs and most of the Oracle
database operators are familiar with. As core DBAs or Oracle database operators already know, to administer
an Oracle database, there should be at least tree environment variables defined properly in your shells or
terminals where you execute the administration commands. That is, the environment variables named
ORACLE_HOME, ORACLE_SID, and PATH constitute the minimum set of environment variables that should
be set to the proper values for being able to administer Oracle Database through OS terminals.
However, when we talk about an EBS database, we actually need to talk about more than these three
environment variables, as the EBS database is an AutoConfig-enabled environment in which all the
management for its configurations is done using the AutoConfig tool. From init.ora parameters such as sga_
target to listener port numbers and from the listener name to the values to be set for environment variables,
almost all the configuration is done using AutoConfig in the EBS 12.2 database tier.
For example, the sqlnet configuration files such as sqlnet.ora, tnsnames.ora, and listener.ora are
created by AutoConfig, and these sqlnet files are placed in the relevant subdirectories named in the form of
<sid>_<hostname> located in the default directories where they normally reside in standard Oracle Homes.
That is, while the sqlnet files are located in the $ORACLE_HOME/network/admin directory
in standard Oracle Database environments, they are located in the $ORACLE_HOME/network/
admin/<sid>_<hostname> directory in EBS database environments.
Because EBS database environments utilize this kind of nondefault directory, you need to have
additional environment variables such as TNS_ADMIN to point to the locations they are located. Without
TNS aliases, for instance, you can only connect to the EBS database using EZ-connect (sqlplus apps/
pwd@<db_host>:<listener_port</<SERVICE_NAME>), which is not a preferred method because it requires
you to supply the database hostname, the listener port, and the service name of the database each time
you want to connect to the database remotely. So, without setting the TNS_ADMIN environment variable
properly, you can’t use sqlplus without supplying a connection string to connect to your database through
the database listener in EBS 12.2. Also, you can’t even administer the listener in the EBS database tier
without the TNS_ADMIN environment variable set properly.
Database- and listener-related log and trace files are also placed in the relevant subdirectories named in
the form of <sid>_<hostname> located inside the default directories where they normally reside in standard
Oracle Homes, and that’s why it is better to use the environment variable CONTEXT_NAME, which is
actually set to <sid>_<hostname> while navigating the database tier.
Also, as AutoConfig is based on a context file, there is a context file stored in EBS Oracle Home, and it
is pointed at by an additional environment variable named CONTEXT_FILE. Thus, you use this CONTEXT_
FILE variable to open the context file for your EBS database whenever you want to check the value of the
context variables it.
Moreover, as EBS databases are cloned using a tool called Rapid Clone, the Oracle Home used in EBS
12.2 also includes the Rapid Clone scripts that are not present in standard database Oracle Homes. As these
kinds of scripts are located in the directory named appsutil, which is an additional directory deployed as
part of the Oracle Home of the EBS database tier, you need to navigate to this directory from time to time.

183
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

■ Note The script for executing the autoconfig and administration scripts for controlling the database tier are
also located in the appsutil directory.

Before giving some examples about using the environment variables and navigating in the database
tier file system for accomplishing some admin tasks, we’ll introduce the administration scripts delivered in
the $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME directory, as you will see some of them in action
while you are going through the scenarios that will be described in the next paragraphs.
Table 4-4 describes these administration scripts and gives usages.

Table 4-4. Database Tier Administration Scripts Located in the $ORACLE_HOME/appsutil/

scripts/$CONTEXT_NAME Directory

Script Description Usage

adautocfg.sh AutoConfig script sh adautocfg.sh
adchknls.pl Script to check the existence of perl adchknls.pl
$ORACLE_HOME/nls/data/9idata and
cr9idata.pl in that directory
addbctl.sh Database stop/start script To stop:
sh addbctl.sh stop <shutdown mode>
(normal|immediate|abort)
To start:
sh addbctl.sh start
addlnctl.sh Listener stop/start script To stop:
sh addlnctl stop <listener_name>
To start:
sh addlnctl start <listener_name>
adexecsql.pl Script to execute all SQL scripts that Normally gets executed by AutoConfig, not by
update the profiles in an AutoConfig run apps DBAs
Nevertheless, the usage is as follows:
perl adexecsql.pl sqlfile=<file> <apps_user>
<apps_password>
adlsnodes.sh Wrapper script to check whether the sh adlsnodes.sh
cluster manager is available in a RAC
environment
adpreclone.pl Script for executing the preclone, which perl adpreclone.pl ( dbTier | database |
is a critical prerequisite operation for dbTechStack )
cloning EBS environments
adstopdb.sql Script for stopping the database used by Used by addbctl.sh; nevertheless, here is an
the addbctl.sh script internally example usage:
sqlplus /nolog @adstopdb.sql "sys as sysdba"
immediate
adstrtdb.sql Script for starting the database used by Used by addbctl.sh; nevertheless, here is an
the addbctl.sh script internally example usage:
sqlplus /nolog @adstrtdb.sql "sys as sysdba"

184
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

So, as the environment variables must be used in the database tier for administrating the EBS 12.2
databases and as the context file and scripts for enabling the EBS-specific database tools such as AutoConfig
and Rapid Clone are located in the appsutil directory located in the database Oracle Home directory, we’ll
give you a better understanding about both the environment variables and the use of the scripts in the
appsutil directory by walking through some scenarios. The following scenarios show different use cases
for the environment variables through the administration scripts addlnctl.sh and addbctl.sh located in the
appsutil directory in the EBS 12.2 database tier for accomplishing the related administration tasks required
to be done in certain scenarios.

Scenario 1: Restarting the EBS Database and the Database Listener

You log in as the RDBMS owner OS user (for example, oracle), set your runtime environment using the
environment script (named in the form of <sid>_<hostname>.env) located in Oracle Home directory, and
then change your current working directory to the administration scripts. Also, as you have the opportunity
to administer the database and listener using the sqlplus and lsnrctl executables, you will also see the
method for starting the database and listener using sqlplus and lsnrctl in this example scenario.
In this scenario, the Oracle Home is the /u01/install/TEST/11.2.0 directory.

■ Note Although it is not crucial and the approaches in the database tier won’t differ according to the
database release, we still feel the need to give you the following information at this point.

The directory name used in this example is 11.2.0 because the EBS environment used in this example
has an 11g R2 database.
You first source the <sid>_<hostname> environment file that is stored in the directory pointed at by
the $ORACLE_HOME environment variable and set the proper environment consisting of the environment
variables such as ORACLE_HOME, ORACLE_SID,TNS_ADMIN, PATH, LD_LIBRARY_PATH, CONTEXT_
FILE,CONTEXT_NAME, and NLS_SORT, as follows:

[oracle@somehost ~]$ . /u01/install/TEST/11.2.0/TEST_somehost.env

After setting the proper environment, you follow this action plan to restart the listener and EBS database:
1. Stop the listener.
2. Stop the database.
3. Start the listener.
4. Start the database.
To stop the listener, you use the addlnctl.sh script, which can be used to stop and start the database.
You first navigate to the $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME directory where all the
database administration scripts are located and then run the addlnctl.sh script by supplying it with the string
stop and the name of the EBS listener that you want to stop as arguments.

[oracle@somehost ~]$ cd $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME

[oracle@somehost TEST_somehost]$ sh addlnctl.sh stop TEST

185
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Note that the listener name provided in this scenario is TEST. However, the value of the listener can be
derived by the context variable named s_db_listener, defined in the database tier context file. Note that as for
the RAC instances, we recommend using srvctl for stopping the database listener, but still, the names of the
RAC listener can be derived by the database tier context file.
In this context, the local listener of a RAC node is written in the context variable named s_
instLocalListener, and the remote listener, also known as the scan listener of a RAC node, is written in the
context variable named s_instRemoteListener.
After stopping the listener, you use the addbctl.sh script to shut down the EBS database. addbctl.sh
uses adstopdb.sql located in the same directory ($ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME) in
conjunction with sqlplus to shut down the EBS database.
So, you run addbctl.sh with “stop” and the shutdown mode (in this example, you use “immediate”)
arguments to shut down an EBS database, described as follows:

[oracle@somehost TEST_somehost]$ sh addbctl.sh stop immediate

As you may realize by looking the previous addbctl.sh command that although the default shutdown
mode used in the addbctl.sh script is normal mode, you have initiated an immediate shutdown by supplying
the argument immediate to the addbctl.sh script. This is because usually you stop the application tier
services and wait for all the application processes to be cleared before stopping an EBS database. Moreover,
you take your downtime and are usually sure that no one does anything critical in the EBS environment
while you are stopping it.
So, as all the services are stopped and there is no need to wait for uncommitted transactions to commit
or open sessions to quit, you just initiate an immediate mode shutdown rather than initiating a normal one
to shut down the EBS databases.
As for the RAC instances, we recommend using srvctl for stopping the database. The database name can
be derived by the context variable named s_dbGlnam defined in the database tier context file.
After stopping the database, you use the addlnctl.sh script again to start the listener, but this time
you run the addlnctl.sh script with the argument “start” rather than “stop” because your goal is to start the
listener TEST that you just stopped.

[oracle@somehost TEST_somehost]$ sh addlnctl.sh start TEST

For the RAC instances, we recommend using srvctl for starting the database listener, but still, the names
of the RAC listener can be derived by the database tier context file. In this context, the local listener of a RAC
node is written in the context variable named s_instLocalListener, and the remote listener, also known as the
scan listener of a RAC node, is written in the context variable named s_instRemoteListener.
After starting the listener, you use the addbctl.sh script once again. But this time, you use it to start the
EBS database. For the start operation, addbctl.sh uses adstrtdb.sql located in the same directory with it. The
addbctl.sh script uses adstrtdb.sql in conjunction with sqlplus to start the EBS database.
This time, you run addbctl.sh with the “start” argument to start the EBS database, as follows:

[oracle@somehost TEST_somehost]$ sh addbctl.sh start

At this point, your listener and database start servicing again, and you have reached your goal:
completing the restart operation of the listener and the EBS database.
As for the RAC instances, we recommend using srvctl for starting the EBS database. The database name
can be derived by the context variable named s_dbGlnam defined in the database tier context file.
Now, let’s take a look at the alternative manual method for accomplishing such a restart operation.
In the manual method, you just execute the lsnrctl command for controlling the listener and execute the
sqlplus command to control the EBS database.

186
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

To stop the listener, you use the lsnrctl command directly by supplying the operation (stop) and the
listener name (the listener name is TEST in this example) arguments, as shown here:

[oracle@somehost TEST_somehost]$ lsnrctl stop TEST

After stopping the listener with lsnrctl, you initiate an “sqlplus as sysdba” connection to the database
and issue a “shutdown immediate” command to shut down the EBS database with the immediate option.

[oracle@somehost TEST_somehost]$ sqlplus "/as sysdba"

SQL> shutdown immediate;

Database closed.
Database dismounted.
ORACLE instance shut down.

After stopping the database, as your goal is to restart the listener and the database, you just start the
listener using lsnrctl and then start the database again by using the sqlplus, as follows.

■ Note To start the listener, you run the lsnrctl command by supplying it with the type of operation you want
to do (start) and the listener name you want to administer (TEST).

[oracle@somehost TEST_somehost]$ lsnrctl start TEST

To start the EBS database, you first execute the sqlplus “/as sysdba” command and get your SQL
prompt. Then, you execute the startup command in the SQL prompt to start the EBS database, as follows:

[oracle@somehost TEST_somehost]$ sqlplus "/as sysdba"

SQL> startup
ORACLE instance started.
Total System Global Area 5.0241E+10 bytes
Fixed Size 2240016 bytes
Variable Size 1879048688 bytes
Database Buffers 4.8318E+10 bytes
Redo Buffers 40890368 bytes
Database mounted.
Database opened.

Scenario 2: Modifying the Database Configuration Using AutoConfig

You log in as the RDBMS owner OS user (for example ,oracle) and set your shell environment using the
environment script (<sid>_<hostname>.env) located in the Oracle Home directory. Next, you open the
database context file by using the CONTEXT_FILE environment variable and your favorite text editor (for
example, vi in Linux) and then make the modification in that file, as shown in Figure 4-5. Lastly, you run the
autoconfig to propagate the change you have made in the context file.
Let’s take a look at the commands and environment variables you use to change the listener name of the
EBS 12.2 database, by changing the value associated with it in the context file and running AutoConfig afterward.
First, you source the environment file as follows:

[oracle@somehost ~]$ . /u01/install/TEST/11.2.0/TEST_somehost.env

187
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Next, you open the database context file pointed at by the $CONTEXT_FILE environment variable using
the vi editor and update the relevant context variable stored in the context file, as shown here:

[oracle@somehost ~]$ vi $CONTEXT_FILE

Figure 4-5 shows part of the database context file, where you update the s_db_listener context variable
to the new listener name. (In this example, you change the listener name from TEST to TESTNEW.)

Figure 4-5. A part of the database context file pointed at by the $CONTEXT_FILE environment variable in the
database tier, showing the change made in the database listener name

Lastly, after modifying and saving the database context file, you navigate to the $ORACLE_HOME/
appsutil/scripts/$CONTEXT_NAME directory and run the AutoConfig script by supplying the appspass
argument to it.
Note that the appspass argument is not mandatory, as the AutoConfig script asks for the apps password
anyway. However, we have used it in the following example command because we wanted to give a one-line
command for the AutoConfig execution:

[oracle@somehost ~]$ cd $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME

[oracle@somehost TEST_somehost]$ sh adautocfg.sh appspass=apps

So, AutoConfig re-creates the sqlnet configuration files, and as a result, the listener name specified in
the listener configuration file (listener.ora) gets changed.
At this moment, you have reached your goal, and you may now stop the already running listener, which
can be considered as the old listener, and then start the new listener using addlnctl.sh as follows:

[oracle@somehost TEST_somehost]$ sh addlnctl.sh stop TEST

Logfile: /u01/install/PROD/11.2.0/appsutil/log/TEST_somehost/addlnctl.txt

[oracle@somehost TEST_somehost]$ sh addlnctl.sh start TESTNEW

Logfile: /u01/install/PROD/11.2.0/appsutil/log/TEST_somehost/addlnctl.txt

188
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

You are running addlnctl.sh version 120.4

Starting listener process TESTNEW ...
...
.....
.......

addlnctl.sh: exiting with status 0

So far, you have seen the file system architecture delivered in EBS 12.2 and also seen the environment
variables. You understand their usages because you have navigated both the application tier and the
database tier using them as well as accomplished the tasks explained in the examples. Before going to the
next chapter, let’s take a look at the log files in EBS 12.2 and complete this chapter by having a complete
awareness of the entities on the EBS 12.2 file system.

EBS 12.2 Applications Log Files

Because EBS environments are generally based on two tiers, named the application tier and the database
tier, and because different kinds of technology components and applications run on each of these tiers, the
log files in EBS 12.2 are placed in the directories according to the components they are produced for. In other
words, the log files related to application tier components are placed in the application tier file system, and
the log files related to the database components are placed in the database tier file system.
Application log files in EBS 12.2 are produced for FMW components, the concurrent processing server,
patching tools, and administration utilities such as logs for ad utilities, application service control scripts,
and AutoConfig scripts.
Let’s start with the directory pointed at by the environment variable named LOG_HOME. $LOG_HOME
is an important environment variable, and it points to the log directory located in the instance top directory
($INST_TOP).
$LOG_HOME stores different types of log files, and these log files are categorized by the directories they
reside in, as follows:
• $LOG_HOME/appl/admin/log: Stores administration scripts’ log files such as the
log files produced for starting and stopping the managed servers as well as the
AutoConfig log file and the log files for adstrtal.sh, adstpall.sh, and adnodemgrctl.sh
scripts.
• $LOG_HOME/appl/rgf: Stores the log files produced while registering WLS
listeners and also stores the TXK configuration log files such as log files for the
txkSetAppsConf.pl script.
• $LOG_HOME/ora/10.1.2/forms: Stores forms rti files, which contain metric data
about the forms’ runtime processes.
• $LOG_HOME/ora/10.1.2/install: Stores the make/compilation logs of the binaries in
10.1.2 Oracle Home.
• $LOG_HOME/ora/10.1.2/network: Stores the application rpc listener’s log files.
• $LOG_HOME/ora/10.1.2/reports/cache: Stores Oracle Reports server’s cache files.
That is, when concurrent requests that run Oracle Reports are submitted, temporary
files are created under this directory.
So, the log file for the administration scripts, AutoConfig, TXK configurations, WLS listener registrations,
forms runtime metrics, 10.1.2 Oracle Home compilations, RPC listener, and the reports cache are placed in
the $LOG_HOME directory.

189
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

The log files for FMW components such as Oracle Process Manager (opmn), Oracle HTTP Server (OHS),
and the WebLogic server logs are stored in the subdirectories of the directory pointed at by the FMW_HOME
environment variable.
The following is a list describing the important Fusion Middleware log directories and the type of the
logs files stored in them:
• $IAS_ORACLE_HOME/instances/EBS_web_<SID>_OHS<INSTANCE_NUMBER> /
diagnostics/logs: Stores Oracle HTTP Server and OPMN logs.
• $FMW_HOME/wlserver_10.3/ common/nodemanager/nodemanager.log: Stores
Node Manager log files.
• $EBS_DOMAIN_HOME/<server_name>/logs: Stores the HTTP transaction logs, as
well as diagnostic, log, and output files for WebLogic admin and managed servers.
Actually, the directory $EBS_DOMAIN_HOME/AdminServer stores much more than
that; $EBS_DOMAIN_HOME/AdminServer/log/ stores the WebLogic domain log
(DomainName.log), which contains forwarded information from the defined servers
within the EBS WebLogic domain. Oracle WebServices Manager (owsm) logs are also
stored in the $EBS_DOMAIN_HOME/AdminServer/log/owsm/msglogging directory.
• $EBS_DOMAIN_HOME/AdminServer/data: Stores the Embedded Ldap server and
Ldap access logs.
• $EBS_DOMAIN_HOME/servers/server_name/adr/diag/ofm/EBS_
domain_<sid>/<server_name>/incident: Stores the incident files created by the
Diagnostic Framework, which is explained in Chapter 7 of this book.
In addition to IAS_ORACLE_HOME, LOG_HOME, and FMW_HOME, there are log files stored in other
application directories such as directories pointed at by the ADOP_LOG_HOME and APPLCSF environment
variables.
The directory pointed at by ADOP_LOG_HOME is stored in noneditioned file system (fs_ne), and the
EBS 12.2 application patching tool’s log files are stored here.
The directory skin of the adop log files is as follows:

$ADOP_LOG_HOME/<adop_session_id>/<phase_timestamp>/<context_name>

The directory pointed at by the APPLCSF environment variable is also stored in the noneditioned file
system (fs_ne), and the concurrent processing log and output files are stored in this directory. The log and
output files stored in this directory are actually separated into two subdirectories as follows:

Concurrent manager and concurrent program/request log files: $APPLCSF/$APPLLOG, typically

$APPLCSF/log
Concurrent program/request output files: $APPLCSF/$APPLOUT, typically $APPLCSF/outt

Lastly, the logs generated by the adadmin utility, which can be used to do several administration tasks
such as compiling forms and compiling apps schema, are also stored in the noneditioned file system (fs_ne),
in the directory pointed at by $APPL_TOP_NE/../log/adadmin.
So, you have seen the important log directories and what kind of log files are stored in them. By knowing
this log file and log directory mapping, an apps DBA can easily navigate to the right directory and start
analyzing the related log files, without navigating the complex application file system directory structure
and trying to find the related log file by listing the contents of all the log directories one by one. That is, by
knowing the directories and the type of the log files stored in them, the apps DBA can directly navigate to the
directory that contains the related log file, list the log files by timestamp, open the related log file using their
favorite text editor, and start analyzing it.

190
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

So far, you have gained the knowledge to investigate the problems that may arise in the application tier
components by going through the application tier log directories and the type of log files stored in them.
Let’s continue with the database tier and gain knowledge about the log files that can be used to
investigate database tier problems.

EBS 12.2 Database Log Files

The Oracle database delivered within EBS 12.2 is not so different from any standard Oracle Database.
The EBS database has almost the same file system architecture as the file system that is deployed when
you use runInstaller to install a stand-alone Oracle Database. So, it is just an Enterprise Edition Oracle
Database 11GR2 (or 12c, if the installation is done with the latest startCD) that has almost the same logging
mechanisms, log files, and directories that can be found in any Oracle Database environment.
As we have explained, the database file system architecture used in EBS 12.2 is almost the same but not
exactly the same as the standard Oracle database file systems. The reason is that there are some application-
aware AD utilities and scripts that are stored in the appsutil directory in the Oracle Home of the EBS
database, and these utilities and scripts are normally not delivered in a standard Oracle Database file system
architecture. Moreover, these scripts and utilities produce log files that also can’t be found in standard
Oracle Database log file directories.
So, although it seems like a standard Oracle Database file system, and even if the log mechanism used
in the EBS database is the same as the mechanism used in all the Oracle databases, we will explain the EBS
log files in this chapter.
By considering some exceptional log directories, which can’t be found in non-EBS databases, you
will take a look at the log files produced in the database tier, and we will explain where to look in the EBS
database file system to find the related log files while diagnosing a database tier problem.
As for the database tier logging, EBS 12.2 uses the standard Oracle Database logging mechanism that
core DBAs are already familiar with.
The EBS 12.2 database uses a diagnostic destination specified by the database parameter diagnostic_dest,
which introduced with the release of Oracle Database 11g, to store all of its log files. While the diagnostic_dest
parameter can be changed to point to any directory that the Oracle database OS user has necessary privileges
for, the EBS installer named Rapidwiz by default sets the diagnostic_dest parameter to the directory named
/<sid>_hostname>, stored in $ORACLE_HOME/admin ($ORACLE_HOME/admin/<sid>_hostname>).
The current value of the diagnostic_dest parameter can be checked at any time to display the diagnostic
directory used in an EBS 12.2 database. The value of the diagnostic_dest parameter can be displayed using a
sqlplus connection and the show parameter command, as shown in Listing 4-12.

■ Note As we have already explained the environment variables and environment setting earlier, we won’t
show how to set the database environment before using the sqlplus command or any other command displayed
in the upcoming examples.

Listing 4-12. The Output of show parameter diagnostic_dest Used with sqlplus to Display the Value of the
diagnostic_dest Database Initialization Parameter
[oracle@somehost ~]$ sqlplus "/as sysdba"

SQL> show parameter diagnostic_dest

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------
diagnostic_dest string /u01/install/PROD/11.2.0/admin /TEST_somehost

191
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

So, the EBS Oracle database uses the directory pointed at by the diagnostic_dest parameter to store
Oracle Database log files, and it has the subdirectories as shown in the ls output provided in Listing 4-13.
Note that in Listing 4-13 we are using the same EBS database that we used to show the diagnostic_dest value
in Listing 4-12.

Listing 4-13. ls command Output Showing the Subdirectories of the diagnostic dest Directory
[oracle@somehost ~]cd /u01/install/PROD/11.2.0/admin//TEST_somehost
[oracle@somehost TEST_somehost]$ ls
bdump cdump diag oradiag_applmgr oradiag_oracle udump

Although there are six subdirectories named bdump, cdump, diag, oradiag_applmgr, oradiag_oracle,
and udump inside the diagnostic dest directory as listed in Listing 4-13, only three of them are in use. That
is, the bdump, cdump, and udump directories that come with the installation are just there to support the
old-style Oracle database logging, and they are not used by the EBS Oracle database to store its log files.
The diag, oradiag_applmgr (in the form of oradiag_ApplicationOSUser), and oradiag_oracle (in the form of
oradiag_databaseOSUser) directories are the actual directories where the database tier log files are created.
Let’s start with the diag directory stored in the directory pointed at by the diagnostic_dest parameter
($ORACLE_HOME/admin/<sid>_<hostname>). The diag directory is the main and actual directory where
the EBS database log files are stored. To analyze a database problem, you usually check the log files stored
in the diag directory, as the diag directory contains the logs created for user sessions, background processes
and database alerts, and the listener. To store several type of log file in a meaningful manner, the log files
stored in the diag directory are categorized and stored in the subdirectories according to their types and the
database tier components they are created for.
The tree command output shown in Listing 4-14 shows the important subdirectories that reside in the
diag directory. Also, the information displaying the type of log files that are stored in these subdirectories,
can be found on the right side of each directory listed in the tree command output shown in Listing 4-14.

■ Note There are Automatic Diagnostic Repository (ADR)–related directories in the output provided by the tree
command used in Listing 4-14. You should stick to them for now, as we will explain ADR just after Listing 4-14.

Listing 4-14. tree Command Output Showing the Subdirectories of the Diag Directory by Giving the
Information About the Types of Log Files Stored in Them
tree $ORACLE_HOME/admin/TEST_somehost/diag/ -L 4 -A

diag/
|-- rdbms : root directory that stores rdbms log and trace files
|-- |-- TEST : directory named with the Database name in order
to separate the log files according to the
Oracle Database SIDs in case where there are
multiple databases uses the same diagnostic
destination directory.
|-- |-- |-- TEST : directory named with the Database sid in order
to separate the log files according to the
Oracle Database SID in case where there are
multiple RAC instances uses the same diagnostic
destination directory.

192
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

|-- |-- |-- |-- alert : directory where xml formatted database alert
log files reside (log.xml ,log1.xml and so on).
|-- |-- |-- |-- cdump : directory that stores the core dumps.
|-- |-- |-- |-- incident : directory that stores the ADR incident files
created when an important database error is
encountered such as ORA-00600, ORA-01578,
ORA-07445 and consist of error stacks, call
stacks, block dumps etc..
|-- |-- |-- |-- incpkg : directory that stores the ADR packages
created by packaging incidents into bundles.
|-- |-- |-- |-- trace : directory that stores user and background traces
(aa replacement for the old udump and bdump
directories). The text based database alert log
file named with the format alert_<SID>.log, is
also stored in trace directory.
|-- tnslsnr : root directory that stores listener log and
trace files
|-- |-- somehost : directory named with the hostname (database
server’s hostname) that listener is working on.
|-- |-- TEST : The service name that the listener listens for.
|-- |-- |-- alert : directory where xml formatted listener log
files resides (log.xml, log1.xml and so on).
|-- |-- |-- cdump : directory that stores the core dumps.
|-- |-- |-- incident : directory that stores the ADR incident files
created when an important listener error is
encountered.
|-- |-- |-- incpkg : directory that stores the ADR packages
created by packaging incidents into bundles.
|-- |-- |-- lck
|-- |-- |-- trace : Listener trace files and the text based listener
log file named with the format <listener_name>.
log are stored in this directory

As shown in Listing 4-14, you have two main subdirectories named tnslsnr and rdbms in the diag
directory. The database-related diagnostic files (logs, trace, core dumps, and so on) are placed in the related
subdirectories of the rdbms directory, and the listener-related diagnostic files are placed in the related
subdirectories of the tnslsnr directory.
As it is important to know the directory structure where the EBS database log files are stored, it is also
crucial to know how to analyze the log files created in these log directories.
As apps DBAs, you can always use your favorite text editors to analyze these log files, as shown in
Figures 4-6 and 4-7.

193
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Figure 4-6. Using the vi editor to search for database errors in alert_<sid>.log file, using “ORA-” as the search item

194
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Figure 4-7. vi editor placing the cursor in the first database error returned from the search shown in Figure 4-6

As depicted in Figure 4-6, you use the vi editor to check the text-based database alert log (alert_<sid>.log)
to see whether any errors are reported by the database by making a search using the string “ORA-,” as you
know that the database error messages start with “ORA-” (for example, ORA-600, ORA-07445, and so on).
By using such a search method, you can directly jump to the log lines created when the database errors
are encountered, as shown in Figure 4-7.
So, using text editors and their capabilities can be an efficient way to analyze the log files and find the
causes of the database problems. Sometimes you need to check the database’s alert log to see what’s wrong
in the database, like the archival problem shown in Figure 4-7, and sometimes you need to check several
trace files to gather a bunch of diagnostic information and state the problem accordingly.
In addition to a text editor, the Oracle database used in EBS 12.2 offers a tool called Automatic Diagnostic
Repository for analyzing the logs and finding problems. Using ADR to diagnose problems is much easier than
navigating in the directory structure and dealing with the huge number of files using text editors.
Even though ADR is beyond the scope of this chapter, let’s take a look at its usage, as shown in Listing 4-15.

■ Note In Chapter 7, which is focused on FMW, we will explain ADR in more detail. Although Chapter 7 is not
related to Oracle Database, the logic behind ADR and its usage is similar to the database tier.

195
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

In Listing 4-15, we use ADR to view the contents of the database alert log file, without navigating the
diagnostic directories and dealing with a text editor.
First, you execute the adrci command to open the Automatic Diagnostic Repository Command
Interpreter (adrci) utility, which is the utility for executing ADR commands.

[oracle@somehost ~]$ adrci

adrci>

After opening the adrci utility, you use the show alert command to display the alert log of the database,
as follows:

adrci>show alert

The adrci utility lists the available diagnostic homes present in the diagnostic repository and waits for
you to choose the diagnostic home, which is your focus right now.
Choose the alert log from the following homes to view:
1: diag/rdbms/test/TEST
Q: to quit
Please select option: 1
You choose the diagnostic home, and the alert log is displayed, as shown in Listing 4-15.

Listing 4-15. Using ADRCI to Display the Contents of the Database Alert Log File (alert_<sid>.log File)
Output the results to file: /tmp/alert_8084_14034_TEST_1.ado
2014-06-25 04:42:28.610000 -04:00
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =44
LICENSE_MAX_USERS = 0
SYS auditing is enabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /u01/install/TEST/11.2.0
...
.....
........

■ Note The adrci utility internally uses the vi editor to display the alert log contents.

The adrci utility can do much more than displaying alert log contents. Listing 4-16 shows an example
output produced by adrci when you execute the show incident command.

196
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

Listing 4-16. An Example adrci Output Showing the Incidents

adrci> show incident

ADR Home = /u01/install/TEST/11.2.0/admin/TEST_somehost/diag/rdbms/test/TEST:

*****************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ---------------------------------------------------------- -----------
26457 ORA 7445 [__intel_new_memcpy()+2960] 2014-09-11
13:49:55.196000 -04:00
26465 ORA 7445 [__intel_new_memcpy()+2960] 2014-09-11
13:51:15.144000 -04:00
26489 ORA 7445 [__intel_new_memcpy()+2960] 2014-09-11
13:52:18.166000 -04:00
26409 ORA 7445 [__intel_new_memcpy()+2960] 2014-09-11
13:53:24.305000 -04:00
26425 ORA 7445 [__intel_new_memcpy()+2960] 2014-09-11
11:21:28.188000 +03:00
161116 ORA 600 [kktget2: no updCol]
2015-04-08 15:20:29.230000 +03:00

As shown in Listing 4-16, adrci can list all the incidents encountered in the database with their timestamp and
problem key information. There are many more things that can be done using adrci such as going into the details
of these incidents, creating packages from them, and so on, but the bottom line is that it brings you efficiency and
it definitely should be used in diagnosing database problems because it saves you time in navigating the database
directories and checking the trace files one by one manually in the OS terminals using a text editor.
So, you have seen the database tier log files and the diagnostic directories, log files, and methods for
analyzing these log files used in an EBS 12.2 database environment. Now let’s take a look at the database tier
log files produced for applications DBA utilities and scripts.
The applications DBA utilities and scripts are the scripts and utilities delivered with the appsutil
directory, which resides in the database tier Oracle Home. There are database stop/start scripts, listener
stop/start scripts, AutoConfig scripts, cloning scripts, and several others. Most of these scripts and utilities
create log files, and unlike Oracle Database itself, which has a diagnostic repository consisting of several
directories, the log files created by application DBA scripts and utilities are placed in a single directory called
log that resides in the appsutil directory.
Although most of the application scripts write the information for their log file paths to the terminal
from where they are executed, Listing 4-17 shows a tree command output that lists the log directory located
in the $ORACLE_HOME/appsutil directory.

Listing 4-17. tree Command Output Showing the Log Directories and Files Located in the $ORACLE_
HOME/appsutil/log Directory
tree –A $ORACLE_HOME/appsutil/log

log
|-- CloneContext_0115002604.log
|-- CloneContext_0115012653.log
|-- TEST_somehost/
|-- |-- 08261526
|-- |-- |-- adconfig.log
|-- |-- |-- adcvmlog.xml.08260827
|-- |-- |-- NetServiceHandler.log
|-- |-- adcrdb_TEST.txt

197
CHAPTER 4 ■ ORACLE E-BUSINESS SUITE 12.2 FILE SYSTEM

|-- |-- adcrobj.txt

|-- |-- adcvmlog.xml
|-- |-- addbprf.txt
|-- |-- addbupdgsm.txt
|-- |-- addlnctl_tmp.txt
|-- |-- addlnctl.txt
|-- |-- adupdlib.txt
|-- |-- afdbprf.txt
|-- |-- ApplyDBTier_06250438.log
|-- |-- make_06250440.log
|-- |-- NetServiceHandler.log
|-- |-- ohclone.log
|-- |-- StageDBTier_08311120.log

As shown in the output displayed in Listing 4-17, the log files are named with the name of the scripts and
the name of the utilities that they are produced for. In this manner, it is easy to understand that addlnctl.txt is
the log file for the addlnctl.sh script used for controlling the database listener. There are also some directories
named with the format <sid>_<hostname> and located in the $ORACLE_HOME/appsutil/log directory. These
directories are for storing log files such as adconfig.log, which is the log file produced by the AutoConfig script.
The other log files located in $ORACLE_HOME/appsutil/log are named with the scripts and utilities
they are produced for. The log file named make_06250440.log shown in Listing 4-17, for example, is the log
file for produced for a Linux make command that is executed probably by a script located in appsutil.
So, most of the time navigating the $ORACLE_HOME/appsutil/log directory is enough for locating the
log files of application DBA scripts and tools, as the log files are mostly named according to the script and tool
names. However, there are also some log files in the appsutil/log directory named with some strings that don’t
give you any clues about the tool or script they are produced for. StageDBTier_08311120.log, shown in Listing
4-17, is one of them, and it is produced for a preclone activity, but by looking its name, you can’t predict that.
So, whether the log file name gives you a clue or not, it is not so important to memorize which file in
the appsutil/log directory to look for when an error is encountered in an applications DBA script or utility.
That’s because, as already mentioned, most of the applications DBA scripts and utilities report their log file
location when they are executed.
Listing 4-18 shows an example AutoConfig run. By looking at the output of AutoConfig script, you can
see that the AutoConfig script reports its log file location just after it starts its execution.

Listing 4-18. AutoConfig Script Reporting Its Log File

[oracle@somehost TEST_somehost]$ sh adautocfg.sh
Enter the APPS user password:
The log file for this session is located at: /u01/install/TEST/11.2.0/appsutil/log/TEST_
somehost/08311817/adconfig.log

Summary
In this chapter, you learned about the file system architecture of EBS 12.2, as well as the environment variables
used to describe the directories and used to get the EBS-specific values while working in the OS terminals. We
explained how to work with the environment variables by giving specific examples, and we explained the log
files by going into the details and giving some examples . You looked at the EBS file system and related topics
such as environment variables and log files, from both the application and the database perspectives.
In the next chapter, you will continue with Oracle E-Business Suite patching concepts, which are almost
completely changed in EBS 12.2.

198
CHAPTER 5

Patching Concepts

In this chapter, we will explain patching concepts in EBS 12.2. We will provide the information about the
components and utilities used in patching and shed light on the logic behind the patching methods. In
addition, we will cover the usages and roles of the dual file system and edition-based redefinition in EBS 12.2
patching. Further, we will introduce the new patching cycle concept in EBS 12.2 as well as the patch phases
used in the online patching concept and explain best practices for EBS 12.2 patching. Both application tier
and database tier patching will be covered in this chapter.

Introduction to Oracle Patching in EBS 12.2

Patching in Oracle E-Business Suite is an inescapable activity because bug fixes and enhancements are
published by Oracle every day. Patching is required in critical projects such as an EBS release or Family Pack
upgrades. Patches can be related to any component present in an E-Business Suite system, and as a matter
of fact, the tools and the methods used for patching differ according to the type of patches.
Although you have different kind of patches in an EBS patching context such as applications patches,
database tier patches, WebLogic patches, and application tier Oracle Home patches, the most common
patching work is done for the applications patches. In other words, except the big upgrades, the things that
usually need patching are the applications.
For example, a form failing to deliver expected contents or an OAF page working slow will require
patching most of the time. It is less necessary to apply patches in the application technology stack and
database tier once EBS is deployed with its latest Family Packs. This is a result of EBS being a packaged
application. So, as EBS 12.2 uses stable versions of the technology stack components, most of the patching
activity is done for the EBS code changes.
Before EBS version 12.2, the approaches used in patching were similar. Versions 11i and 12 (12.0 and 12.1)
were similar in their patching concepts. In these releases, when a patch needed to be applied to the
application tier, you stopped the application services, enabled the maintenance mode, and applied the
required patch with the relevant tool. If the patch could be applied while the application services were
running, you applied it as a hotpatch without needing to stop any services, but this was not a scenario that
was encountered much.
The method for applying database tier and application tier Oracle Home patches was also similar
and straightforward. For database and application tier Oracle Home patches, you used the opatch utility.
Actually, this has not changed with EBS 12.2.
However, patching in the application tier has changed with the release of EBS 12.2. As you may
imagine, this was expected. Because EBS 12.2 has introduced almost a complete new technology stack in the
application tier, the tools for patching and the methods had to be changed.
But this was not the big change in the subject of patching EBS 12.2. The most important change in
EBS 12.2 is the new online patching concept.

© Syed Zaheer and Erman Arslan 2016 199

S. Zaheer and E. Arslan, Practical Oracle E-Business Suite, DOI 10.1007/978-1-4842-1422-0_5
CHAPTER 5 ■ PATCHING CONCEPTS

In 12.1, there was an option named Staged APPL TOP to make the system be available while patching.
But even with Staged APPL TOP, if a patch required changes in the database objects, the system had to be
taken offline.
As the name itself implies, the online patching concept introduced in EBS 12.2 allows the applications
patches, as well as the application tier technology stack patches (WebLogic and application tier Oracle
Home–based components), to be applied online with a near-zero downtime. This online patching feature
applies even for the patches that require some database object changes.
There is still a minimal downtime, but it is only required for restarting application services. There
is also a downtime option, which was first introduced with EBS 12.2.4 (or AD-TXK Delta 5) for applying
patches with downtime. However, to apply a patch with this option, the patch must be compatible with it. In
other words, it should be explicitly documented in the patch readme file or in the relevant Oracle Support
documents. That is, unless the Oracle Support documents or the readme of the patch declare something like
“This patch can be applied using apply_mode=downtime,” you must use online patching.
Patching with downtime should be preferred only where the downtime is not an issue and there
is a need to increase the patching speed. Patching with downtime is used in operations such as Fresh
installations, upgrades, and some specific product upgrades at the moment. It is not something that should
be used frequently, and this makes online patching the main way to apply patches in EBS 12.2.
To able to create an EBS environment with the online patching feature, Oracle has used its own
technologies. EBS 12.2 employs edition-based redefinition (EBR), a feature of Oracle Database 11g R2 and
12c (12c R1) in the database tier, and a dual file system in the application tier to support online patching.
In addition to these new technologies, the patching utility and the patching concepts have also been
changed according to the online patching methodology. EBS 12.2 brings a new patching utility for applying
the application tier patches called adop (which stands for “applications DBA online patching”), which
replaces the adpatch utility used in EBS 12.1 and 11i. Although adop seems like a wrapper for executing
adpatch in the back end, it is far more than that.
It is the tool that drives the online patching cycle and affects both the database tier EBR and the dual file
system because it makes them become involved in the patching process. In addition to the adop utility, the
new patch cycle concept is at the top of this online patching stack. Every time a patch needs to be applied,
a patch cycle is created. Patching cycles in EBS 12.2 consist of five main phases: prepare, apply, finalize,
cutover, and cleanup.
So, adop, the dual file system, EBR, and the patching cycle and phases together supply the online
patching used in applying EBS 12.2 application patches. We will explain these terms and the adop utility
itself in detail in the coming sections. Also, we will walk you through the online patching process in
conjunction with the dual file system explained in Chapter 4.
The method used in patching the database tier is the same as the old releases. As you may imagine, the
opatch utility is used for database tier patching in EBS 12.2. The tool opatch is also used in the application
tier Oracle Home patches in EBS 12.2.
Using opatch is a familiar approach for core DBAs and former apps DBAs. However, there are also new
utilities like BSU for patching the new EBS application tier components such as WebLogic. These utilities will
be covered later in this chapter, while we explain the different patching utilities.
So, although patching seems to consist of downloading the required patches from Oracle Support,
uploading them to the server, and using the utilities to apply them, the technology and the infrastructure
behind them are highly complex. In addition to the complex patching infrastructure consisting of utilities
and a bunch of technologies supporting them introduced in the previous paragraphs, patching EBS is not a
straightforward operation every time.
Downloading the patches from Oracle Support is certainly the first and easiest step in a patching
operation. The only point to be considered while downloading a patch is that you must download the
patches according to the platform and release level of the corresponding environment. Choosing the correct
patch that will fix the related problem is also important here.
After choosing and downloading the patches, the second step is placing the patches in the
corresponding directory and configuring their ownerships. This is also easy.

200
CHAPTER 5 ■ PATCHING CONCEPTS

However, the action begins after this point. Once the patches are in place, you need to choose the
correct patching order and proceed with applying them. You can apply patches one by one or merge them
into a single patch and apply all the patches in one go. Even if the order and action plan are correct, there
may be other issues while patching, so you need to know the whole patching process, the architecture
behind it, and the tools used in patching.
Let’s start by identifying how and why these patches in EBS are created by Oracle and how to decide on
the patching order in general.

Types of the Patches and Deciding the Patching Order

Patches for EBS are created by Oracle as bug fixes or as enhancements. A patch may address a single issue or
multiple issues and enhancements.
The story behind the patch creation is based on Oracle Support service requests. A customer or an
Oracle Support analyst opens a service request to report his or her findings. If there are no patches available
or if the reported problem is not an expected behavior, the problem is logged as a bug and transferred to
the development team at Oracle. The development team makes its research and creates a new patch for the
reported bug. Afterward, the patch becomes available for all the required Oracle applications, platforms, and
all the required languages, and the patch become ready to be released for the customer use.
There are six main patch types present for EBS products: one-off patches, Recommended Patch
Collection (RPC) patches, Mini Packs, Family Packs, Release Update Packs, and Maintenance Packs. One-
off patches are usually the smallest patches, and they are created to fix specific issues. Recommend Patch
Collection patches are used for applying multiple recommended one-off patches in one go. RPC patches
combine the latest recommended patches with all their prerequisite patches for the EBS products.
Mini Packs are created by assembling multiple one-off patches and can be considered cumulative
bug fixes and enhancements related to a specific EBS product. Family Packs are collections of Mini Packs
to provide cumulative bug fixes and enhancements for a group of EBS products. The grouping of products
is based on the product family. For example, a Family Pack for financials has fixes and enhancements for
the products such as AR, AP, GL, and FA, as these products constitute the financials family. Release Update
Packs are a collection of Family Packs that are created for a given codeline after the initial EBS release. For
example, upgrading from 12.1.1 to 12.1.2 is done by applying 12.1.2 Release Update Pack.
Maintenance Packs are the collection of Family Packs to be used for the release upgrades. For example,
a release upgrade from 12.0 to 12.1.1 is done by applying the 12.1.1 Maintenance Pack.
In addition to the EBS product patches, there are patches for the technology components that come
bundled with EBS. The application tier technology components such as WebLogic, FMW, and Oracle
10.1.2.3 Home and Oracle Database are the components in this category, and they have their own patching
needs, terminology, and methods. For these components, the nomenclature is as follows:
• Interim patch: This is the same as the one-off patch explained earlier. These patches
contain one or more fixes.
• Diagnostic patch: This is an interim patch that does not fix any problems but is used
to diagnose a specific problem.
• Bundle patch: This is a cumulative patch for the corresponding product. These
patches include fixes and sometimes some minor enhancements.
• Patchset update (PSU): This is a quarterly patch that contains the most critical fixes.
• Security patch update (SPU): This is a cumulative patch that contains the security
fixes for the corresponding product.

201
CHAPTER 5 ■ PATCHING CONCEPTS

As explained in Chapter 2, EBS 12.2.0, which is installed as the base release, is not supported by Oracle.
So, EBS 12.2.0 must be upgraded to the latest release immediately after the installation, as we covered in
Chapter 2. Thus, within the installation (actually just before the upgrade), the technological components
become stable as there are many prerequisite patches for these components to be applied in order to
upgrade EBS to the latest release, which is 12.2.5 currently.
However, patching these components is still required. Sometimes because of a bug, sometimes because
of security vulnerability, and sometimes just because of the need to adapt the support policies, these
components require patching.
As long as there is time to wait until the next patchset to get a fix, applying PSU and SPU patches is
enough for the technological components in EBS. As we have mentioned about the adop utility for applying
application product patches, technology components have their own tools to be used in patching.
To apply a patch to Oracle Database, Oracle 10.1.2.3 Home, the FMW web tier, or oracle_common, you
use the tool opatch. This is a well-known utility in the Oracle world, and core DBAs are quite familiar with it.
However, to be able to apply a patch the WebLogic Server environment, you must use the BSU utility.
Although there is a detailed information regarding the installation instructions present in the readme
files residing in the patches, we will explain these utilities in detail in the next section, “Different Patching
Utilities Under Oracle EBS 12.2.”
Deciding on the patching order is as important as applying the patches. The key to deciding the order
of patches is identifying whether any prerequisite patches are required to be applied before the patch that
you want applied. If there are prerequisite patches for the desired patch, another check should be done to
identify whether those prerequisite patches require other prerequisite patches to be applied before applying
them. This process of identifying goes on until all the prerequisites are identified. It seems tough, but
normally it does not take so much time. There are some scenarios such as upgrading ATG family products
that require a lot of prerequisite patches to be applied, but these kinds of operations are rare. So, most of the
time, one patch requires one or two prerequisites and that’s it. In addition, if the required prerequisite patch
is already applied to your system, normally there is no need to apply it again.
However, there are situations where a single patch requires several prerequisite patches. These
situations are most likely caused by not keeping the EBS system up-to-date with patching. That is, if the
system is not patched often, then the most of the recent bug fixes will be missing, and when a problem that
requires a patch to be applied as a fix arises, the prerequisites of that patch will most likely be required to
be applied. Moreover, if there are several prerequisites for that patch, this will increase the patching time
and also increase the testing effort because there will be more things to test after applying several patches.
In this context, we recommend you keep the EBS system up-to-date by applying the latest Mini Packs and
recommended patch collections, as long as the business has the ability to give you the required approval for
these maintenance operations and the resources for testing them.
There are two methods that can be used to check the prerequisites and decide the patching order.
The first one is the manual method, which is the preferred method of the two. It is preferred because
of old habits. That is, apps DBAs have administrated the EBS environment since version 11i, and they
are accustomed to these methods. The second method is using the Patch Application Assistant (admsi.
pl), which is a tool/Perl script for generating the customized installation instructions according to the
environment. With Release 12.2, using admsi.pl for determining patching actions has started to become
widespread. As a result, even the readme files of the latest patches in EBS 12.2 redirect to admsi.pl for
determining the prerequisite actions and patches. In the readme files of these patches, the redirection is
made by the statement “run the Patch Application Assistant by entering admsi.pl.”
Almost every application patch in 12.2 uses admsi.pl, but for some patches like patches technology
stack components, there is still a requirement to read and follow the readme files for the prerequisite actions
and installation instructions.

202
CHAPTER 5 ■ PATCHING CONCEPTS

In addition, unfortunately there are some EBS 12.1 patches that can be applied on EBS 12.2 systems. To
apply these kinds of patches or determine whether they can be applied to EBS 12.2, you need to follow their
readme files carefully. These patches may contain a statement like “For 12.2.X patches (using adop), you can
perform the tasks in this section without shutting down the Application tier services,” which proves that they
can be applied to EBS 12.2 systems.
Therefore, because of these important causes, it is good to know both of these methods and read the
readme files carefully even if the patch in question is admsi.pl-compatible.
Let’s start with the manual method.

The Manual Method

In the manual method, you connect to Oracle Support and check the readme file of the patch you want to
apply. In the readme file, there is a section named “Prerequisites” that lists the prerequisite actions and the
prerequisites patches, if there any.
To give you an example of this method, let’s walk through the Fusion Middleware patch 17555224:
OHSTLS 1.2 WITH CLIENT CERTIFICATE AUTHENTICATION, which is an example for a patch that requires
the readme file to be followed.
As shown in Figure 5-1, you connect to My Oracle Support using the URL https://support.oracle.com.

Figure 5-1. My Oracle Support web page

203
CHAPTER 5 ■ PATCHING CONCEPTS

Click the Sign In button and supply your credentials on the login page shown in Figure 5-2. The account
name you are using to log in to My Oracle Support needs to have at least one valid customer support identification
(CSI) associated with it. (The CSI is provided by Oracle when purchasing license and support services.)

Figure 5-2. My Oracle Support login page

After the login, choose the Patches & Updates tab and search for the patch or patches you want to apply.
On this tab, you have different options for searching such as searching by patch name or by number or
using the advanced search for searching by product or family.
You even have an option to use the Recommended Patch Advisor, which is an option for listing the
required patches according your product, release, and platform selections. As for the example shown in
Figure 5-3, we searched for patch 17555224.

204
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-3. My Oracle Patches & Updates tab

When the search finishes, you will the list of patches with this number, as depicted in Figure 5-4.

Figure 5-4. My Oracle Support patch search page

205
CHAPTER 5 ■ PATCHING CONCEPTS

Note that My Oracle Support (MOS) lists all the patches with the number you entered for the search
criteria; here we have chosen the correct patch for your environment by considering the values listed in
release and platform columns.
So, if your current FMW version in the EBS instance is 11.1.6.0 and your application server platform is
HP-UX Itanium, you need to choose the line that has 11.1.6.0 in the release column and HP-UX Itanium in
the Platform column from the list.
The patch in this example is an FMW patch, which naturally has only one language version, which is
the default EBS language, American English. However, some of applications patches may have versions for
other languages too. If that’s the case, the NLS language versions of the desired patch must be applied to the
system. In other words, for every language present in an EBS 12.2 system, the NLS language versions of the
patches must be applied, too.

■ Note If there are NLS language versions of the desired patches, they must be applied after the generic or
American English versions of that patches.

Let’s continue with our example. Once you choose the appropriate patch for your platform and release,
you click it and My Oracle Support redirects you to the general information page, as depicted in Figure 5-5,
where you can see options such as downloading the patch itself, see the bugs resolved by that patch, and see
the readme file of it.

Figure 5-5. My Oracle Support patch information page

206
CHAPTER 5 ■ PATCHING CONCEPTS

Click the Read Me button, and My Oracle Support opens the readme file of that patch in a new browser
tab, as shown in Figure 5-6.

Figure 5-6. My Oracle Support patch readme file

As you can see, you have several sections in a patch readme. The section names and counts change
according to the type, platform, effect, and importance of the patches. But generally, the format in the
readme file is like the format displayed in Figure 5-6.
Once the readme file is opened, check the prerequisites first. You take the actions specified in
the “Prerequisites” section and continue with the pre-installation, installation, and post-installation
instructions. Note that there are de-installation instructions for some of the patches, as well. These
instructions may be followed if a patch must be uninstalled because of errors while applying it or because
some side effects were discovered after applying it.

207
CHAPTER 5 ■ PATCHING CONCEPTS

So, the previous example shows determining the prerequisites and patching order of a single patch,
which is dependent on some prerequisite patches. Naturally the patch order for this patch is to apply
prerequisite patches and then to apply the actual patch.
But there can be some cases, especially in applying Oracle applications patches, where you have to
apply several prerequisite patches that have several prerequisites as well. If that is the case, you should make
a list, and by performing a cross-patch analysis, you must apply the prerequisite patches first. You can merge
and apply several prerequisite patches in one go; this approach, which will be explained in Chapter 6, makes
the patching easier and faster.
One more thing that makes your job easy is that, nowadays, Oracle Support supplies documents for
big patches. Patches like latest AD and TXK Release Updates are documented through their separate Oracle
Support documents, which list the prerequisites for them and even the post actions related to them. So, for
these kinds of big and important patches, Oracle does these analyses for you and releases them in Oracle
Support documents, which makes your lives easier.
Figure 5-7 shows an example of this kind of documentation from Oracle. It is used for upgrading the AD
and TXK product releases to their latest versions. It is detailed, and the patching order is present in it.

Figure 5-7. Documentation applying the latest AD and TXT release update packs

Actually, the update packs AD and TXK Delta 7 were just released, so the latest release for these update
packs can be considered as Delta 7. However, the versions of these update packs do not change the approach.
Also, the document to be followed (1617461.1) does not change either, because the document 1617461.1 is
updated frequently so that it always points to the AD and TXK update pack patches for the latest release.

208
CHAPTER 5 ■ PATCHING CONCEPTS

We mentioned the patches that redirect you to admsi.pl for determining the prerequisite and
installation instructions; AD.C.Delta.6 is one of those patches, as shown in the example screen in Figure 5-8.

Figure 5-8. My Oracle Support patch general information page for the AD.C.Delta.6 patch

When you open the readme file of these kinds of patches, you see instructions that say the following:
1. Source the Applications environment file.
2. Run the Patch Application Assistant by entering “admsi.pl”
The example readme file shown in Figure 5-9 is for patch 19197270, and as shown, the instructions for
applying the patch and preparation tasks are clearly specified.

209
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-9. My Oracle Support readme file for patch 19197270 (AD.C.Delta.6)

The Patch Application Assistant Method

At this point, you can use the Patch Application Assistant (admsi.pl), which is the second method for
determining the prerequisite actions, patching order, and instructions required by the patch that you want
to apply.
We’ll explain how to use the admsi.pl utility with an example. To able to use the Oracle Patch
Application Assistant, an X Desktop Viewer such as Vncserver must be used, and the desired patches must
be placed in the application file system. So, after downloading the patch zip files, you need to be transferred
to a location in the application server with the file ownerships set to application OS user.
In this example, create a folder named ADCDELTA6 in the home directory of the application OS user
and unzip the patch there.

[applmgr@somenode ~]$ pwd

[applmgr@somenode ~]$ /home/applmgr
[applmgr@somenode ~]$ mkdir ADCDELTA6
--we transfer the patch zip file in to the newly created folder, ADCDELTA6 using our
favorite file transfer utility such as Winscp.
[applmgr@somenode ~]$ cd ADCDELTA6
[applmgr@somenode ADCDELTA6]$
[applmgr@somenode ADCDELTA6]$ ls
p19197270_R12.AD.C_R12_LINUX.zip
--once we upload the patch zip file, we use unzip utility for extracting the patch contents.

210
CHAPTER 5 ■ PATCHING CONCEPTS

[applmgr@somenode ADCDELTA6]$ unzip p19197270_R12.AD.C_R12_LINUX.zip

[applmgr@somenode ADCDELTA6]$ls
19197270 p19197270_R12.AD.C_R12_LINUX.zip

By the way, not all the patches contain the same directories and files, but an application patch typically
contains the following files:
README.txt and README.html files: These include the instructions and
prerequisite actions required by the corresponding patch. README.txt is in text
format, and README.html is in HTML format.
Unified driver file: This is a driver file named with the <patch_name>.drv
format, which is used by the patching utility to perform actions such as copying,
generating the application objects, and taking database-related actions.
Patch metadata files: These are ldt files in b.<patch-number>.ldt and f.<patch-
number>.ldt naming formats. These files are used by the patching utilities
for determining prerequisite patches, analyzing the impact of the patch, and
comparing the file versions of patch with the file versions present in the system.
The replacement files: These files are usually in the folders named with the related
product names such as ad, ar, ap, and so on, and these are the actual files used by
the patching utility through the unified driver to replace the files the objects such
as SQL, forms, reports, and HTML files with their patched versions.
patch_metadata.xml file: This contains the metadata information about
the patch to be applied. admsi.pl reads this file and populates its screens
accordingly.
Java files: These are the Java files delivered by the patch. These files are in zip
format with names like j<patch_number>_<related_product_short_name>.zip,
and they contain Java files such as Java classes.
marker1.txt: This contains the name of the patch zip file.
JRIMETA.dat: This file is an encrypted binary file located in the META-INF
directory. The patching utility reads this file to compare the version of the Java
class present in the system with the Java class file delivered with the patch to
determine whether the update of the relevant Java class is required.
You’ve now seen the contents of an application patch, so let’s continue with the example. When you
unzip the patch zip file, the unzip utility will create a folder named with the patch number and extract the
content of the zip files into it.
Just after unzipping the downloaded patch file and sourcing the EBS environment file, you run Oracle Patch
Application Assistant by executing admsi.pl using the applications operating system user (usually applmgr).

[applmgr@daroratestappsrv1 ~]$ . /u01/install/APPS/EBSapps.env run

[applmgr@daroratestappsrv1 ~]$ admsi.pl

211
CHAPTER 5 ■ PATCHING CONCEPTS

Once the Oracle Patch Application Assistant is executed, it opens an initial screen with two options
(viewing instance-specific or generic instructions for a new patch) and lists the incomplete tasks remaining
from the previous patches, as shown in Figure 5-10.

Figure 5-10. Oracle Patch Application Assistant initial screen

212
CHAPTER 5 ■ PATCHING CONCEPTS

At this point, you choose “View instance specific instructions for a new patch” and specify the apps
password and the location of the patch that you unzipped earlier, as shown in Figure 5-11.

Figure 5-11. Oracle Patch Application Assistant : viewing instance-specific instructions for a patch and
specifying the patch location

213
CHAPTER 5 ■ PATCHING CONCEPTS

After filling in the APPS Password text box and choosing the location of the patch, click Next, as depicted
in Figure 5-12.

Figure 5-12. Oracle Patch Application Assistant, viewing instance-specific instructions for patch 19197270
and specifying the apps schema name, password, and patch location

214
CHAPTER 5 ■ PATCHING CONCEPTS

On the next screen (see Figure 5-13), the Oracle Applications Patch Assistant lists the prerequisite
actions and installation instructions with the subtitles Preparation Tasks and Apply the Patch.

Figure 5-13. Oracle Patch Application Assistant, summary of installation instructions for patch 19197270

215
CHAPTER 5 ■ PATCHING CONCEPTS

When a subtitle is expanded, the instructions specific to the environment can be displayed, as shown in
Figure 5-14 and Figure 5-15.

Figure 5-14. Oracle Patch Application Assistant, summary of installation instructions for patch 19197270,
continued

216
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-15. Oracle Patch Application Assistant, summary of installation instructions for patch
19197270, continued

So, the instructions displayed on this screen are the main function of the Oracle Patch Application
Assistant. With this view, the Oracle Patch Application Assistant generates a detailed and clearly explained
instruction list, which contains the manual steps for applying a patch in an EBS 12.2 environment. Additional
steps may also be detailed depending on the patch, the state of the system, and the products installed.
When you click Next, the instructions come one by one. Once you complete an instruction, you have the
opportunity to click the Completed check box and save your work, as shown in Figure 5-16.

217
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-16. Oracle Patch Application Assistant, completing the preparation tasks
In addition, the Oracle Patch Application Assistant provides a summary screen, as shown in Figure 5-17, to
display the actions that have been done so far or that remain for a patch to become properly applied to the system.

Figure 5-17. Oracle Patch Application Assistant, checking the completion of the installation instructions

218
CHAPTER 5 ■ PATCHING CONCEPTS

The Summary of the Installation Instructions screen is the last screen of the Oracle Patch Application
Assistant, where you can save the work for a patch in the database and later continue following the patching
instructions for that patch from where the assistant left off.
Figure 5-18 shows the summary screen for patch 19197270 where the preparation task of the patch is
finished and the current state of the work for this patch is saved.

Figure 5-18. Oracle Patch Application Assistant, saving the work

As shown in Figure 5-18, the Oracle Patch Application Assistant is really like an assistant who helps both
identify the custom actions required by patches and track the work done during the patch applications. So,
we and Oracle strongly suggest using this utility for EBS 12.2 patching activities, as recommended in the
readme files of EBS 12.2 patches.
Even so, the best approach for determining the instructions needed for patching and deciding on the
patching order is using the Oracle Patch Application Assistant in conjunction with reading the readme
files of the patches. This is because there are some patches that aren’t compatible with the Oracle Patch
Application Assistant or using it is not explicitly defined in their readme files. In addition, there may be some
important instructions in the readme files of those patches.
The bottom line is that it is important to deal with patching as a whole as it takes more than only using
the relevant patching utility to apply an EBS patch properly. Things like determining the required patch,
the correct patching order of the actions, and the instructions are the most important parts of the patching
activities in EBS 12.2. In other words, these duties constitute 50 percent of the actual patching work, but still
there is other important work for applying a patch properly to an EBS 12.2 system. This remaining 50 percent
is applying patches using related utilities.
There are different kinds of utilities for different kinds of patches in EBS 12.2. Let’s continue with the
next section and start getting to know them.

219
CHAPTER 5 ■ PATCHING CONCEPTS

Different Patching Utilities Under Oracle EBS 12.2

As EBS 12.2 is comprised by a bunch of different technological components, patching methods, and utilities
for patching, the method of patching differs from one component to other.
These are the components in the technology stack of an EBS 12.2 instance: EBS 12.2 employs Oracle
Database (Oracle RDMBS) as the database tier, Oracle Application Server (Oracle AS) for serving the forms
and reports services, the Oracle Fusion Middleware architecture by providing WebLogic Server and Oracle
HTTP Server also known as the web tier, and an Oracle Common Home (which is an Oracle Home for
storing and serving the common modules).
With this classification, this makes four different technologies, and if you add the applications/EBS
products as technologies to these four kinds of technologies, you have five different technologies and may
expect five different tools and methods to be used for patching.
Luckily, this is not the case. There are three different kinds of patching utilities and methods for
patching these components. This is because some of the components are based on the same technologies.
That is, the patching method and the utility used for patching Oracle HTTP Server (OHS), Fusion
Middleware Common, Oracle Forms and Reports 10.1.2 Home, and Oracle Database are identical, as these
technologies and their structures are based on the component called Oracle Home, which is a file system
architecture generally used for storing Oracle Database software in the file system.
WebLogic and the application products, on the other hand, have their own patching utilities and
methods because they are completely different from an Oracle Home.
Table 5-1, which classifies the components according to their patching utilities and installation
methods, shows the installation methods used for patching these components.

Table 5-1. Components, Patching Utilities, and Installation Methods

Component Patch Utility Patch Installation Method

• WebLogic Server BSU 1. Review the patch readme.
2. Use cd $FMW_HOME/utils/bsu.
3. Follow the readme instructions, for example,
by running the command $ bsu.sh.
• OHS (web tier) opatch 1. Review the patch readme.
• Oracle Common 2. Set ORACLE_HOME.
• Oracle Forms and Reports 3. Include $ORACLE_HOME/OPatch in the PATH.
10.1.2 Home 4. Change the directory to the patch directory.
• Database (Oracle RDBMS) 5. Follow the readme instructions.
• Oracle applications/product adop 1. Review the patch readme.
patches 2. Source the application environment file (run edition env).
3. Prepare the system for patching (adop
phase=prepare); this must be done before applying a
patch if a patching cycle is not present.
4. Apply the patch (adop phase=apply).
5. Complete the patching cycle (adop phase=finalize,
adop phase=cutover and adop phase=cleanup).
6. Synchronize the file systems (adop phase=fs_clone),
which is optional.

220
CHAPTER 5 ■ PATCHING CONCEPTS

As shown in the previous table, the components can be categorized into three categories according to
the patching utilities and the patching methods.

Patching WebLogic with BSU (BEA Smart Update)

WebLogic patches are applied online by following the online patching process of EBS 12.2, which we will
explain in detail in the next section. To apply a patch to WebLogic Server inside an EBS 12.2 system, you
basically create an online patching cycle, source the patch edition, and use BSU utility, which is also known
as Smart Update. Actually, we prefer to call this utility BEA Smart Update, because the letter B in BSU stands
for the company BEA, which Oracle acquired in 2008. BEA was the owner of WebLogic Server, before it was
acquired by Oracle.
To patch the WebLogic instance, you normally start by downloading the required patches from Oracle
Support and placing them in the application server or servers where your WebLogic instance resides. Once
the patches are downloaded and unzipped in the $FMW_HOME/utils/bsu/cache/dir location in the patch
file system, BSU can be run from the $FMW_HOME/utils/bsu directory as follows:
1. With the application OS user (for example, applmgr), open a VNC server
connection.
2. Create an online patching cycle and set the patch edition environment using the
EBSapps.env script using the command . EBSapps.env patch. Alternatively, the
utility can be run from the run edition environment, if the purpose of running it
is just to control the WebLogic patching information (for example, checking the
applied patches).
• cd /u01/install/APPS
• . EBSapps.env run
• adop phase=prepare
• . EBSapps.env patch
3. Change the directory where the bsu.sh resides using a command like cd $FMW_
HOME/utils/bsu.
4. Execute the bsu script using the command . /bsu.sh.
Once the BSU utility starts, it will list the patches present in the cache directory where you have
unzipped them. BSU makes patching easier because it provides you with the opportunity to apply the
desired patch or patches by just clicking a button. Figure 5-19 shows an example of the BSU initial screen.

221
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-19. BSU utility

As an alternative for the interactive BSU screen, you can apply the WebLogic patches using terminal
screens in noninteractive mode using the following command format:

bsu.sh \
-prod_dir=<path>/FMW_Home/wlserver_10.3 \
-patchlist=<patchID>
-verbose –install

After installing the WebLogic patches, you proceed with the adop finalize, cutover, and cleanup phases
to complete the online patching cycle as follows:
• adop phase=finalize
• adop phase=cutover
• adop phase=cleanup
So, the approach for patching WebLogic in EBS 12.2 is pretty straightforward because it is based on the
standard WebLogic patching tool BSU, which can be executed easily from the command line and which also
has a user-friendly graphical user interface.

222
CHAPTER 5 ■ PATCHING CONCEPTS

Patching the Application Tier Oracle Homes and the

Database with Opatch
The required actions for patching the technology stack components such as Oracle Forms and Reports
Home, Oracle HTTP Server (web tier), and Oracle Common are pretty straightforward, too. These
components can be classified as application tier Oracle Home–based components, and the utility used for
patching them is opatch, which is an Oracle-supplied tool well-known by core database administrators. Like
with WebLogic inside EBS 12.2, these components are patched online.
The required patching actions for the Oracle Database component is similar to the technology stack
components. The only difference is you create any online patching cycle before patching the database, as the
database patches are not handled with the online patching feature of EBS 12.2.
To patch a technology stack component with opatch, you need to create an online patching cycle, set
the patch edition environment, set the Oracle Home to the Base directory (ORACLE_HOME directory)
of the component, set the PATH for its terminal session to include the Opatch directory present in the
corresponding ORACLE_HOME directory, change the current working directory to the directory where the
patch is unzipped, and issue an opatch apply command from there. Lastly, once the patch application is
finished, you need to complete the patching cycle to complete the patching process.
In this context, follow these steps:
1. To patch OHS (web tier), Forms and Reports Home, and Oracle Common Home,
follow these steps:

• Connect to the application server using the application OS user, create an

online patching cycle, set the patch environment using the EBSapps.env script
located in the Base EBS apps tier directory, set the ORACLE_HOME and PATH
environment variables accordingly, and execute the opatch apply command.
Here’s an example:

cd /u01/install/APPS
. EBSapps.env run
adop phase=prepare
. EBSapps.env patch

2. For patching the web tier, the required environment settings are as follows:

export ORACLE_HOME= $FMW_HOME/webtier/

export PATH=$ORACLE_HOME/OPatch: $PATH

3. For patching Oracle Common, the required environment settings are as follows:

export ORACLE_HOME=$FMW_HOME/oracle_common/
export PATH=$ORACLE_HOME/OPatch:$PATH

4. For patching Forms and Reports 10.1.2 Oracle Home, the required environment
settings are as follows:

export PATH=$ORACLE_HOME/OPatch: $PATH

Note that you don’t need to set ORACLE_HOME for 10.1.2 Home patches, as it is the default Oracle
Home sourced by the EBSapps.env environment file.

223
CHAPTER 5 ■ PATCHING CONCEPTS

After setting the environment, you change your directory to the directory where you unzipped the patch
and execute opatch for applying the patch or patches to the patch edition from there.
• cd /patch_dir
• opatch apply
After applying the patch or patches using the opatch apply command, you proceed with the adop
finalize, cutover, and cleanup phases to complete the patching cycle.
• adop phase=finalize
• adop phase=cutover
• adop phase=cleanup
Note that we have given opatch apply as the command that should be used to apply Oracle Home
patches using the opatch utility. However, there may be some exceptional situations where you may need
to execute opatch using arguments such as napply or auto. The requirements for using these kinds of
arguments are explicitly stated in the patch readme files or Oracle Support documents, which direct you to
apply the patches.
As mentioned earlier, you don’t create an online patching cycle or set the patch environment before
applying EBS 12.2 database patches (there is no patch environment in the database tier anyway). What you
do for patching the EBS 12.2 database is not different from any other Oracle database. You just source the
database environment and execute Opatch. Following the readme files of the patches is also important,
as most of the database patches require the database to be shut down, and some of the database patches
require manual actions as well.
To patch Oracle Database (RDBMS), follow these steps:
• Connect to the database server using the database OS user, also known as the Oracle
software owner, and set the runtime environment, present in the Oracle Home
of the database. Once the general environment is set, set the PATH environment
variable properly to include the Opatch directory and lastly execute the opatch apply
command.
For patching Oracle Database Home, the required environment settings are as follows:

cd <ORACLE_HOME directory> (For example: /u01/install/PROD/11.2.0)

Source the database environment : . <s_systemname>_<s_hostname>.env
export PATH=$ORACLE_HOME/OPatch: $PATH

• cd /patch_dir
• opatch apply
Just like the application tier component patches, there may be some exceptional situations in the
database tier. That is, for some patches, you may need to execute opatch using arguments like napply or
auto; the requirements for using these kinds of arguments are explicitly stated in the patch readme files or
Oracle Support documents that direct you to apply the patches.
opatch is an easy-to-use utility despite its wide range of capabilities. The utility is based on an inventory
mechanism and may list the patches and bug fixes currently present in the system using the inventory it
maintains. Like BSU, opatch provides an ability to roll back/remove the patches applied without depending
on the time the patches in question are applied. But in contrast with BSU, opatch does not require a
vncserver connection. So, it is a tool that works in the text terminal.

224
CHAPTER 5 ■ PATCHING CONCEPTS

You can use the opatch –help command to display the usage for different options present in opatch.

command := apply
lsinventory
lspatches
napply
nrollback
rollback
query
version
prereq
util
...

It is important to know that the patches may have pre-installation and post-installation instructions,
too. As explained in the introduction of this chapter, patching is not all about executing the appropriate tool
for the component to be patched.
An example of this is a database patch, which may require a SQL script to be executed with a database
user who has SYSDBA privileges, as instructed in the readme file. In these cases, you need to apply the
desired patch using the opatch utility and execute the SQL pointed at by the readme file of that patch. This
kind of situations applies to the Forms and Reports, Oracle Common, and OHS patches, too. That’s why we
remind you of the importance of reading the readme files, once again.

Applying the Applications Patches with the ADOP Utility

After explaining the opatch and BSU utilities, we’ll continue with the adop utility, which is the tool for
applying the application product patches.
adop is an acronym for “applications DBA online patching” and was introduced in EBS 12.2. Although adop
internally uses the adpatch utility, which is used for patching in earlier releases, it replaces adpatch in general.
As mentioned earlier, patches for the database and other technological components patches are applied
to the EBS 12.2 systems rarely. That is, once the installation and upgrade to the latest available release of a
new EBS 12.2 are complete, you’ll rarely need to apply technology component and database patches.
But this is not the case for application product patches, as EBS 12.2 is a huge system consisting of
several products, and product codes are at the top level of its technology stack. As a result, application
product patches are the most frequently applied patches in an EBS 12.2 environment during and after the
initial deployment. As stated earlier, these patches are applied using the adop utility.
In EBS 12.2, the application patches are applied online, and as the name of the utility implies, the adop
utility is used for online patching in EBS 12.2.
The instructions for applying a patch with adop are as follows:
1. Log in to the application server using the application OS user (for example, applmgr).
2. Set the environment <EBS_ROOT>/EBSapps.env run.
3. Unzip the patch to the $APPL_TOP_NE/../patch directory pointed at by the
$PATCH_TOP environment variable.
4. Run the Oracle Patch Application Assistant (admsi.pl) and follow the instructions.
225
CHAPTER 5 ■ PATCHING CONCEPTS

5. Run the adop utility.

• adop phase=prepare
• adop phase=apply patches=123456
• adop phase=finalize
• adop phase=cutover
• . <EBS_ROOT>/EBSapps.env run
• adop phase=cleanup
Note that you set the environment again just before the cleanup phase. This is because during the
cutover phase, the current run edition becomes the patch edition, and vice versa. The details of this
operation will be given later in this chapter.
So far, you have seen the different patching utilities used in EBS 12.2. As you can see, the adop utility is
based on a more complex structure than others. It governs the phases, and it is based on the dual file system
and edition-based redefinition feature in the back end.
As mentioned, the application product patches are mostly applied patches in an EBS 12.2 environment,
which makes the adop utility important. To understand this complexity, you have to take a closer look at
the utility, understand the technologies supporting it, and understand its own logic and terms, especially
the phases.

Introduction to Online Patching Utility (adop)

Online patching in EBS 12.2 is a big advancement, and it brings some changes to support this completely
new patching architecture and method for apps DBAs. Using the adop utility is one of the major changes in
EBS 12.2, and it actually drives the online patching architecture supplied by EBS 12.2.
The online patching architecture is provided by Oracle, and it is provided by having a dual file system
consisting of two apps tier file systems named fs1 and fs2 in the application tier and using the edition-based
redefinition feature of RDBMS 11g R2 and 12C in the database tier. Moreover, the new patching methodology
in EBS 12.2 brings five phases: prepare, apply, finalize, cutover, and cleanup. The term patching cycle is
used to describe the new patching process consisting of these five phases. adop is the tool that creates this
patching cycle, advances the phases, and applies the patch files to the system.
We will use all these terms while discussing online patching in EBS 12.2 later in this chapter, and
Chapter 6 is devoted to adop. Right now we’ll introduce the adop utility and explain the method used for
applying application patches in EBS 12.2.
Just like the other patches, to apply an application patch using the adop utility, the patch must be
downloaded from Oracle Support and placed in an appropriate location in the application file system.
Unlike the case with the opatch, there is no need to execute the adop command from the directory where the
patch file resides. You can run adop from any directory as long as the environment is set properly.
Patches can be placed into the $APPL_TOP_NE/../patch directory, which is the default location where
adop looks for patches when invoked, or the patches can be placed in any directory where the application
OS user has the appropriate file permissions.
Note that if the patches are located in a nondefault directory, that directory should be given as an input
to adop. This is accomplished using the patchtop argument, which you will see in Chapter 6.
So, the environment must be set before applying the patches. Setting the environment for adop is only
about setting the application environment. Before trying to apply a patch with adop, you set the environment
with the script EBSapps.env by supplying “Run” as an argument to it. Here’s an example:

EBSapps.env Run

226
CHAPTER 5 ■ PATCHING CONCEPTS

Once your patch is in place (unzipped and the ownerships configured) and the prerequisites mentioned
in the readme file of the patch are met, you start by executing adop phases in the following sequence:
1. adop phase=prepare
2. adop phase=apply

■ Note In addition to the application patches applied using adop, you can apply WebLogic and other
application technology stack component patches at this point before going any further in the patching cycle.

3. adop phase=finalize
4. adop phase=cutover
5. adop phase=cleanup
We will cover the phases in detail in the next section, but here we’ll give you some introductory
information about them. The first phase, which is the prepare phase of adop, is used for preparing the
system for online patching, and it starts a new patch cycle. Continuing with the apply phase, you actually
apply the patch in question. With the finalize phase, you finalize things with actions such as compilations.
Until the time you execute the cutover phase, all the things done by adop can be rolled back, but once
the cutover phase is finished, there is no option for rolling back anymore. At this point, you execute adop
phase=cutover, and the patched files are actually activated. By design, a near-zero downtime occurs. This
downtime is caused by the need to restart application services for making them use the patched files.
In the last phase, which is the cleanup phase, the objects created for the use of online patching are
cleaned up. After the cutover phase is completed, the patch becomes applied, and the patched files and
database objects can be used by the applications.
Besides the phases, adop have several capabilities. It can abort a patching activity/patching cycle, and it
can initiate a file system clone operation, all of which will be covered in Chapter 6.
As the bottom line, the logic used in online patching in EBS 12.2 is to patch the nonactive files and
nonactive database objects without touching any of the active ones and doing a file system and database
edition switch-over, once the patching work finishes. The separation of these activities is done by using the
phases and is driven by the adop utility.
The logic is clear; however, the structure that makes the online patching available is a complex one.
Let’s take a look at the structure by explaining the technologies behind online patching.

Technological Changes for Supporting Online Patching

To provide online patching, EBS 12.2 uses two major technologies. There are two technologies because
there are two major tiers in an EBS environment: the application tier and the database tier. EBS 12.2 uses
an additional file system as a copy/patch file system to build a file system structure for supplying the online
patching requirements in the application tier. As for the database tier, EBS 12.2 uses the edition-based
redefinition feature of Oracle Database to provide the online patching requirements of the database objects.
These two major technologies introduced in EBS 12.2 are tightly integrated, and they are orchestrated
by the new patching utility, adop, as mentioned in the previous section. Using these two technologies,
EBS 12.2 applies the patches into the copy of the production system, does not interfere the production
environment, and thus provides the business continuity even while a patching is being applied. In other
words, patching any module does not cause the entire system to be down.

227
CHAPTER 5 ■ PATCHING CONCEPTS

The phrase “copy of production system” is used for describing a patch file system in the application tier
and a patch edition in the database tier. So, when an application tier code change is required by the patch,
this change is made in the patch file system, and when a database object needs to be changed, the action is
done in the patch edition of the EBS database.
The editioned objects and file system structures are created by the copies of the production objects,
and during an online patching operation, only the objects to be changed by the patches are copied; in other
words, application data is not copied during an EBS 12.2 online patching operation. As mentioned earlier,
the idea behind online patching in EBS 12.2 is to apply the patch to the copy and then to switch the copy to
be the real one, and vice versa.
Switching the copy to be the real one with near-zero downtime requires restarting the application
services, which is automatically done by the adop utility and which creates a downtime measured in
minutes. Although there is downtime in switching the file system and editions, the control of the downtime
is in your hands. That is, you as the apps DBA may complete the online patching operations during office
hours and then execute the cutover phase, which makes the switch, during night time when downtime is
acceptable. Of course, following such a method like applying a patch and waiting for the switch for a long
time has some side effects to the application; we will explain these effects in Chapter 6.
So, let’s explore the dual file system structure in EBS 12.2 so you have a better understanding of online
patching. In EBS 12.2, in addition to the application file system, a secondary file system is used. This
secondary file system, called the patch file system, is a copy of the application’s currently active file system
called the run file system, and it is kept synchronized by the patching tools.
Although the name dual file system implies two file systems, there is another file system, called the
noneditioned file system, present in the EBS 12.2 application tier to support online patching architecture.
Therefore, you actually have three file systems in EBS 12.2: fs1, fs2, and fs_ne (noneditioned). fs1 and fs2 can
switch roles by design. The switching of file systems, which is done by adop in the cutover phase, makes this
happen. That is, in the cutover phase of adop, the run file system becomes the new patch file system, and the
patch file system becomes the new run file system. So, at any one time, fs1 or fs2 can be the run file system or
the patch file system.
Nevertheless, the EBSapps.env script mentioned earlier in this chapter eases your work to determine
and operate on these file systems. If it is executed with the run argument, the EBSapps.env script sets your
environment to point at the run file system, and if it is executed with the patch argument, the EBSapps.env
script sets your environment to point at the patch file system.
The third file system is fs_ne, the noneditioned file system. It contains the types of files that are not
changed during the application patches, such as log files, report outputs, and data import/export files. As the
files in fs_ne are not changed by the patches, they are not synchronized during patching activities.
Figure 5-20 represents the dual file system and the fs_ne file system (noneditioned file system).

228
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-20. Dual file system and noneditioned file system

As shown in Figure 5-20, you have three file systems but one database. The run and patch file systems
are shown as Filesystem 1 and Filesystem 2. They connect to the same database although their roles are
different from each other, and that’s why you see the edition-based redefinition feature in the figure; the
editions created using the edition-based redefinition feature make multiple database editions available for
multiple application tier file systems. Thus, EBR lets EBS have a patch file system that connects to the patch
edition and a run file system that connects to the run edition.
In other words, like adop makes its patching activities on the copies of the application objects, the work
needed for patching the database objects is done on the copies of the corresponding database objects.

Understanding Edition-Based Redefinition Usage in Online Patching

EBR is an isolation mechanism that supplies the online patching of database objects. The editions created
in the EBS database define what you view. That is, EBR allows applications such as EBS 12.2 to use the
application definitions and the changes in different editions inside the Oracle Database.
Thus, there may be two copies of the same database object in a single database, and the patching utility
adop may use the patch editions to make the database changes required by the patches on copies of the
database objects. This brings with it an opportunity to upgrade or patch the database objects online without
interrupting the end users.

229
CHAPTER 5 ■ PATCHING CONCEPTS

To support this, the EBS application runtime code also runs on a database edition, which is called a run
edition, which is always present in an EBS 12.2 database. However, the patching activity for the database
objects is done in the patch edition, which is created and maintained only during the patching activities, in
other words, when there is an active patching cycle.
In addition to the run and patch editions, there may be one or more old editions inside the database.
These old editions arise from the consequences of adop’s cutover phase and are removed when you execute
adop’s cleanup phase.
To sum up, you can say that EBR is a well-known feature introduced with Oracle Database 11g R2. It
isolates the different versions of the same database objects by using editions, and EBS 12.2 uses the EBR
feature inside the database to support online patching.
We’ll now explain how EBS 12.2 uses EBR by walking through the EBR techniques that EBS uses to
support the new online patching feature in the database tier. Basically, you have editioned and noneditioned
objects in an EBS 12.2 database. Editioned objects are the database objects that are compatible with the
EBR, so they can be copied, and these copies can be dedicated to editions. In other words, every edition may
see an editioned object from its own perspective.
Noneditioned objects, however, cannot be copied. They are like traditional objects, so they are visible to
all editions identically.
While package specifications, package bodies, procedures, views, triggers, editioning views, types, and
synonyms can be considered as editionable objects, objects that store data on them such as tables, indexes,
materialized views, and sequences may be considered noneditionable objects. We would like to draw your
attention to the terminology used here. If an object is editonable and if it has been editioned, it is called an
editioned object. Also, if an object has not been editioned, it is called a noneditioned object regardless of
whether it is an editionable object. So, it is important to not to confuse the terms editionable, noneditionable,
editioned, and noneditioned.
For the editionable and supposed to be editioned objects such as procedures, the idea is pretty
straightforward. Online patching creates the patched version of the editionable object in the patch edition
without touching the object that is used by the runtime and then switches the patch edition to be the new
run edition to activate the new version of the object, thus making the EBS applications use the new patched
version instantaneously.
As you may have noticed, EBS 12.2 supplies the online patching feature even though there are
noneditioned objects inside an EBS database. EBS handles these noneditionable objects by using advanced
features of EBR such as editioning views, cross-edition triggers, and editioned data storage in the back end.
In the case of the patching table structure, rather than copying the tables and using the copies for
patching, EBS uses different ways to alter the tables without breaking the online patching methodology. By
using editioning views, the tables in an EBS 12.2 database can be seen in different forms according to the
editions. So, these editioning views are the keys for the structure to support online patching, and that’s why
by design all the code in EBS 12.2 uses these editioning views to access the database tables. Even the custom
codes and third-party product codes must not access EBS 12.2 tables directly; rather, the EBS tables must be
accessed via synonyms defined in the APPS schema.
Any third-party schema, either from third-party products or custom code, must access Oracle
E-Business Suite tables via the synonyms in the APPS schema. Direct access to Oracle E-Business Suite
tables may produce incorrect results.
In this context, when a patch needs to alter a column of a database table, it is actually a new column
with the desired attributes into that database table. As a result, changing a column does not affect the
application because the application continues to see the table the way it was before the new column was
added. This is accomplished by using the editioning views.

■ Note EBS 12.2 can use the old format without any admin intervention, as EBS uses editioning views to
reach the tables.

230
CHAPTER 5 ■ PATCHING CONCEPTS

To support online patching, the application tables in EBS have editioning views in front of them.
These editioning views are named almost identically with their corresponding tables. The only difference
in naming is that editioning views have # characters added as suffixes on their names. For example, the
EBS 12.2 database uses an editioned view named FND_NODES # for reaching the FND_NODES table in an
editioned manner.
The FND_NODES table belongs to the APPLSYS schema, and it stores the node information in an EBS
12.2 environment. When EBS needs to use the FND_NODES table, it uses the APPS schema, and since the
APPS schema has synonyms defined for the application tables and because these synonyms are defined with
the same names as their corresponding tables, FND_NODES is accessed through the synonym.
The important thing here is that the synonyms are not created to directly point to the tables they are
created for. These synonyms in the EBS 12.2 environment actually point to the editioning views, which are
created to reach the underlying table according to the editions. So, in the case of FND_NODES, the synonym
in the APPS schema named FND_NODES points to the editioning view, which is named FND_NODES#. The
FND_NODES# editioning view reaches the FND_NODES table according to the editions.
As the editioning views are used to reach the tables, the session (or let’s say the applications operating
on the tables) sees the tables in the format according to their editions.
To have a better understanding about this, suppose a column is altered during a patch application.
Suppose that the patch changes the column type from number(10) to number(15). In EBS 12.2, to make this
operation, the online patching mechanism does not change the actual column. Rather than doing that, the
mechanism adds a new column with a type of number(15) to the underlying table.
By doing so, the patching tools or patch edition may work on the table while the application or run
edition actually uses it. The patching tools see the table with its new structure, and the application continues
to see the tables like it has never changed. This happens without any invalidations or code breaks.
Figure 5-21 represents this scenario, where the patch edition view sees the table with a newly added column
named ID2, while the run edition view continues to see the table as unchanged, with its run edition columns.

Figure 5-21. Patch edition view vs. run edition view of application tables

As shown, the patch edition and run edition view the same table at the same time, but they see different
columns, so this makes sure patching and the running applications do not conflict with each other. This
makes the system remain stable, and patching can continue while the applications are running.
In addition to the editioning views, using the cross-editioning trigger feature of EBR is crucial for
building an online patching environment in modern systems like EBS 12.2. Cross-editioning triggers are
triggers that are triggered when the data in the actual edition changes and populates the tables in other
editions with these new data changes to make them be synchronous with the base table. Figure 5-22 depicts
the scenario where a cross-edition trigger is triggered to propagate the changes done in the original column
named ID to the new version of it named ID2, which is added by a patch.

231
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-22. Cross-edition triggers populating newly added column

These triggers are used in EBS 12.2 to propagate the changes to a table during a patch application.
As explained earlier, in such a patching scenario like changing the definition of a column to a table, this
change will first be added in the patch edition. While the new table structure remains in the patch edition,
the run edition (in other words, the applications) won’t see this column with its new description. Consider a
scenario that changing the column description actually affects the data. That is, consider that a patch is used
for changing the way the full name of the students in the student table is stored. That is, consider that there
was only one column named FULL NAME to store the full names of the students before the patch.
Now consider that with the new structure that comes with the patch, the student table will have two
columns for storing the full names for the students: First Name and Surname.
So, as the new structure will not be activated until the adop cutover phase, the run edition (in other
words, the application) will still see the students table with the column FULL NAME, and the application will
continue to operate on this table as the patching process is designed to be online. Applications will insert the
new student name or update existing student names in the students table. So, what about the new columns
defined by the patch in the patch edition? We are talking about First Name and Surname. What will be stored
there? What about the new inserts? What about the updated data?
The answer for these questions is cross-editioning triggers. These triggers are defined to transmit the
data from the run edition to the patch edition and to synchronize the data between the editions.
A cross-edition trigger like the following will do the job, and that’s what the EBS 12.2 online patching
mechanism uses for answering these questions.
In a scenario like this, EBS 12.2 may use a forward cross-edition trigger to syncronize and populate the
new column.

CREATE OR REPLACE STUDENTS_FTRG

BEFORE INSERT OR UPDATE
ON FULL_NAME
FOR EACH ROW
FORWARD CROSSEDITION
DISABLE
BEGIN
:NEW.FIRSTNAME := TRIM(SUBSTR(:NEW.FULLNAME, 1, INSTR(:NEW.FULLNAME, ' ', -1)));
:NEW.SURNAME := TRIM(SUBSTR(:NEW.FULLNAME, INSTR(:NEW.FULLNAME, ' ', -1)));
END STUDENTS_ FTRG;
/

232
CHAPTER 5 ■ PATCHING CONCEPTS

The previous trigger can be used in making newly inserted or updated values in the old edition be
synchronized with the new edition.
So, as you may have noticed, there is a forward cross-edition statement in the previous code, which
defines the trigger STUDENTS_FTRG as a forward cross-edition trigger.
It is important to mention that forward cross-edition triggers are not the only type of cross-edition
triggers used in EBS 12.2.
That is, although the general logic of online patching in EBS 12.2 is having only one way to synchronize,
which is from the new edition to the old edition, there are some exceptional cases where you also see
reverse cross-edition triggers come into play. This is rare, but there are cases where online patching needs
synchronizing with the old edition from the data stored in the new edition. In such cases like “updating a
column in a seed table, that has a not null constraint, with no default value” or “updating a column which is
part of an unique index,” you can see reverse cross-edition triggers for synchronizing the updated data from
the patch edition to the run edition.

■ Note You may see the reverse cross-edition triggers in some exceptional cases, but you see the forward
cross-edition triggers almost in every case where a table structure is changed via online patching.

During online patching, forward cross-edition triggers are created in the patch edition, and they are
triggered when the changes are made in the old (run) edition. Oracle has chosen to use cross-edition
triggers for these type of operations as they can be reexecuted automatically for all the rows that are inserted
or changed by the running application. As for the patches that change the structure of application tables,
forward cross-edition triggers are used for synchronizing the old rows as well. In this context, a simple
update like update example_table set dummy=dummy will trigger the forward cross-edition trigger that is
defined on top of the table named example_table, and as a result, all the current rows of example_table are
synchronized.
In the case of the tables that store the seed data, the method is different. The table data is actually
copied during a patch application, and EBS uses the virtual private database (VPD) feature to create views
of data according to the edition that queries the data. The copying of data is done in the table. That is, seed
tables have an additional column named ZD_EDITION_NAME to store the edition type of a row. So, the
seed data (the rows residing on the seed table, which is in the target of the patch) is copied into the same
table, and the values of the ZD_EDITION_NAME columns for these copied rows are set to the patch edition’s
name. Thus, with the VPD based on the ZD_EDITION_NAME column, the online patching mechanism
makes the patch edition see and operate on the copy of the data without touching any of the actual data that
is used by the running EBS applications.
There must be sufficient space in the EBS 12.2 database to hold the duplicate copy of the seed data.
This is also required for the patches that are changing the columns of the application tables. In this manner,
the System tablespace should have at least 25GB of free space available, and the APPS_TS_SEED tablespace
should have a minimum of 5GB of free space available before starting an online patching cycle. We also
recommend you have at least 10 percent free space available in all other standard EBS tablespaces.
Later, within the cutover phase, the modified data becomes the actual data, and the former actual
data becomes the old data, which is removed in the cleanup phase. Oracle calls this method editioned data
storage, which allows an online patch to modify the seed data online.
Using this approach, what happens basically is that the data in seed data tables is replicated into the
same tables where it resides, and the patch operates on the private copy of the data. Thus, any change in the
seed data won’t affect the running application.
Oracle must have chosen this approach for the seed data, because the seed data is the data used by
the code itself, and unlike the application data stored in the application tables, the seed data is created and
patched by Oracle.

233
CHAPTER 5 ■ PATCHING CONCEPTS

That is, the patches written for the seed data probably change the data. As you may recall, the patches
for the application tables, as explained earlier, usually change the table structures of the related tables, and
this is where seed data patches differs. As the patches for seed data usually operate on the data, the online
patching mechanism does not follow a method based on the editioning views for supplying the online
patching; the purpose of the editioning views is not preventing the data from being accessed concurrently.
So, with this design, Oracle does not want to have two database editions to operate on the same data
concurrently; a VPD-based operation called editioned data storage is used for applying the patches that have
seed tables on their targets.
Figure 5-23 represents how the run and patch editions see the data in a single seed table differently.

Figure 5-23. Run edition vs. patch edition view of seed data stored in seed tables

Lastly, the forward cross-edition triggers are used to synchronize the copy of the data that is used by the
patch edition and the data used by the run edition, as there may be updates to the actual seed data during a
patching cycle, exactly between the apply and cutover phases.

■ Note The reverse cross-edition triggers could also be used in such scenarios. In a scenario like seed data
loading, reverse cross-edition triggers may be used for ensuring the old NOT NULL or UNIQUE constraints on the
old run edition columns are satisfied while the rows are being loaded in the patch edition. However, as no changes
in the patch edition are propagated to the run edition, reverse cross-edition triggers are not your concern.

If you pay attention, you’ll see we are talking about phases all the time. We explained the phases in general
in the introduction of this chapter, but you need to have detailed knowledge about them, as they as a whole
may be considered one of the most important systems that the online patching architecture is based on.
So, let’s take a closer look at the phases of online patching, also known as the adop phases.

Phases of Online Patching

Unlike earlier releases, EBS 12.2 uses a patching cycle for applying the patches. The patching cycle consists
of five major phases, which the online patching mechanism follows for applying any of the application
product patches. There is another mechanism, which is the downtime option, that we have already
explained in general but you will learn more about in Chapter 6.

234
CHAPTER 5 ■ PATCHING CONCEPTS

So, all the patches except the patches applied with the downtime option can be considered as online
patches in EBS 12.2. The patching activities required for these online patches are maintained by the online
patching phases also known as adop phases.
To apply a patch online, a patching cycle must be created, which is created by putting the system into
the first phase of online patching. The first phase is the prepare phase. To put the system into this prepare
phase, as it is applicable for putting the EBS system into any other phases, is done by executing the adop
phase=prepare command.
Once adop puts the system into the prepare phase, the patching cycle begins. After the prepare patch,
any patches can be applied using adop phase=apply in the patch edition of the EBS system online without
touching the runtime codes and objects. Once the application of the patches finish, in other words, once
the apply phase is completed, you can proceed with the finalize and cutover phases to activate those
changes brought by the patches. What is actually done by proceeding with the finalize and cutover phases is
making the EBS 12.2 application start using the newly deployed versions of both the code objects and data
structures.
Lastly, in the cleanup phase, all the objects and data created for patching the EBS 12.2 online are
cleared from the system, and the patching cycle completes.

■ Note Any time before the cutover, you can abort the patching cycle by using the adop phase=abort
command. However, a patching cycle cannot be aborted once the cutover phase is completed.

Figure 5-24 depicts what the phases and methodology followed by online patching looks like.

Figure 5-24. Phases of online patching

235
CHAPTER 5 ■ PATCHING CONCEPTS

Let’s get into the phases in more depth. Starting with the prepare phase (adop phase=prepare), the file
system gets synchronized. It is an incremental synchronization, so only the required file system objects are
copied from run to patch. The required files for the synchronization are files changed after the last patch is
applied to the system. Moreover, a new patch edition is created during the prepare phase. The new database
edition is created by making copies of the editioned objects in the database, and the copies don’t consume
space, as they are like pointers to the runtime objects. In other words, these copies are only the virtual
representations of the corresponding runtime objects and actualized only when they are patched. Although
the editioned objects do not consume space until they get actualized, this is not true for the patches
designed to change the seed data or application table definitions.
The seed data is also copied in this phase, and this copy of rows consumes space inside the database.
Thus, it is better to say that, except the seed data and the application table definitions, objects that are
supposed to be patched get actualized and start using space in the database patch edition only after they are
actually patched/changed.
Continuing with the apply phase, the patches are applied. The adop phase=apply command starts the
application of one more patches. While the patching actions required for changing a file system object are
done in the patch file system of the application tier, database actions taken by the patch are done in the
patch edition for the database tier. So, the apply phase is where the patches are actually applied online to an
EBS 12.2 system. However, the patches are applied to the patch edition and patch file system, so they are not
activated yet.
Even custom patches that are created by developers to deploy customized objects are applied in
this phase. Custom patches are prepared by developers, as well as using Application Management Pack
(AMP), which extends the capabilities of Oracle Enterprise Manager 12c Cloud Control to manage an
Oracle E-Business Suite 12.2 system more effectively. Note that you can refer to “Developing and Deploying
Customizations in Oracle E-Business Suite Release 12.2” (Doc ID 1577661.1) for details about developing
and deploying customized database objects, as well as the customized application tier objects in EBS 12.2.
Before activating the patched files and database objects, you have one more phase to complete; this
phase is called the finalize phase. The adop phase=finalize command puts the system into the finalize
phase, which can be considered a staging point. The finalize phase is where the invalid objects get compiled,
derived objects are generated, and DDLs for the use of the cutover phase are precomputed.
The finalize phase is also a terminal phase in a patching cycle.
You can wait as long as you want in this phase for the appropriate time to proceed with the cutover
phase, where the application services gets restarted, in other words, where downtime is needed.
Cutover, which is executed by the adop phase=cutover command, is the phase where the patch edition
becomes the new run edition and the previous run edition becomes an old edition. In this phase, the patch
file system becomes the new run file system, and the patch edition in database becomes the new run edition.
As a result of the cutover, application services are restarted, and that’s why downtime is felt by the end
users of the EBS applications. That is, end users are logged off when the application services in the middle
tier are stopped. When the application middle tier is stopped, the run file system and run edition become
old, and the patch file system and patch edition become the run file system and run edition.
Also, some final maintenance is performed in this phase, and after that, users are brought back online
when the application services are restarted on the new run file system connected to the new run edition.
The last phase of the patching cycle is the cleanup phase. The action done in this phase is basically
cleaning up the environment after applying the patches. This is where the System tablespace gets cleaned,
unnecessary objects are deleted, and even the old edition gets deleted if a full cleanup (cleanup_mode=full)
is performed.
So far, we have explained the online patching architecture, dual file system, EBR supporting the
architecture, and the phases that you need to consider while patching the EBS 12.2 application online.
Before continuing with Chapter 6, we will show these concepts in action and discuss backup best practices
for EBS 12.2 patching.

236
CHAPTER 5 ■ PATCHING CONCEPTS

Backup Best Practices for EBS 12.2 Patching

You have learned the methodology behind the patching activities in EBS 12.2. You have seen the different
methods, different tools, and different patching components along the way. You have seen the opatch and
BSU utilities for patching the technological components in EBS 12.2, and you have learned the new online
patching mechanism used in EBS product patches and the architecture supporting this mechanism in the
previous chapters. So, here we will explain the best practices for backup.
Backing up the system before applying patches to the technology components such as WebLogic and
Oracle Home such as 10.1.2 Home and RDBMS is not so crucial, as the utilities used in patching them have
the ability to roll back the action they made while patching.
BSU can remove a patch, which has been already applied to WebLogic, and opatch can roll back a
patch, which has been applied into an Oracle Home. These are pretty straightforward operations, and
removal or de-installation instructions for them can be found in the patch readme files.
Nevertheless, it’s worth mentioning the patch de-installation steps for patches that are applied using
BSU and opatch. To de-install a WebLogic patch that was applied using BSU utility, you basically execute the
BSU with a special argument called remove.
Here is an example of its usage:

./bsu.sh3 -remove -patchlist=<patchID1> \ prod_dir=<path>/FMW_Home/wlserver_10.3 -verbose

The command to be used removing a WebLogic patch is generally in this format, but there may be some
special instructions for the patches. That’s why we always recommend reading the readme files, even though
the actions needed for installation or de-installation can be memorized.
The following is a snippet from the readme of a WebLogic patch, which is actually a PSU. As you can
see, it says to stop the WebLogic server, navigate to MW_HOME/utils/bsu, and execute the command bsu.
sh –remove.

Uninstalling Oracle WebLogic Server Patch Set Update 10.3.6.0.7

---------------------------------------------------------------

- Stop all WebLogic Servers

- Navigate to the {MW_HOME}/utils/bsu directory.
- Execute bsu.sh -remove -patchlist={PATCH_ID} -prod_dir={MW_HOME}/{WL_HOME}

Alternatively, the remove operation can be done using the BSU utility interactively. As you see in
Figure 5-25, there is a Remove button for every patch listed in the BSU inventory. So, these Remove buttons
can also be used to remove a WebLogic patch from the WebLogic instance of an EBS 12.2 system.

237
CHAPTER 5 ■ PATCHING CONCEPTS

Figure 5-25. BSU Remove buttons

To de-install an Oracle Home patch that was applied using the opatch utility, you basically execute the
opatch with the special argument called rollback. Here’s an example:
opatch rollback -id <patch number>
Reading the readme file applies for these patches too.
The following is the de-installation part of a patch readme file that belongs to a database patch. As you
can see, it requires a SQL script to be executed for the patch to be installed.

To deinstall
Connect to the database using sqlplus / as sysdba
sqlplus> @catnomgdidcode (NOTE: file is located in $OH/md/admin)

Again, it is straightforward. The principle is just “Read the readme file and execute commands.”
However, the situation is a little different or a little complicated when it comes to online patching.
That is why we will focus on the backup best practices of online patching in this section.
The online patching mechanism introduced by the new release has an option to roll back the patches
up to the cutover phase. The adop utility, when run with the abort option, results in the special phase called
the abort phase to be executed for the active patching cycle. Thus, all the changes that occurred by doing the
patching activities up to the cutover phase can be rolled back.

238
CHAPTER 5 ■ PATCHING CONCEPTS

The benefits of the online patching mechanism emerge again, but this time in the form of supporting
the ability to roll back the changes created by the results of the patching activities.
“Ability to roll back the changes created by patching” means the ability to roll back the patches actually.
So, the patches in EBS 12.2 can be rolled back, but the ability to roll back is available up to the cutover phase.
Once the cutover is executed, the changes made in the apply phase become committed, and they cannot be
rolled back. In other words, a patch or bunch of patches applied as one in one go can be rolled back even
after applying them with the opatch phase=apply command.
By knowing this, you could say that if the online patching cycle consisted of only the prepare and apply
phases, the EBS 12.2 online patches could be rolled back. However, in reality, there is a phase called cutover
in online patching, and the changes cannot be rolled back once they are committed in the cutover phase.
This constraint brings a requirement to take a backup before patching. A cold backup could work,
but there is a big downtime for taking a cold backup. An online backup could also work, but it is a time-
consuming process and will increase the backup maintenance cost in the environment, so taking an online
backup for every patch is not so rational.
The problem here is not actually the method of the backup. It is the backup operation itself that creates
the cost. In other words, taking a backup before applying every online patch in EBS 12.2 is not so applicable,
as it costs so much that it complicates the patching operation and it increases the backup maintenance
operations; therefore, it even reduces the benefits of using online patching.
Therefore, you can use a different method for taking backups and for guaranteeing the ability to roll
back the EBS system to a state before the patching activities. The method you should follow to accomplish
this involves using the Flashback Database feature of Oracle Database in the database tier and restarting the
application services from the relevant file system edition depending on whether the decision to roll back the
system is done before the file systems were switched.
To explain this approach properly, let’s walk through on a scenario in which you actually need to roll
back the system after the cutover phase has been run. Suppose you want to apply a patch to your EBS 12.2
instance and started the patching cycle using the adop phase=prepare command. After the prepare phase,
you continue with the adop phase=apply command and apply the patch to the database patch edition and
application patch file system. Then you use the adop phase=finalize command to finalize the things before
running the adop‘s cutover phase.
After the finalize phase suppose you execute adop phase=cutover, but cutover fails. Also suppose you
try to fix the problem, causing cutover to fail (Oracle suggests so) but could not fix it. Thus, as a last resort,
you decide to go back to a state before you ran the cutover phase.
To able to go back to that state, you have to roll back the changes done in the database and application tiers.
In such a scenario, you need to start by rolling back the database to a state before you ran the cutover
phase, and to able to do so, you need to have a backup that can restored and used for recovering the
database just before running the cutover phase.
If the point-in-time recovery is not preferred, you can also take a full online backup before running the
cutover phase. However, taking an online backup in the cutover phase extends the time needed for patching,
and therefore it is not applicable for every patch. Suppose you need to apply a patch 10KB in size, but to
guarantee the ability to roll back in case of a failure that may be encountered during the cutover phase, you
need to take a backup of your EBS environment, which is 500GB in size.
So, backing up the environment would increase the duration of the patch application, and it could take
hours to apply a small patch to this system. Without even mentioning the side effects like heavy I/O that
backup jobs create, you can understand that taking a full backup before applying a small patch is not a great
idea. Similarly, restoring a full backup taken just before the cutover or restoring a full backup that has been
taken earlier and doing a point-in-time recovery will be a long process, and it is not applicable to be used in
the case of a patching failure.
Let’s go back where you started and illustrate this scenario again, but this time you’ll use the flashback
option and a couple of application tier operations to restore your EBS 12.2 system to the state it was in before
the online patching cutover phase was run.

239
CHAPTER 5 ■ PATCHING CONCEPTS

Enable flashback and configure it with four settings accordingly, before starting the patching cycle,
as follows:

sqlplus "/as sysdba"

SQL>alter system set db_recovery_file_dest = '/some_path/some_directory’ scope=BOTH SID='*';

db_recovery_file_dest is set to a directory where the flashback logs are placed. It can set
to an ASM disk group, as well.

SQL> alter system set db_recovery_file_dest_size = 100G scope=BOTH SID='*';

db_recover_file_dest_size is where flashback is placed; the size of the db_recovery_file_

dest should be set according to our needs. It actually depends on how long we want to store
the flashback logs. Also in addition to the flashback logs if we place our rman backups and
online redologs in the database recovery file destination, then we also need to consider
them for setting the db_recovery_file_dest_size.

SQL> alter system set db_flashback_retention_target=120;

db_flashback_retention_target is set to a value which actually represents the upper limit in
minutes on how far back in time the database may be flashed back.

SQL> alter database flashback on;

By executing "alter database flashback on", flashback in the Database gets activated.

At this point, you can say that configuring and enabling flashback in the EBS 12.2 database is completed.
The next thing to do is to create a flashback restore point, which is a point in time where you want to restore
your database using the flashback techniques. In such EBS 12.2 online patching scenarios, this restore point
may be created just before starting the patching cycle or preferably just before the cutover phase.
Before continuing with the creation of the restore point, let’s take a look at the recommendations for
this phase.
It is better to put the scheduled concurrent requests on hold before creating the request point and do a
log switch before and after creating the restore point.
Also, it is recommended you shut down the web services before creating the restore point to ensure that
there is no loss of data. So, by shutting down the web services and putting the critical concurrent requests
on hold, you can ensure that you won’t lose any important transactional data. Also, if there are any other
database applications that reach the EBS database via database links or any other non-EBS products using
the EBS database (actually there should not be), then they should be stopped or their EBS-related activities
should prevented by their application owners.
Another thing to consider is that rather than creating a normal restore point, a guaranteed restore point
should be created, as a guaranteed restore point assures that the database will maintain enough flashback
logs to flash back the database to the restore point. To accomplish this, you should use the guarantee
flashback database statement to create the restore point.
Lastly, it is important to ensure that no third-party application changes the data during the cutover
phase, so these kinds of third-party applications should be stopped before creating the restore point.
So, to summarize the requirements mentioned in the previous paragraphs, you have the following
action plan:
1. Stop the web services.
2. Stop the concurrent managers or put the schedule concurrent requests on hold.
3. Stop database-bound third-party applications or cut off their database connections.

240
CHAPTER 5 ■ PATCHING CONCEPTS

4. Force a log switch.

5. Create a guaranteed restore point.
6. Force another log switch.
Although you have the ability to choose when to create the restore point, it is advisable to create the
restore point just before the cutover phase, because as you can see in the previous action plan, there are
some requirements to stop the application services, which will increase the downtime for the patching
operation. So, it is better to create the restore point as late as possible.
After reviewing and ensuring the recommendations are in place, you continue with creating the
patching cycle and completing phases one by one until you reach the cutover phase and creating the restore
point as follows.
To start patching, you create the patching cycle using the adop phase=prepare command and complete
the phases one by one as shown here, until the cutover phase:

adop phase=prepare
adop phase=apply
adop phase=finalize

Just before the cutover phase, you create the restore point as follows:

SQL>alter system switch logfile;

System altered.
SQL>create restore point BEFORE_PATCH guarantee flashback database;
Restore point created.
SQL>alter system switch logfile;
System altered.

Once the restore point is created, you have a database backup that was taken exactly at the time you
wanted and can be restored if needed.
At this point, you have a backup; thus, you can continue with the critical cutover phase.

adop phase=cutover

Now suppose you face an unsolvable error during the cutover phase and decide to roll your EBS 12.2
environment back to the state before the patching cycle was started. This time, rather than a costly standard
database and application file system restore, you can use flashback to restore the database to the restore
point named BEFORE_PATCH, which was created just before the cutover phase.
To accomplish this, you follow this action plan:
1. Shut down the database.
• SQL>shutdown immediate
2. Start the database in mount mode.
• SQL>startup mount
3. Restore the database to the restore point BEFORE_PATCH using the flashback
feature.
• SQL>flashback database to restore point BEFORE_CUTOVER;
4. Start the database in read-only mode.

241
CHAPTER 5 ■ PATCHING CONCEPTS

• SQL>alter database open read only

5. Check the database with simple queries and ensure that there are no
abnormalities.
6. Shut down the database and open it using the resetlogs option.
• SQL>shutdown immediate
• SQL>startup mount
• SQL>alter database open resetlogs;
By doing the previous actions, you roll back your database to a state before the cutover phase.
After rolling back your database using flashback, you should disable the flashback in the database and
leave it to be disabled until the next patching operation. By doing so, you eliminate the risk of running out of
space in FRA, which may be caused by retaining the flashback logs. Note that running out of space will cause
the EBS database to hang.
The following action plan can be used to accomplish that:
1. Disable flashback.
• SQL>alter database flashback off;
2. Drop the restore point.
• SQL>drop restore point BEFORE_CUTOVER;
3. Set recovery file destination.
• SQL>alter system set db_recovery_file_dest='';
So far, so good. We have explained how to roll back an EBS 12.2 database using the flashback option in
case of a failure that may be encountered during the cutover phase. But what about the application tier file
systems? To fully roll back an EBS 12.2 system in the case of a cutover failure, you need to roll back the file
systems of the application nodes, too.
As patching activities change the database objects in the database, they change the file objects in the
application file system. Until the cutover phase, all the file objet changes are done in the patch file system;
likewise, all the database objects changes are done in the patch edition. So, any time before the cutover
phase, you can use adop phase=abort and roll back those changes. However, once you start the cutover
phase, abort will no longer work, and that’s why you need to do some special actions to roll back the changes
done in the cutover phase.
For the database tier, it is a little complicated. An operation like rolling back the changes that occurred
before the cutover employs using the flashback option, restore points, and so on. However, it is pretty simple
for the application tier.
Suppose you execute the cutover phase during a patching activity and encounter some errors. So, you
decide to roll back your EBS system to a state before the cutover phase. To roll back the changes for the
database tier, suppose you use the flashback restore point that you created earlier.
Just after the database is restored, you continue with rolling back the application tier. To do that, you
need to know whether the cutover failed before the file systems were switched. You can identify this using
the cutover logs stored in the adop cutover log file ($NE_BASE/EBSapps/log/adop/<current_session_id>/
cutover_<timestamp>/ for your session ID).
If the cutover failed before the file systems were switched, then you are lucky, as you just need to
shut down all the application services and then start all the application services using the run edition
environment like in your standard startup procedure.

242
CHAPTER 5 ■ PATCHING CONCEPTS

If the log file indicates that cutover failed after the file systems were switched, then you have to follow a
different action plan. That is, if the file systems were switched, then you need to switch back the file systems
in order to roll back your application tier to its state before the cutover phase.
What you need to do is as follows:
1. Source the environment on the current run file system.
2. Shut down all the application services using the standard procedure (adstpall.sh).
3. Switch back the file system using txkADOPCutOverPhaseCtrlScript.pl.

Usage :
perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl \
-action=ctxupdate \
-contextfile=<full path to new run context file> \
-patchcontextfile=<full path to new patch file system context file> \
-outdir=<full path to out directory>

4. Start up all services from the new run file system using the standard procedure.
(Source run edition environment and use the adstrtal.sh script to start all the
application services.)
Figure 5-26 represents the approach we have explained so far for rolling back a patch after executing the
adop’s cutover phase in EBS 12.2.

Figure 5-26. Using the Oracle Database flashback feature to roll back an EBS 12.2 system in case of patch failure

243
CHAPTER 5 ■ PATCHING CONCEPTS

Once you flash back the database and restart the application services from the file system that was
your run file system before the last cutover phase, your EBS 12.2 system is rolled back to the state before the
cutover phase. At this point, you can decide whether to continue or abort the patching cycle.
If you fix the issues causing cutover to fail, you may decide to continue the patching. In that case, you
can just execute the adop phase=cutover command. However, if you decide not to continue, you can use
adop phase=abort and abort the patching cycle.

Summary
In this chapter, you were introduced to the online patching concept used in EBS 12.2. You saw how to decide
the patching order in cases where you need to apply multiple patches in one go. Also, you learned about
merging patches and the different patching utilities available in EBS 12.2.
You took a deep dive into online patching and saw the phases that you go through while applying
applications patches online.
Lastly, you saw a recommended approach to be used in special recovery scenarios, where the database
work that is done in online patching is already committed.
Our goal in this chapter was to make you familiar with the Oracle E-Business Suite patching concepts by
concentrating on the newly introduced online patching concept. It is important to understand the patching
concepts of EBS 12.2 before going forward with Chapter 6, in which we will give you more specifics on
applying applications patches in EBS 12.2.

244
CHAPTER 6

Working with the Applications DBA

Online Patching Tool (adop)

In the previous chapter, you learned about the patching utilities used for applying different kind of patches
in EBS 12.2, the new online patching concept, and the patching tools and technology improvements
delivered in this new release of EBS to support the new patching concepts. In that chapter you also focused
on online patching because it is a new concept delivered with EBS 12.2 and it is the most common patching
activity that you will use in terms of EBS 12.2 patching.
We also introduced the new online patching tool, adop. In this chapter, you will focus on the adop utility
and learn more about its usage. We will also explain the details of online patching activities in EBS 12.2. In
this context, we will be showing you common usages of the adop tool that you may face in your daily work.
Specifically, we will cover the following topics: adop’s command-line parameters and options, how
to create patching cycles, adop’s remote invocation, hotpatch mode, downtime mode, how to merge the
patches, how to create patch reports, and diagnostics and troubleshooting.

Overview of adop
adop stands for “applications DBA online patching,” and it is the new patching utility in EBS 12.2. adop takes
the place of its ancestor, the adpatch utility, which was used for applications patching in earlier releases.
This does not mean adpatch has been retired. adop uses the adpatch utility in the back end transparently to
do some of its work. But adop is much more than a wrapper. The biggest difference of adop is that it uses a
new patching capability to support the online patching concept introduced in EBS 12.2.
adop is executed using the adop wrapper script named adop located in $APPL_TOP_NE/ad/bin. You
don’t need to remember this path, as the directory $APPL_TOP_NE/ad/bin comes included in your $PATH
environment variable when you source the applications environment using the EBSapps.env script.
So, wherever you’re in the file system and execute the adop command, the adop wrapper script $APPL_
TOP_NE/ad/bin/adop is executed by your shell, and this wrapper script executes the Perl script named
adzdoptl.pl located in the $AD_TOP/bin directory, which does the real work. The adzoptl.pl script is a Perl
script and uses several Perl libraries located in $AU_TOP/perl/ADOP, which, as you may guess, comes in
your $PERL5LIB environment variable when you source the applications environment. So, by using the Perl
libraries in the $AU_TOP/perl directories, adzoptl.pl drives the patching cycles, does the patching work, and
even executes some Java commands when necessary.
Topics such as the internals of adop, how it does the processing, the Perl scripting language behind
it, the wrappers, the actual scripts, and the environment variables are good to know and will bring you the
perspective on what you are dealing with; however, these things are mostly transparent to you.

S. Zaheer and E. Arslan, Practical Oracle E-Business Suite, DOI 10.1007/978-1-4842-1422-0_6
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

The important things to know for your administration work are what you can do with adop, how you
drive the patching cycle using it, how to use the adop utility consciously, what kinds of options are in this
utility, and how to diagnose the patching problems that may be encountered while using it.
Patching in EBS is done both on the application tier and on the database tier. That is, patches are
prepared by Oracle to change, modify, or create objects located both in the application tier and in the
database tier. Some patches may modify a forms objects or a report object located in the application tier file
system, and others may modify a PL/SQL package inside the database. Some of the application patches are
for adding a new language to the EBS system, and some of them are for adding the localizations for the EBS
products.
So, no matter the types of application patches and no matter their size or how big their effects are, the
patching is done by following some standards and a patching mechanism. These standards and the patching
mechanism are called online patching and come built-in with EBS so that the adop utility drives this
patching mechanism and applies the application patches in respect to the standards in EBS 12.2.
The patching standards and the mechanism used in EBS application patching are quite sophisticated.
The sequences of events that are performed during the EBS application patching are as follows. First, EBS
application patches are applied by analyzing the patch metadata to determine the dependencies and
requirements. After analyzing the patch metadata, the patch driver files are read to determine the patching
actions, and the product objects are compared with their correlates that come with the patch that is about to
be applied.
Next, the object definitions that will be changed by the patch are backed up, and actions are specified in
the patch driver file such as the following: copying files, compiling JSPs and invalid objects in the database,
relinking application tier executables, and generating forms, reports, messages, and JAR files. Also, the
database objects are updated if necessary, and lastly an AutoConfig is triggered to update the configuration
files if the patch delivers a new template or any existing template files are updated. As the patching session
finishes, the patch information is saved to the database to be queried for the next time.
So, all of these standards that are based on the patching mechanism in EBS 12.2 are followed by the
adop utility. In other words, adop in conjunction with the patch files, the patch metadata repository, and the
version information all work in respect to this mechanism to apply the application patches to the EBS 12.2
system in a supported way. adop does the heavy work, and you as the apps DBA just execute it and try to fix
any problems encountered in the adop executions. adop is an application-aware online patching utility that
can also sets its environment automatically and has capabilities such as recovering a failed patching session,
logging all of its activities, reporting its status, and doing other things such as validating the connection to
EBS schemas and making its operations in parallel.
The adop tool has additional modes such as preinstall mode, which is generally used in special
situations when instructed, such as when a patch needs to upgrade an AD utility. There is also a test mode of
adop, which can be used when you want to see the effects of a patch before applying it.
The adop tool can run interactively or noninteractively except for prompting for a password. Prompting
for a password can also be disabled during execution by passing passwords as inputs to adop using the
capabilities of the underlying shell. (For example, you can use Linux pipes to supply the passwords to adop
while executing it.)
In addition, the adop utility in EBS 12.2.5 (or in earlier 12.2 releases, which are at AD-TXK Delta 5 patch
levels) has the ability to apply patches offline using the downtime option.
To summarize, adop is a sophisticated tool that drives the complex patching process used in EBS 12.2.
It is also important to mention that, in addition to the adop’s capabilities, there are supporting AD tools such
as admerge for merging several patches to a single one and adctrl for controlling the adop workers that are
often used while working with adop. Thus, they will also be explained in this chapter.

246
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Working with the adop Utility

As the adop tool utility is used for applying application patches to an EBS 12.2 system, the utility is located in
the application tier and run from the application tier’s run edition file system.
To run the adop utility and apply patches, you just log in to the application node or nodes using the
application owner OS user (for example, applmgr), set the run edition environment, and execute the adop
command. Listing 6-1 describes sourcing the runtime environment using the famous EBSapps.env script
and running the adop utility.

Listing 6-1. Setting the Runtime Environment and Running adop

[applmgr@somehost ~]$ . /u01/install/TEST/EBSapps.env run

E-Business Suite Environment Information

----------------------------------------
RUN File System : /u01/install/TEST/fs1/EBSapps/appl
PATCH File System : /u01/install/TEST/fs2/EBSapps/appl
Non-Editioned File System : /u01/install/TEST/fs_ne
DB Host: somehost.somedomain.com Service/SID: TEST
Sourcing the RUN File System ...

[applmgr@somehost ~]$ adop

Enter phase:

As shown in Listing 6-1, when executed without any command-line parameters, adop requests to enter
the phase. This means adop can’t be executed without specifying the phase; this is a logical requirement
because the patching in EBS 12.2 is based on a new concept, the patching cycle.
The patching cycle and the phases of it were explained in Chapter 5, but it is worth reviewing them
before you start working with adop in this chapter.
The patches can be applied online by following the phases in the patching cycle. The patching cycle
consists of five phases named prepare, apply, finalize, cutover, and cleanup. The phase abort is also a main
phase in this patching cycle concept, but it is used for quitting an ongoing patching activity by aborting the
patching cycle. In addition, there are two more phases named fs_clone and actualize_all, which can be used
in special situations and will be explained when we talk about the adop command-line parameters and
options.
So, to start online patching an EBS 12.2 system with adop, you first need to execute the adop prepare
phase. The adop tool prepare phase creates a patching cycle, which can then be used for patching the EBS
system by following the remaining adop phases in sequence. In other words, to apply a patch, you start a
patching cycle using adop phase=prepare, and after that you continue with the phase=apply, phase=finalize,
phase=cutover, and phase=cleanup commands.
Listing 6-2 shows how to set the runtime environment and execute the adop phases one by one in
sequence to apply a patch online to an EBS 12.2 system.
The outputs of the adop commands provide lots of the details about their executions and display the log
file paths of the ongoing adop operations and scripts executed along the way, but we won’t list the logs here,
as they are beyond the scope of this section. Rather than concentrating on the outputs and logs at this point,
you will see them later this chapter while we explain diagnostics and troubleshooting in online patching.

247
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Another thing that may catch your attention is that, as shown in Listing 6-2, adop requests you to enter
the APPS schema, SYSTEM schema, and WLSADMIN passwords before it starts executing the phases.

Listing 6-2. Executing adop with Phases

[applmgr@somehost ~]$ . /u01/install/APPS/EBSapps.env run
[applmgr@somehost ~]$ adop phase=prepare

Enter the APPS password:

Enter the SYSTEM password:
Enter the WLSADMIN password:

[applmgr@somehost ~]$ adop phase=apply

Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

[applmgr@somehost ~]$ adop phase=finalize

Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

[applmgr@somehost ~]$ adop phase=cutover

Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

[applmgr@somehost ~]$ adop phase=cleanup

Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

So, each time an adop phase completes, it gives you the OS terminal prompt back so you can continue
with the next phase by running adop again by supplying the desired phase as an argument. That is, when
adop phase=prepare completes, you execute the adop phase=apply command, and after the apply phase is
complete, you continue by executing the adop phase=finalize command, and so on.
Actually, you can execute the adop phases one by one in sequence like a script without waiting in the
OS terminal for each phase to complete.
Listing 6-3 shows an adop command that instructs adop to execute the five main adop phases one
after another.

Listing 6-3. Executing All the adop Phases in One Go

[applmgr@somehost ~]$ adop phase=prepare,apply,finalize,cutover,cleanup
Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

As you may see in the Listings 6-2 and 6-3, adop wants you to provide the APPS schema, SYSTEM
schema, and WebLogic admin passwords every time it runs. You can use the shell trick in Listing 6-4 to
automate specifying these passwords. Note that this method brings an opportunity to execute adop with less
effort from the shell scripts or any other code that has the ability to connect to the operating system.

248
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Listing 6-4. Executing adop by Supplying the APPS Schema, SYSTEM Schema, and WebLogic Passwords in
the Command Line
[applmgr@somehost ~]$ { echo appspassword; echo systempassword; echo adminpassword; } | adop
phase=prepare,apply,finalize,cutover,cleanup

You can even go further and create an input file for adop to specify things such as the parallel worker
counts, the number of the patch to be applied, and the directory that the patch to be applied is located, as
shown in Listing 6-5. In Listing 6-5, we are using an input file in conjunction with an automated password
specification method to apply patch 20863040 by only pressing the Enter button. To do this, you create an
input file named test_input and add the lines shown in the listing in it.

Listing 6-5. Executing adop phases as a one liner by piping the passwords and giving an input file as a
command line argument
workers=12
patches=20863040
phase=prepare,apply,finalize,cutover,cleanup
patchtop=/home/applmgr
[applmgr@somehost ~]$ { echo appspassword; echo systempassword; echo adminpassword; } | adop
input_file=/home/applmgr/input_test

Note that the patch used in Listing 6-5 is located in the /home/applmgr directory and is unzipped.
As described in Listing 6-5, after creating the input file, you supply it to adop using the command-line
argument named input_file.
So, as shown in Listing 6-5, there are different forms of executions for adop, and even though we have
not explained them yet, there are several command-line arguments that can be supplied for it.
Another important thing is that we did not specify any patch numbers or point adop to look for a patch
in a specific directory while we were showing the adop phases in Listing 6-2. However, in Listing 6-5, we
supplied the patch location and the number of the patch to be applied using an input file. So, you may ask,
“How does adop know which patch to apply without specifying the patch directory and patch number as
showing Listing 6-2?”
The answer is simple. adop looks to a default directory pointed at by $APPL_TOP_NE/../patch to
determine the patch or patches to be applied.
As long as there are no command-line arguments or any input files that specify the patch directory
or the number of the desired patch, adop checks the $APPL_TOP_NE/../patch directory and applies the
patches located as unzipped in that directory.
Knowing this, you can just download the desired patch from Oracle Support and unzip it into the
$APPL_TOP_NE/../patch directory and then execute adop without specifying any arguments for patch
locations and patch numbers. That’s why you may see a sentence like the following in most of the Oracle
Support documents that are written for big upgrade patches: “Download and unzip all the patches to the
default Patch Top location for R12.2 ($APPL_TOP_NE/../patch).”
Listing 6-6 shows unzipping patch 21140485, which was downloaded to a directory named /downloads,
to the default patch directory for adop and executing the adop apply phase afterward (we have already
completed the adop=prepare phase).

249
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Listing 6-6. Unzipping an Application Patch into the Default Patch Top Location for adop ($APPL_TOP_
NE/../patch) and Executing the adop apply Phase
[applmgr@somehost ~]$ cd /downloads
[applmgr@somehost ~]$ ls
p21140485_R12.CLE.C_R12_GENERIC.zip
[applmgr@somehost ~]$ unzip p21140485_R12.CLE.C_R12_GENERIC.zip -d $APPL_TOP_NE/../patch
[applmgr@somehost ~]$ adop phase=apply

As shown in Listing 6-6, for your convenience you can unzip the patch or patches to be applied to the
default patch directory and thus execute adop without specifying any patch-related arguments. Also, as in
Listing 6-5, you can always apply a patch located in a nondefault directory by specifying that directory using
the patchtop and patches arguments. That is, if you unzip a patch with the number 123456 to a directory
named /home/applmgr, you should supply patchtop as /home/applmgr and the patches argument as patch
number to adop, as shown in Listing 6-7.
In Listing 6-7, you unzip patch 21140485 to a nondefault patch directory named /home/patches and
then execute adop by specifying that directory using the patchtop argument. (We have already completed
the adop=prepare phase.)

Listing 6-7. Unzipping an Application Patch into a Nondefault Patch Location (/home/applmgr/patches)
and Executing adop Apply Phase with the patchtop Argument
[applmgr@somehost ~]$adop=prepare phase
[applmgr@somehost ~]$cd /downloads
[applmgr@somehost ~]$ls
p21140485_R12.CLE.C_R12_GENERIC.zip
[applmgr@somehost ~]$ unzip p21140485_R12.CLE.C_R12_GENERIC.zip -d /home/applmgr/patches
[applmgr@somehost ~]$ adop phase=apply patchtop=/home/applmgr/patches

■ Note Whether using the default patch top, the patches that are unzipped and applied in an online patching
cycle must not be deleted and must be located in the same location where they are unzipped and applied
from. These patches will be used in the next prepare phase, in other words, in the next patching cycle for
synchronizing the patch file system. So, the patches that are applied in an online patching cycle should not be
deleted from the patch top directory (default or nondefault) until the next prepare phase is complete.

As there are different phases to be executed for applying a patch online with the adop utility and as
there is no need to execute the phases of adop immediately one after another, there is a status option for
adop that gives the current statuses of adop patching cycles.
In this context, the adop –status command can be used anytime there is a need for checking the current
status of the patching cycle to understand which phases are executed, which are pending, and so on. The
adop tool –status command requests you to supply only the APPS password when it gets executed.
Listing 6-8 shows the adop –status command and its output for a patching cycle where all the phases are
completed and patch 20863040 is applied.

■ Note The output of the adop –status command has been trimmed here in order to display the statuses in a
better format.

250
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Listing 6-8. adop -status Command and Its Output Displaying That Patch 20863040 Has Been Applied
[applmgr@somehost ~]$adop –status
Enter the APPS password:

Node Name Node Type Phase Status Started Finished Elapsed

--------- --------- -------- --------- ----------------- ----------------- -------
somehost PREPARE COMPLETED 14-APR-15 04:11:19 14-APR-15 05:32:38 1:21:19
master +03:00 +03:00
v1
APPLY COMPLETED
14-APR-15 05:33:03 14-APR-15 05:35:32 0:02:29
+03:00 +03:00
FINALIZE COMPLETED 14-APR-15 05:35:42 14-APR-15 05:36:07 0:00:25
+03:00 +03:00
CUTOVER COMPLETED 14-APR-15 05:36:17 14-APR-15 05:50:51 0:14:34
+03:00 +03:00
CLEANUP COMPLETED 14-APR-15 05:50:53 14-APR-15 05:51:34 0:00:41
+03:00 +03:00
============================================================================================
Patches Applied in the Current Patching Cycle
============================================================================================
Node Name Node Type Status Run ID File System File System Applied Session Type
Patch Patch Base Base Adpatch Parameters
--------- --------- ------- ------------------ ------------------------ -------------
somehost 20863040 Y 78344 /u01/install/APPS/fs1 ONLINE
master

So, you have seen how to execute adop from the OS terminal as well as how to unzip patches and supply
the needed information such as patch directories and patches to be applied for adop to operate. Remember,
execute the adop phases one by one and execute all the phases by running only one adop command.
Also, you have seen some advanced topics such as piping the passwords to adop using the command
line, using an input file in conjunction with the command-line password piping method, and specifying all
the phases in a comma-separated list in adop’s phase argument to execute the whole patching cycle process
using only a one-liner. You have also seen how to report the status of the adop phases executed in patching
cycles by seeing an example of the adop –status command.
So far, you should realize that it is easy to execute adop, but there are different forms for its executions.
That is, by seeing the previous examples, you may already start feeling that there are several command-line
options for adop and several use cases that may be required according to the different patching scenarios.
Even though the adop tool is easy to use, there are lots of things it can do.
Although adop can be executed using only a simple command like adop phase=desired_phase, there
are several command-line options for adop that change the behavior of this patching tool.
Well, we have started fast and you already seen some of the command-line options for adop while
seeing how you work with adop in this section. Until now, you have seen a couple of these command-line
parameters, and you used them to make your job easier. In the examples provided earlier, it was optional
to use the command-line options such as input file, patchtop, and patches. However, there are some
command-line parameters that are required in some special cases.
So, there are several command-line parameters for the adop utility, and it is crucial to know them all.
We will explain the command-line parameters and options in the next section.

251
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

adop Command-Line Parameters and Options

adop command-line arguments can be classified into two categories: command-line parameters and
command-line options.
The main difference between command-line parameters and command-line options is that command-
line options can be used to change the way adop operates. That is, you can supply options to adop and
change its default behavior when applying application patches such as skipping compiling invalid database
objects after taking the necessary patching actions in the database or reapplying a patch even if it is already
applied. Normally adop detects the patches if they are already applied and gives the type of warnings shown
in Listing 6-9.

Listing 6-9. adop Warnings for Already Applied Patches

[WARNING] Skipping the application of patch 18060329 since it has been already applied
[WARNING] Hint: Patches can be applied again by specifying options=forceapply when
invoking adop

Command-line parameters, however, can be used to make adop use the provided values in its
executions. That is, you can tell adop to execute only the prepare phase in a patching cycle, or you can
increase the log level of adop by supplying it with the necessary command-line parameters. To summarize,
the command-line options can be used to change the standard behavior of adop, and the command-line
parameters can be used to specify the standards to be applied by adop.
In addition to this main difference, there are some more differences in using the command-line
parameters and options. That is, while all the command-line options are optional, there are some
command-line parameters such as phase that are required to be supplied to adop in order to apply a patch.
The ways of using these options and parameters at the command line also differ from each other.
That is, options are supplied using the options argument (for example, adop options=nocopyportion,
nogenerateportion).
However, the parameters are supplied directly (for example, adop phase=apply or adop phase=apply
loglevel=STATEMENT). Nevertheless, there is still a big similarity between them, as options are specified
as using the command-line parameter named options, so this makes the command-line options can be
considered command-line parameters in a way.
After this quick introduction, let’s examine the adop command-line parameters and options in detail
so you can see what options you have and what you can do using the parameters. Table 6-1 describes the
available command-line parameters for adop and provides examples of how to use them in command line.
The adop tool command-line options are also declared and explained in Table 6-1, as the command-line
options are specified using the command-line parameter named options.

■ Note The usages of these parameters can also be viewed by using the adop –help command. In addition,
using the adop –examples command, you can view the example usages of these parameters.

252
Table 6-1. The adop Tool Command-Line Parameters and Options with Their Descriptions, Possible Values, and Usage Examples

Parameter Possible Values Description Example of Usage

phase • prepare Used for specifying the phase to be executed by adop phase=prepare
• apply adop. adop phase=prepare,apply
• finalize Except abort and fs_clone, other phases can be adop phase=abort
• cutover specified together like a comma-separated list. adop phase=fs_clone
• cleanup adop phase=prepare,apply,
• fs_clone finalize,cutover,cleanup
• abort
• actualize_all
loglevel • statement Used to adjust the log level for adop. statement is the adop phase=prepare log_level=warning
• procedure highest level, where adop logs almost everything, adop log_level=statement
• event (default) and unexpected is the lowest level, where adop logs
• warning only the unexpected situations.
• error
• unexpected
apply_mode • online (default) Used to specify how the patch is applied. This adop phase=apply apply_mode=downtime
• downtime parameter can be used only for the apply phase.
• hotpatch The default value of online is for specifying the
• bootstrap online patching, the value of downtime is for
applying a patch while the application services are
down, and the value of hotpatch is for applying
the patch directly to the run edition while the
application services are running.
Bootstrap mode is an undocumented mode, but it
applies the patches in hotpatch mode and, when
used, adop makes you deal with the adpatch dialogs
just like in earlier releases. So, it is just a way to use
adpatch through adop. Bootstrap mode must not be
used unless instructed by Oracle.
(continued)

253
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)
Table 6-1. (continued)

254
Parameter Possible Values Description Example of Usage
cleanup_mode • quick Used in the cleanup or prepare phase, where the adop phase=prepare cleanup_mode=full
• full cleanup action takes place. Used to tell adop how adop phase=cleanup cleanup_mode=quick
• standard (default) much to clean up.
Quick cleanup mode has the shortest execution time
by removing the cross-edition triggers and obsolete
data and skipping some other essential cleaning
actions such as dropping old editions and obsolete
columns.
Standard cleanup mode has the second shortest
execution time. The difference between quick and
standard cleanup modes is, in standard mode,
obsolete; editioned code objects are also removed.
Full cleanup mode is the slowest cleanup mode. In a
full cleanup, in addition to all the cleanup work that
is done in standard cleanup mode, the old editions
and obsolete columns are also removed.
finalize_mode 1. full This parameter can be used both in the finalize and adop phase=finalize finalize_mode=full
2. quick (default) cutover phases. (There is a finalize operation in adop phase=cutover finalize_mode=full
cutover phase too.)
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

Quick finalize mode has the shortest execution

time. The difference between full and quickest
finalize modes is that quick finalize mode skips
some essential finalizing actions such as gathering
statistics.
In full finalize mode, the finalize phase may
take a long time (like an hour) according to the
performance of the database system, as statistics
are gathered in full finalize mode to improve
performance.
input_file User-specified file with An input file prepared by users (apps dbas) for adop. Input file name:
full path Using input files, apps DBAs can specify several /tmp/test.in
parameters in a file called the input file and use the Input file contents:
input file command-line parameter to make adop workers=12 patches=20863040 phase=prepa
interpret that file and get its parameters. re,apply,finalize,cutover,cleanup patchtop=/
home/applmgr
Specifying the input file:
adop input_file=/tmp/test.in
maxworkers User-specified value This parameter can be used in the apply phase. adop phase=cleanup workers=8
for telling adop the Normally, maxworkers are automatically calculated maxworkers=12
maximum parallel by adop according to the CPU core counts, but by adop phase=prepare workers=40
worker count that it using the maxworkers parameter, apps DBAs can maxworkers=50
can use in its patching overwrite it. adop phase=prepare,apply,finalize,cutover,cl
activities Note that to overwrite the automatically calculated eanup workers=20 maxworkers=30
workers value, the value of the maxworkers
parameter should be used in conjunction with
workers parameters, and it must be set greater than
the automatically calculated and desired worker
value. Otherwise, adop will use the automatically
calculated one.
patches Patch number or This parameter is required in the apply phase. Adop phase=apply patches=123456
comma-separated list of Using the patches parameter, apps DBAs can tell Adop phase=apply
patch numbers, used to adop which patch or patches to apply in an apply patches=123456,112233,445566
tell adop the patches to phase. In case of translation patches, the patch
be applied number is specified with the short name of
the language and the driver file of the patch.
The following example shows specifying the
patch 111111 and Turkish version of patch
123456:
adop phase= apply patches=111111,
123456_TR:123456.drv

(continued)

255
CHAPTER 6 ■ WORKING WITH THE APPLICATIONS DBA ONLINE PATCHING TOOL (ADOP)

File System Case Study
No ratings yet
File System Case Study
23 pages
Oracle EBS Architecture
No ratings yet
Oracle EBS Architecture
8 pages
DBMS VS File System
No ratings yet
DBMS VS File System
4 pages
BJMP Time Allowances Manual Revised Version 2016
No ratings yet
BJMP Time Allowances Manual Revised Version 2016
46 pages
10116-Oracle E-Business Suite R12.2.6 On Database 12c - Install - Patch and Administer-Presentation With Notes - 157
No ratings yet
10116-Oracle E-Business Suite R12.2.6 On Database 12c - Install - Patch and Administer-Presentation With Notes - 157
64 pages
4b Raid Filesystem
No ratings yet
4b Raid Filesystem
76 pages
Applying Patch in R12.2
50% (2)
Applying Patch in R12.2
80 pages
Decline of Education in Pakistan For CSS English Essay - Atif Pedia PDF
No ratings yet
Decline of Education in Pakistan For CSS English Essay - Atif Pedia PDF
9 pages
SQL Aggregate Functions PDF
100% (2)
SQL Aggregate Functions PDF
19 pages
Distributed File Systems
No ratings yet
Distributed File Systems
35 pages
4a Filesystem
No ratings yet
4a Filesystem
33 pages
File MGMT L4
No ratings yet
File MGMT L4
42 pages
Oracle EBS R12 Architecture
No ratings yet
Oracle EBS R12 Architecture
7 pages
13 FileSystemImplementation
No ratings yet
13 FileSystemImplementation
24 pages
XFS - Extended Filesystem
No ratings yet
XFS - Extended Filesystem
46 pages
FHSS PT 05 File Systems
No ratings yet
FHSS PT 05 File Systems
30 pages
Wa0010.
No ratings yet
Wa0010.
26 pages
Oracle EBS R12 Architecture
No ratings yet
Oracle EBS R12 Architecture
8 pages
17-Module 7-11-11-2024
No ratings yet
17-Module 7-11-11-2024
48 pages
Oracle 12.2 Development Standards
No ratings yet
Oracle 12.2 Development Standards
24 pages
CYB 205 Part 2
No ratings yet
CYB 205 Part 2
17 pages
Presentation - Os - File System
No ratings yet
Presentation - Os - File System
20 pages
Unit 8 - File System Interface and Implementation
No ratings yet
Unit 8 - File System Interface and Implementation
37 pages
Theory Assignment 01
No ratings yet
Theory Assignment 01
13 pages
Week-3 Os Ass
No ratings yet
Week-3 Os Ass
17 pages
Laurie Baker: (The Gandhi of Architecture - Who Built Sustainable Buildings)
No ratings yet
Laurie Baker: (The Gandhi of Architecture - Who Built Sustainable Buildings)
38 pages
Review Dbms Proj
No ratings yet
Review Dbms Proj
40 pages
L8 DFS
No ratings yet
L8 DFS
35 pages
Distributed File System
No ratings yet
Distributed File System
27 pages
Section10-File Systems PDF
No ratings yet
Section10-File Systems PDF
43 pages
Media and Storage: UNIX File Systems
No ratings yet
Media and Storage: UNIX File Systems
47 pages
Oracle EBS 12.2.7 Rohan TEST
No ratings yet
Oracle EBS 12.2.7 Rohan TEST
39 pages
Session 15 EXT2 and EXT3 Amzb
No ratings yet
Session 15 EXT2 and EXT3 Amzb
47 pages
Estandar OFA
No ratings yet
Estandar OFA
12 pages
Operating Systems - File-System Interface
No ratings yet
Operating Systems - File-System Interface
13 pages
Succession Notes
No ratings yet
Succession Notes
146 pages
Operating System Assignment
No ratings yet
Operating System Assignment
9 pages
Group A File System
No ratings yet
Group A File System
8 pages
Database Vs File Processing System
No ratings yet
Database Vs File Processing System
5 pages
Akash Kunal
No ratings yet
Akash Kunal
7 pages
Operating Systems/ File Systems and Management Lecture Notes
No ratings yet
Operating Systems/ File Systems and Management Lecture Notes
21 pages
COM 214 File Ogarnization and Management Lecture Note 4
No ratings yet
COM 214 File Ogarnization and Management Lecture Note 4
14 pages
List of Filesystems
No ratings yet
List of Filesystems
3 pages
General Parallel and Window File System
No ratings yet
General Parallel and Window File System
5 pages
Assignment No. 1
No ratings yet
Assignment No. 1
8 pages
CL205 Lab8
No ratings yet
CL205 Lab8
21 pages
Franz
100% (1)
Franz
2 pages
CEF427 Chapter5
No ratings yet
CEF427 Chapter5
6 pages
What Is A File System ?
No ratings yet
What Is A File System ?
11 pages
Distributed Operating Systems
No ratings yet
Distributed Operating Systems
5 pages
File System
No ratings yet
File System
27 pages
A Comparison of Journaling and Transactional File Systems
No ratings yet
A Comparison of Journaling and Transactional File Systems
12 pages
Operating System
No ratings yet
Operating System
5 pages
Test Bank For International Business Competing in The Global Marketplace 10th Edition Hill 007811277X 9780078112775
100% (44)
Test Bank For International Business Competing in The Global Marketplace 10th Edition Hill 007811277X 9780078112775
36 pages
Oracle EBS R12 Architecture
No ratings yet
Oracle EBS R12 Architecture
7 pages
Modern Distributed File System Design: Vrije Universiteit Amsterdam
No ratings yet
Modern Distributed File System Design: Vrije Universiteit Amsterdam
7 pages
APPS R12 Architecture: Tech Stack Components
No ratings yet
APPS R12 Architecture: Tech Stack Components
6 pages
Ce40 2 - M3 Exam
No ratings yet
Ce40 2 - M3 Exam
21 pages
Key Concepts of English Language and Linguistics: Raffaella Picello
No ratings yet
Key Concepts of English Language and Linguistics: Raffaella Picello
12 pages
Sacrament of The Eucharist
No ratings yet
Sacrament of The Eucharist
3 pages
Kuis Akmen
No ratings yet
Kuis Akmen
5 pages
Howard+Luck+Gossage+Collection+ +Legendary+Ads+Vault+ +975042
100% (2)
Howard+Luck+Gossage+Collection+ +Legendary+Ads+Vault+ +975042
109 pages
OPCRF SY2022 2023 ToolAutomated Final
No ratings yet
OPCRF SY2022 2023 ToolAutomated Final
46 pages
6 To 8 Grammer Key
No ratings yet
6 To 8 Grammer Key
149 pages
Canonical Preparations
No ratings yet
Canonical Preparations
3 pages
Racial and Sexual Oppression
No ratings yet
Racial and Sexual Oppression
3 pages
Cambridge International AS & A Level: BIOLOGY 9700/31
No ratings yet
Cambridge International AS & A Level: BIOLOGY 9700/31
12 pages
Admission Broucher Admission Form MTech 2024 1005
No ratings yet
Admission Broucher Admission Form MTech 2024 1005
9 pages
Oracledatabaseadministrationi1z0 082examdumps2024 240524135625 A77fac36
No ratings yet
Oracledatabaseadministrationi1z0 082examdumps2024 240524135625 A77fac36
12 pages
Alur Diagnosis Rash Kulit
No ratings yet
Alur Diagnosis Rash Kulit
21 pages
Developing Design Process
No ratings yet
Developing Design Process
25 pages
Curriculum Vitae P. Hari Krishnan: Objective
No ratings yet
Curriculum Vitae P. Hari Krishnan: Objective
2 pages
NextLeap Graduation Project GPay
No ratings yet
NextLeap Graduation Project GPay
10 pages
Adil H. Shaikh Lqy4
No ratings yet
Adil H. Shaikh Lqy4
7 pages
Vapor RTF Manual .3
No ratings yet
Vapor RTF Manual .3
12 pages
A UnitI ProgramTest PDF
No ratings yet
A UnitI ProgramTest PDF
1 page
My World: Vocabulary
No ratings yet
My World: Vocabulary
10 pages
Vedic Mathematics - Brief History of Vedic Mathemat..
No ratings yet
Vedic Mathematics - Brief History of Vedic Mathemat..
5 pages
(Rtcamp) WordPress Engineers (Trainee) - Campus Job Description 2022,21,20 Batch
No ratings yet
(Rtcamp) WordPress Engineers (Trainee) - Campus Job Description 2022,21,20 Batch
7 pages
Unit 4 Cultural Env Intro
No ratings yet
Unit 4 Cultural Env Intro
31 pages
Fabia PDF
No ratings yet
Fabia PDF
40 pages
Worksheet For Sean Young
No ratings yet
Worksheet For Sean Young
12 pages
CLASS 11 - PHYSICS - MECHANICAL PROPERTIES OF SOLIDS Assignments
No ratings yet
CLASS 11 - PHYSICS - MECHANICAL PROPERTIES OF SOLIDS Assignments
3 pages
Revision Sheet
No ratings yet
Revision Sheet
15 pages
Consumer Protection Act 2019
No ratings yet
Consumer Protection Act 2019
4 pages
Justice Isn
No ratings yet
Justice Isn
2 pages
Grade 9 - Chinese - Reading and Writing - Marking Scheme
No ratings yet
Grade 9 - Chinese - Reading and Writing - Marking Scheme
4 pages
BTP Project Consent Form: Details of The Student(s)
No ratings yet
BTP Project Consent Form: Details of The Student(s)
1 page
Revisi Artikel Kelompok 3
No ratings yet
Revisi Artikel Kelompok 3
7 pages
Introduction to Oracle Database Administration
From Everand
Introduction to Oracle Database Administration
Ying Wang
5/5 (1)
Work with the Command-line: To Manage Files and Directories in Ubuntu
From Everand
Work with the Command-line: To Manage Files and Directories in Ubuntu
Sudiman Suhaili
5/5 (4)
Oracle Database 12c Quickstart
From Everand
Oracle Database 12c Quickstart
Michael Elliott
5/5 (5)
Starting Database Administration: Oracle DBA
From Everand
Starting Database Administration: Oracle DBA
anuragbaruah84
3/5 (2)
The 101 Most Important UNIX and Linux Commands
From Everand
The 101 Most Important UNIX and Linux Commands
Ronald J. Leach
No ratings yet
Concise Oracle Database For People Who Has No Time
From Everand
Concise Oracle Database For People Who Has No Time
Billy Aung Myint
No ratings yet
Introduction to Microsoft SQL Server
From Everand
Introduction to Microsoft SQL Server
Eric Frick
No ratings yet
JavaScript File Handling from Scratch: A Practical Guide with Examples
From Everand
JavaScript File Handling from Scratch: A Practical Guide with Examples
William E. Clark
No ratings yet
MVS JCL Utilities Quick Reference, Third Edition
From Everand
MVS JCL Utilities Quick Reference, Third Edition
Robert Wingate
5/5 (1)