I recently built a fresh Oracle E-Business Suite 12.2.15 environment from the OCI Marketplace image, following Oracle's installation document (KB849587). The services came up cleanly. The problem appeared the first time I tried to prepare for patching.
The symptom
When I sourced the environment file and chose the patch file system, it failed immediately:
Please choose the environment file you wish to source [R/P]:P
Sourcing the PATCH File System ...
ERROR: This env should be sourced from apps !
[oracle@ebsdemo12-2-15 ~]$
The application was up and running, so the environment itself was healthy. Only the patch file system would not source.
Background: two file systems
EBS 12.2 uses online patching with two application file systems, a run file system and a patch file system. When you source the environment file, you choose which one you want:
- R sets up the environment for the run file system, which is what users are connected to.
-
P sets up the environment for the patch file system, which
adopneeds before you apply a patch.
If the patch file system won't source, you can't start a patching cycle.
What fixed it
I ran AutoConfig directly against the patch file system's context file, from the AD_TOP/bin directory:
perl adconfig.pl contextfile=/u01/install/APPS/fs2/inst/apps/EBSDB_apps/appl/admin/EBSDB_apps.xml
Once AutoConfig finished, I sourced the environment file again, chose P, and the patch environment loaded normally.
Why it happens
The error is raised by the environment-sourcing logic, before any patch is involved. So this is an environment configuration problem, not a patch problem.
AutoConfig regenerates the environment and configuration files for a file system from its context file. Running it against the patch file system's context file was the only change I made, and it resolved the error. The most likely cause is that the environment files for the patch file system were stale or incomplete after the initial build, while the run file system had been fully configured.
A Marketplace environment is provisioned onto a new host, so the two file systems don't necessarily get configured at the same time. I haven't proven this from the internals, so treat it as the most likely explanation and verify it on your own system with the checks below.
How to check your own system
-
Rule out the simple cause. Run
whoamiandls -ldon the patch file system directory. If your install uses a separate application OS user, make sure you are sourcing as that user. - Compare the context files. Check that key values, such as the hostname, match between the run and patch context files:
grep -i s_hostname <run context file>
grep -i s_hostname <patch context file>
-
Check the AutoConfig log. After the run, look in the patch file system's
admin/logdirectory for a cleanadconfig.log. - Compare file timestamps. Look at the environment files in the patch file system before and after the run to see what AutoConfig regenerated.
What I learned
-
Read the error as an environment problem. The message appears before
adopstarts, so look at the file system's configuration first. - Run AutoConfig on both file systems. On a new or cloned environment, I now treat this as a pre-patching checklist item, not just a fix for when something breaks.
- Don't force the environment. Regenerating it from the context file is cleaner than editing generated files by hand.
Have you hit this error on a Marketplace or cloned EBS environment? I'd like to know whether the cause was the same.
Kumaran Murugan is an Oracle Apps DBA and OCI Cloud Administrator with 5+ years of experience in Oracle E-Business Suite, database migrations, and OCI infrastructure. Connect on LinkedIn.
Top comments (0)