Unix ->DBA-RAC->Apps DBA

login as: applmgr

applmgr@192.168.0.120's password:
Last login: Tue Mar 28 15:09:16 2017 from 192.168.0.133

E-Business Suite Environment Information

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

DB Host: r12.hasmansoft.com Service/SID: VIS

E-Business Suite Environment Setting

------------------------------------
- Enter [R/r] for sourcing Run File System Environment file,
or
 - Enter [P/p] for sourcing Patch File System Environment
file, or
- Enter anything else to exit

Please choose the environment file you wish to source

[R/P]:
[applmgr@r12 ~]$
[applmgr@r12 ~]$
[applmgr@r12 ~]$ pwd
/u01/applmgr
[applmgr@r12 ~]$ ls
02131633.log afiedt.buf oradiag_applmgr sqlnet.log
wwapps2 wwapps_vis
adctrl.log bea prefs.ora wwapps wwapps2.tar.gz
XX_DASHBOARD.ldt
[applmgr@r12 ~]$ pwd
/u01/applmgr
[applmgr@r12 ~]$ cd ../
[applmgr@r12 u01]$ ls -lrt
total 1856
-rw-r--r--. 1 root root 83928 Jan 19 19:29 compat-
libstdc++-296-2.96-144.0.2.el7.i686.rpm
-rw-r--r--. 1 root root 10662 Jan 19 19:30 xorg-x11-libs-
compat-6.8.2-1.EL.33.0.1.i386.rpm
-rw-r--r--. 1 root root 1026332 Jan 19 19:31 openmotif21-
2.1.30-11.el7.i686.rpm
-rw-r--r--. 1 root root 735261 Jan 20 15:12
12.2.0.51_startCD.txt
drwxr-xr-x. 3 oracle dba 4096 Jan 20 16:32 app
drwxrwxrwx. 7 root root 4096 Jan 25 17:26
oraInventorybkp
drwxrwxr-x. 8 oracle dba 4096 Feb 3 15:19 ora_ebs
drwxrwxrwx. 7 root root 4096 Feb 13 18:34
oraInventory
drwxr-xr-x. 2 oracle dba 4096 Feb 14 15:12 data
drwxrwxr-x. 2 kiran dba 4096 Feb 21 17:56 kiran
drwxrwxr-x. 10 applmgr dba 4096 Mar 28 12:55 appl_ebs
drwxrwxrwx. 7 oracle dba 4096 Mar 28 13:41 oracle
drwx------. 12 applmgr dba 4096 Mar 28 15:08 applmgr
[applmgr@r12 u01]$ cd ora_Ebs
-bash: cd: ora_Ebs: No such file or directory
[applmgr@r12 u01]$ cd ora_ebbs
-bash: cd: ora_ebbs: No such file or directory
[applmgr@r12 u01]$ ls
12.2.0.51_startCD.txt openmotif21-2.1.30-
11.el7.i686.rpm
app oracle
appl_ebs ora_ebs
applmgr oraInventory
compat-libstdc++-296-2.96-144.0.2.el7.i686.rpm
oraInventorybkp
data xorg-x11-libs-compat-6.8.2-
1.EL.33.0.1.i386.rpm
kiran
[applmgr@r12 u01]$ pwd
/u01
[applmgr@r12 u01]$ cd appl_ebs
[applmgr@r12 appl_ebs]$ ls
21841299 fs_ne
p3636980_R12_GENERIC.zip
3636980 OPatch
p6880880_101000_LINUX.zip
EBSapps.env p20780171_1036_Generic.zip patch-
catalog_22958.xml
EJUW.jar p21830810_R12.TXK.C_R12_GENERIC.zip
README.txt
etcc-bundle p21841299_R12.AD.C_R12_LINUX.zip xxhs
fs1 p23577513_R12_LINUX.zip
fs2 p24658753_R12_LINUX.zip
[applmgr@r12 appl_ebs]$ EBSapps.env
bash: EBSapps.env: command not found...
[applmgr@r12 appl_ebs]$ . EBSapps.env

E-Business Suite Environment Information

----------------------------------------
RUN File System : /u01/appl_ebs/fs1/EBSapps/appl
PATCH File System : /u01/appl_ebs/fs2/EBSapps/appl
Non-Editioned File System : /u01/appl_ebs/fs_ne
 DB Host: r12.hasmansoft.com Service/SID: VIS

E-Business Suite Environment Setting

------------------------------------
- Enter [R/r] for sourcing Run File System Environment file,
or
- Enter [P/p] for sourcing Patch File System Environment
file, or
- Enter anything else to exit

Please choose the environment file you wish to source

[R/P]:R

Sourcing the RUN File System ...

[applmgr@r12 appl_ebs]$
[applmgr@r12 appl_ebs]$
[applmgr@r12 appl_ebs]$
[applmgr@r12 appl_ebs]$
[applmgr@r12 appl_ebs]$ adop -examples
Applications DBA Online Patching Tool (adop)

See Oracle E-Business Suite Maintenance Guide for a full

description of
adop features, operation, and usage.

Standard Online Patching Cycle:

In Oracle E-Business Suite Release 12.2, patches are

normally applied
using an online patching cycle. The online patching cycle
consists of
five phases which are executed in order.

Example - Typical online patching cycle:

source <ebs_root>/EBSapps.env run

adop phase=prepare
 adop phase=apply patches=123456
adop phase=finalize
adop phase=cutover
source <ebs_root>/EBSapps.env run
adop phase=cleanup

Note that after cutover the command line environment

should be re-loaded
as the run edition file system has changed.

In a multi-node deployment, adop commands are only

executed from the
primary node. The primary adop session uses remote
execution to
automatically perform required actions on any secondary
node.

Multiple phases can be executed in a single adop

command.
 Example - combined finalize/cutover/cleanup:

adop phase=finalize,cutover,cleanup

Prior to cutover, it is possible to execute additional

"apply" and "finalize" phases as needed.

Example - applying multiple patches using separate apply

commands:

source <ebs_root>/EBSapps.env run

adop phase=prepare
adop phase=apply patches=123456
adop phase=apply patches=223456
adop phase=finalize
adop phase=apply patches=323456
adop phase=finalize
adop phase=cutover
source <ebs_root>/EBSapps.env run
 adop phase=cleanup

Note that it is possible to apply additional patches after

running the
finalize phase, but if you do so then you will need to run
the finalize
phase again. Finalize must always be run immediately
prior to cutover.

General parameters applicable to all phases:

workers=<number> [default: computed]

Number of parallel workers used to execute tasks.
Default value is
computed principally according to number of available
CPU cores.

Example:
 adop phase=prepare workers=8

The example command executes the prepare phase with

8 parallel workers.
Not all processing can be executed with parallel
workers, and in such
cases the workers parameter is ignored. In multi-node
systems the
workers parameter indicates workers per node.

input_file=<file_name>
As well as being entered directly on the command line,
adop parameters
can be specified in a text file, with one
<parameter>=<value>
on each line of the file. Command line parameters
override input file
parameters.
 Example - Input File text "empty_cycle.txt" for empty
patching cycle:

phase=prepare,finalize,cutover,cleanup
workers=4
loglevel=statement

Example - Use input file to execute empty patching cycle:

adop input_file=empty_cycle.txt workers=1

The example command will execute an empty patching

cycle with a
single worker and maximum log detail.

loglevel=(statement|procedure|event|warning|error|
unexpected)
[default: event]
 Controls the level of diagnostic log detail displayed on
the
console output. Each log message is tagged with a level:
1) statement - internal debugging messages
2) procedure - internal procedure begin/end
messages
3) event - significant processing action
4) warning - important user message or possible
problem
5) error - a patching action has failed, processing
continues
6) unexpected - a critical action has failed, processing
halted
Setting loglevel will display messages at that level and
higher.

Example - Display full log details:

adop phase=prepare loglevel=statement

Example - Display only warnings and errors:

 adop phase=prepare loglevel=warning

prompt=(yes|no) [default: yes]

Specifies whether adop should prompt for user input on
warnings.
By default adop will ask user whether to continue or exit
on
some warning messages. If this parameter is set to "no"
adop
will remain fully non-interactive, and will continue past
any
warning messages without user confirmation.

Example - Disable user prompt for warnings:

adop phase=cutover prompt=no

Diagnostic Parameters, normally not used unless directed by
Support:

allowcoredump=(yes|no) [default: no]

Specifies whether adop should create a core dump if it
crashes. This
option should only be used if directed by support.

Example - Enable writing of core dump files:

adop phase=cutover allowcoredump=yes

analytics=(yes|no) [default: no]

Controls whether adop writes additional reports with
information
that might be helpful in some diagnostic situations. This
option
should not be used unless directed by Support.
 Example - Enable additional analytic reports

adop phase=finalize analytics=yes

defaultsfile=<file_name> [default: adalldefaults.txt]

Name of the response file providing default parameter
values for
non-interactive execution of adadmin and adop. The file
must be in
the $APPL_TOP/admin/$TWO_TASK directory in both
run edition and patch
edition file systems. The default file "adalldefaults.txt" is
maintained by AutoConfig and normally you should not
need to change
any values.

Example - Using a custom AD Defaults file:

adop phase=apply defaultsfile=adcustomdefaults.txt

Prepare Parameters:

skipsyncerror=(yes|no) [default: no]

Specifies whether to ignore errors that may occur during
incremental
file system synchronization. This might happen if you
applied
a patch in the previous patching cycle that had errors
but decided
to continue with the cutover. When the patch is
synchronized on
the next patching cycle, the apply errors may occur
again, but
can be ignored.

sync_mode=(delta|patch) [default: patch]

Specifies the method used to synchronize the patch file
system
with the run file system.
 'delta' mode uses the file system synchronization
command
specified in $AD_TOP/patch/115/etc/delta_sync_drv.txt.
'patch' mode reapplies the patches that were applied on
the run file system.

Example:

adop phase=prepare skipsyncerror=yes

sync_mode=delta

Apply Parameters:

apply=(yes|no) [default: yes]

Controls whether adop actually applies the patch. You
can specify
"apply=no" to run adop in test mode, where the patch
will not actually
 be applied, and adop will record what it would have
done in the log.

Example - Execute adop apply in test mode:

adop phase=apply apply=no patches=1234

patches=<patch#>[,<patch#>...]

patches=<patch_directory>:<driver>[,<patch_directory>:<dr
iver>...]
This parameter specifies a comma-separated list of
patches to be
applied. Patches can be specified either as the patch
number or
by the patch directory and driver file. All patches are
expected
to be in the $PATCH_TOP directory on all tiers. Patches
are applied
serially unless the merge=yes parameter is specified.
 Example - Apply two patches in series:

adop phase=apply patches=1234,5678

Example - Apply patch and its translation:

adop phase=apply
patches=1012464,10124646_AR:u10124646.drv

patchtop=<directory_name> [default: $PATCH_TOP]

Path to a user-specified directory where patches are
unzipped.
The default and recommend location is the $PATCH_TOP
directory
automatically created by the install. When using an
alternate
patchtop you must ensure that the location is not within
the
 editioned file systems (fs1, fs2) and is accessible by the
same
path for all nodes of a multi-node deployment.

Example - Apply patch from alternate patchtop

directory:

adop phase=apply patches=123456

patchtop=/install/patches

apply_mode=(online|downtime|hotpatch) [default:
online]
Use online mode to apply a patch to the patch edition
during an
online patching cycle; downtime mode to apply a patch
to the
run edition when application services are down; and
hotpatch
mode to apply a patch to the run edition when
application
 services are up. Only use hotpatch mode when explicitly
directed by documentation.

Example - apply a patch in downtime mode:

adop phase=apply patches=123456

apply_mode=downtime

In downtime mode, adop will validate that application

services
are shutdown before apply the patch. The patch will be
applied
to the run edition of the system. Downtime mode cannot
be used
if there is an online patching cycle in progress.

Example - apply a patch in hotpatch mode:

adop phase=apply patches=123456

apply_mode=hotpatch
 In hotpatch mode, adop will apply the patch to the run
edition
of the system while application services are still running.
Patches
that can be safely applied in hotpatch mode (such as NLS
and Online
Help patches) will document this in the patch readme.
Hotpatch mode
cannot be used if there is an online patching cycle in
progress.

merge=(yes|no) [default: no]

Indicates whether adop should merge a list of patches
before applying.
By default, adop will apply a list of patches serially in the
order
specified. You can also use AD Merge Patch to merge
multiple patches
ahead of the apply command.
 Example - Merge multiple patches before applying

adop phase=apply patches=1234,5678 merge=yes

In some cases it may be necessary to merge patches,

such as when
an additional patch corrects an installation issue in the
main patch.
If the merge parameter is required, this will be
documented in the
patch readme.

restart=(yes|no) [default: no]

Use restart=yes to resume the previous failed apply
command
from where processing terminated. If an apply
command fails,
check the log files for further information. If the
problem
 can be corrected, you can then restart the apply
command where
it left off using the restart parameter.

Example - Restart a apply command

adop phase=apply patches=123456 restart=yes

When restarting a failed apply it is important to use the

same parameters as the failed command, with only the
addition
of the restart=yes parameter.

abandon=(yes|no) [default: no]

Use abandon=yes to abandon the previous failed apply
command
and start a new apply command. Note that any changes
made
 to the system by the failed command will remain in
effect.
The abandon flag is most useful when applying a
replacement
patch for the failing patch.

Example - Abandon previous apply command and apply

replacement

adop phase=apply patches=223456 abandon=yes

If a patch fails to apply and there is no replacement

patch,
you may also abort the online patching cycle. See abort
phase
later in this text.

options=<patch_option>[,<patch_option>...]
Options can be specified in a comma-separated list to
control
 advanced features when a patch is applied. These
options are normally
not needed unless specified by documentation or
support. Note
that these options can be prefixed with "no", e.g.
"nocheckfile",
to disable the behavior, and for some options "no" is the
default.

checkfile - Skip running exec, SQL, and exectier

commands if they are recorded as already
run.
[default: checkfile]

compiledb - Compile invalid objects in the database

after running actions in the database driver.
[default: compiledb]

compilejsp - Compile out-of-date JSP files, if the

patch
has copy actions for at least one JSP file.
 [default: compilejsp]

copyportion - Run commands found in a copy driver.

[default: copyportion]

databaseportion - Run commands found in a database

driver.
[default: databaseportion]

generateportion - Run commands found in a generate

driver.
[default: generateportion]

integrity - Perform patch integrity checking

[default: nointegrity]

autoconfig - Run AutoConfig.

[default: autoconfig]
 actiondetails - Turn off display of action details.
[default: actiondetails]

parallel - Run actions that update the database or

actions that generate files in parallel.
[default: parallel]

prereq - Perform prerequisite patch checking

prior to
running patch driver files.
[default: noprereq]

validate - Connect to all registered Oracle E-

Business
Suite schemas at the start of patch
application.
[default: novalidate]

phtofile - Save patch history to file

[default: nophtofile]
 forceapply - Reapply a patch that has already been
applied.
Useful in combination with "nocheckfile"
option
to rerun files that have already been
executed.
[default: noforceapply]

Example - Apply patch again, force re-execution of driver

commands:

adop phase=apply patches=123456

options=forceapply,nocheckfile

This command will apply the patch again, and will

execute SQL, exec
and exectier actions even if they have already been
executed.
 flags=<patch_flag>[,<patch_flag>...]
Flags can be specified in a comma-separated list to
control advanced
features when applying a patch. Note that these flags
can be prefixed
with "no", e.g. "nologging", to disable the behavior and
for some
flags "no" is the default.

hidepw - Omit the "HIDEPW:" comments in the

log file.
[default: hidepw]

trace - Log all database operations to a trace file.

[default: notrace]

logging - Create indexes in LOGGING or

NOLOGGING mode.
[default: nologging]
 autoskip - To proceed with adpatch execution even
if some
driver actions failed. Failed actions are
recorded in a log file.
[default: noautoskip]

Example - Skip apply failures:

adop phase=apply patches=123456 flags=autoskip

preinstall=(yes|no) [default: no]

Allows a patch to be applied to the file system without
connecting
to the database. Do not use this parameter unless
directed by Oracle.

wait_on_failed_job=(yes|no) [default: no]

 Controls whether adop apply command exits when all
workers have
failed. Instead of exiting, you can force adop to wait, and
use
the "adctrl" to retry failed jobs.

printdebug=(yes|no) [default: no]

Controls whether to display additional debugging
information.

uploadph=(yes|no) [default: yes]

Controls whether to upload patch history information to
database after
applying the patch.

Finalize Parameters:
 finalize_mode=(full|quick) [default: quick]
Quick mode will provide the shortest execution time, by
skipping non-essential actions.
Full mode performs additional actions such as gathering
statistics that may improve performance after cutover.

Example - Perform additional optimizations during

Finalize:

adop phase=finalize finalize_mode=full

Using full mode after applying a major patch can help

maintain
optimal system performance.

Cutover Parameters:

mtrestart=(yes|no) [default: yes]

 Specifies whether to restart application tier servers after
cutover.
Leave at default unless you need to perform any manual
steps during
downtime.

Example - Perform downtime actions after cutover:

adop phase=cutover mtrestart=no

<Perform downtime steps>
adstrtal.sh

cm_wait=<minutes> [default: forever]

Specifies the number of minutes to wait for Concurrent
Manager
shutdown. Adop cutover starts by requesting a
concurrent manager
shutdown and then waits for in-progress requests to
complete.
 If Concurrent Manager does not shutdown within the
specified
time limit, remaining concurrent requests will be killed
and
cutover will proceed.

Example - cutover with maximum wait of 15 minutes:

adop phase=cutover cm_wait=15

Note that any concurrent requests killed during forced

shutdown
may need to be manually re-submitted after cutover. To
avoid
killing concurrent requests, schedule cutover at a time of
minimal user activity or manually shutdown Concurrent
Manager
in advance of cutover.
Cleanup Parameters:

cleanup_mode=(full|standard|quick) [default: standard]

Quick mode provides the shortest execution time, by
skipping non-essential actions.
Standard mode performs additional processing to drop
obsolete code objects from old editions.
Full mode performs additional processing to drop empty
database editions and unused table columns.

Example - Run quick cleanup for minimum delay to next

prepare:

adop phase=cleanup cleanup_mode=quick

Example - Run full cleanup for maximum space

recovery:

adop phase=cleanup cleanup_mode=full

Special Operations:

Cloning the Patch Edition File System:

The patch edition file system is normally synchronized
with the
run edition file system during the prepare phase. There
are some
cases where it is helpful or required to manually re-
clone the patch
edition file system from the run edition.

1) After aborting an online patching cycle.

2) After manually changing the run edition file system.
3) After patching middle-tier technology components.
4) After applying an EBS RUP.

By re-cloning the patch edition file system, you can be

certain that
 it is correctly synchronized, and also minimize any
synchronization
delay that would normally occur on the next prepare
command.

Example - Re-clone the patch edition file system:

adop phase=fs_clone

If there is any error you must examine log files and

correct the
problem, then restart the fs_clone by running the
command again.
If fs_clone does not restart correctly you can force the
process
to restart from the beginning.

Example - Restart failed fs_clone from the beginning:

adop phase=fs_clone force=yes

 Aborting an online patching cycle:
If an online patching cycle encounters problems that
cannot be
fixed immediately you can abort the patching cycle and
return
to normal runtime operation.

Example - Aborting a failed online patching cycle:

adop phase=prepare
adop phase=apply patches=123456
### serious unfixable error reported
adop phase=abort
adop phase=cleanup cleanup_mode=full
adop phase=fs_clone

The abort command drops the database patch edition

and
 returns the system to normal runtime state.
Immediately
following abort, you must also run a full cleanup and
fs_clone operation to fully remove effects of the failed
online patching cycle.

Dropping old database editions:

As online patching cycles are completed, the system will
build
up a number of old database editions. When the number
of old
database editions reaches about 25, you should consider
running
a special maintenance operation to drop old database
editions.

Example - Actualize_All and Full Cleanup:

adop phase=prepare
 adop phase=actualize_all
adop phase=finalize
adop phase=cutover
adop phase=cleanup cleanup_mode=full

Warning: This maintenance operation will take much

longer than a
typical online patching cycle, and should only be
performed when
there is no immediate need to start a new online
patching cycle.

The actualize all and full cleanup can be done separately

as shown
above, or can be executed in conjunction with an online
patching
cycle.

Example - Actualize_All and Full Cleanup combined with

patching:
 adop phase=prepare
adop phase=apply patches=123456
adop phase=actualize_all
adop phase=finalize
adop phase=cutover
adop phase=cleanup cleanup_mode=full

adop exiting with status = 0 (Success)

[applmgr@r12 appl_ebs]$

[applmgr@r12 adop]$ ls -lrt

total 24
drwxr-xr-x. 5 applmgr dba 4096 Feb 7 13:08 2
drwxr-xr-x. 12 applmgr dba 4096 Feb 13 14:19 3
drwxr-xr-x. 18 applmgr dba 4096 Feb 13 14:59 4
drwxr-xr-x. 5 applmgr dba 4096 Mar 24 10:27 5
-rw-r--r--. 1 applmgr dba 3009 Mar 30 09:51
CheckWLSAdminPwd.log
drwxr-xr-x. 10 applmgr dba 4096 Mar 30 10:05 6

[applmgr@r12 adop]$ cd 6
[applmgr@r12 6]$ ls -lrt
total 32
drwxr-xr-x. 3 applmgr dba 4096 Mar 27 09:29
20170327_092820
drwxr-xr-x. 2 applmgr dba 4096 Mar 27 09:59
20170327_095948
drwxr-xr-x. 2 applmgr dba 4096 Mar 30 09:43
20170330_094300
drwxr-xr-x. 2 applmgr dba 4096 Mar 30 09:43
20170330_094323
drwxr-xr-x. 3 applmgr dba 4096 Mar 30 09:51
20170330_095056
drwxr-xr-x. 2 applmgr dba 4096 Mar 30 09:51
20170330_095144
drwxr-xr-x. 2 applmgr dba 4096 Mar 30 09:53
20170330_095258
drwxr-xr-x. 2 applmgr dba 4096 Mar 30 10:05
20170330_100457

plmgr@r12 6]$ cd 20170327_092820

[applmgr@r12 20170327_092820]$ ls -lrt
total 16
drwxr-xr-x. 4 applmgr dba 4096 Mar 27 09:30 prepare
-rw-r--r--. 1 applmgr dba 11919 Mar 27 09:30 adop.log
[applmgr@r12 20170327_092820]$

drwxr-xr-x. 3 applmgr dba 4096 Mar 27 09:29 validate

drwxr-xr-x. 5 applmgr dba 4096 Mar 27 09:30 r12
[applmgr@r12 prepare]$ cd validate
[applmgr@r12 validate]$ ls -lrt
total 4
drwxr-xr-x. 3 applmgr dba 4096 Mar 30 09:49 r12
[applmgr@r12 validate]$ cd r12
[applmgr@r12 r12]$ ls -lrt
total 36
-rw-r--r--. 1 applmgr dba 0 Mar 27 09:29
txkADOPValidations.error
drwxr-xr-x. 4 applmgr dba 4096 Mar 27 09:29 validations
-rw-r--r--. 1 applmgr dba 19477 Mar 27 09:30
ADOPValidations_detailed.log
-rw-r--r--. 1 applmgr dba 3129 Mar 27 09:30
txkADOPValidations.log
-rw-r--r--. 1 applmgr dba 6038 Mar 30 09:50 adctrl.log

[applmgr@r12 20170330_095056]$ pwd

/
u01/appl_ebs/fs_ne/EBSapps/log/adop/6/20170330_0950
56
[applmgr@r12 20170330_095056]$ ls -lrt
total 24
drwxr-xr-x. 4 applmgr dba 4096 Mar 30 09:52 prepare
-rw-r--r--. 1 applmgr dba 18901 Mar 30 10:01 adop.log
total 28
-rw-r--r--. 1 applmgr dba 0 Mar 30 09:51
txkADOPValidations.error
drwxr-xr-x. 4 applmgr dba 4096 Mar 30 09:51 validations
-rw-r--r--. 1 applmgr dba 19747 Mar 30 09:52
ADOPValidations_detailed.log
-rw-r--r--. 1 applmgr dba 3129 Mar 30 09:52
txkADOPValidations.log

/
u01/appl_ebs/fs_ne/EBSapps/log/adop/6/20170330_0950
56/prepare/r12/TXK_SYNC_update/log

SQL> select * from dba_editions;

EDITION_NAME
------------------------------------------------------------------------------
--
PARENT_EDITION_NAME
------------------------------------------------------------------------------
--
USA
---
ORA$BASE

YES

V_20170330_0954
ORA$BASE
YES

EDITION_NAME
------------------------------------------------------------------------------
--
PARENT_EDITION_NAME
------------------------------------------------------------------------------
--
USA
SQL> select * from adop_Valid_nodes;

NODE_NAME
------------------------------------------------------------------------------
--
CONTEXT_NAME
--------------------------------------------------
ZD_EDITION_NAME ZD_SYNC
------------------------------ ------------------------------
r12
VIS_r12
SET1 INSERTED

OBJECT_NAME OBJECT_TYPE
OWNER
-------------------------------------------------- -----------------------
----------
AD_ADOP_SESSION_PATCHES# VIEW
APPLSYS
AD_ADOP_SESSION_PATCHES TABLE
APPLSYS
AD_ADOP_SESSION_ID_SEQ SEQUENCE
APPLSYS
AD_ADOP_SESSIONS_LOGS# VIEW
APPLSYS
AD_ADOP_SESSIONS_LOGS TABLE
APPLSYS
AD_ADOP_SESSIONS# VIEW
APPLSYS
AD_ADOP_SESSIONS TABLE
APPLSYS
ADOP_VALID_NODES_U1 INDEX
APPLSYS
ADOP_VALID_NODES# VIEW
APPLSYS
ADOP_VALID_NODES TABLE
APPLSYS
SSP_SHARED_ADOPTION_RESULTS PACKAGE
BODY APPS
SSP_SHARED_ADOPTION_RESULTS PACKAGE
APPS
SSP_SHARED_ADOPTION_PAY PACKAGE BODY
APPS
SSP_SHARED_ADOPTION_PAY PACKAGE
APPS
AD_ZD_ADOP PACKAGE BODY
APPS
AD_ZD_ADOP PACKAGE APPS
AD_ADOP_SESSION_PATCHES SYNONYM
APPS
AD_ADOP_SESSION_ID_SEQ SYNONYM
APPS
AD_ADOP_SESSIONS_LOGS SYNONYM
APPS
AD_ADOP_SESSIONS SYNONYM
APPS
ADOP_VALID_NODES= FUNCTION
APPS
ADOP_VALID_NODES+ TRIGGER
APPS
ADOP_VALID_NODES SYNONYM
APPS

23 rows selected.
SQL> desc applsys.AD_ADOP_SESSION_PATCHES#
Name Null? Type

------------------------------------------------------------------------------
----- -------- --------------------------------------------------------
ADOP_SESSION_ID NOT
NULL NUMBER
BUG_NUMBER NOT
NULL VARCHAR2(30)
PATCHRUN_ID
NUMBER
STATUS NOT NULL
VARCHAR2(1)
APPLIED_FILE_SYSTEM_BASE
VARCHAR2(512)
PATCH_FILE_SYSTEM_BASE
VARCHAR2(512)
ADPATCH_OPTIONS
VARCHAR2(4000)
APPLTOP_ID
NUMBER
NODE_NAME
VARCHAR2(256)
AUTOCONFIG_STATUS
VARCHAR2(1)
START_DATE
DATE
END_DATE
DATE
CLONE_STATUS
VARCHAR2(30)
PATCH_TOP
VARCHAR2(250)
DRIVER_FILE_NAME
VARCHAR2(50)
SESSION_TYPE
VARCHAR2(20)
SQL> desc ad_adop_session_patches
Name Null? Type

------------------------------------------------------------------------------
----- -------- --------------------------------------------------------
ADOP_SESSION_ID NOT
NULL NUMBER
BUG_NUMBER NOT
NULL VARCHAR2(30)
PATCHRUN_ID
NUMBER
STATUS NOT NULL
VARCHAR2(1)
APPLIED_FILE_SYSTEM_BASE
VARCHAR2(512)
PATCH_FILE_SYSTEM_BASE
VARCHAR2(512)
ADPATCH_OPTIONS
VARCHAR2(4000)
APPLTOP_ID
NUMBER
NODE_NAME
VARCHAR2(256)
AUTOCONFIG_STATUS
VARCHAR2(1)
START_DATE
DATE
END_DATE
DATE
CLONE_STATUS
VARCHAR2(30)
PATCH_TOP
VARCHAR2(250)
DRIVER_FILE_NAME
VARCHAR2(50)
SESSION_TYPE
VARCHAR2(20)

SQL> select node_name,context_name from

adop_Valid_nodes;

NODE_NAME
------------------------------------------------------------------------------
------------------------------------------------------------------------
CONTEXT_NAME
--------------------------------------------------
r12
VIS_r12