If you are not in an online patching cycle, you can only connect to the database run edition from the run filesystem fs1 in your current case. If you source the patch edition outside of an online patching cycle, you get the following message:
SQL*Plus: Release 10.1.0.5.0 - Production on Sun May 6 10:12:05 2018
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ORA-00604: error occurred at recursive SQL level 1
ORA-20099: E-Business Suite Patch Edition does not exist.
ORA-06512: at line 29
If you have started an online patching cycle, a patch edition is created in the database, which is the construct that allows you to patch the database patch edition, run autoconfig successfully etc, while users are processing transactions in the run edition of the database. When you have completed your patching and are ready to cutover, the applications are shutdown and the patched patch edition becomes the new run edition, and the filesystem fs2 becomes the new run filesystem. After the next patching cycle completes, it cycles back to fs1.
I asked this because everytime we undergo patching cycles, the programmers is complaining their packages, or triggers seems dropped and created in another schema? or maybe something is messed up while they are compiling programs?
I also see this patching cycle process, of dropping objects?
And there are 3 types of database edition? Maybe the programmers packages/triggers are misplaced in one of this editions?
Maybe your developers are not creating editions enabled custom code, or it is only being deployed to the run edition.
Creating a Custom Application in Oracle E-Business Suite Release 12.2 (Doc ID 1577707.1)
You should be bundling up your code migrations and load them at the end of an apply session in an adop patching cycle to ensure they get loaded properly.
For migrating the code how you are following the patching cycle? Is it normal patching cycle or hot code migration.
Thanks Micheal and Prasant,
The programmers did not create new BOL_TOP, but they just reuse the APPS schema to create custom codes (packages/triggers).
Is this not the right way of doing it?
Is it my fault as appsdba for not creating a CUSTOM_TOP? or the programmers fault?****For migrating the code how you are following the patching cycle? Is it normal patching cycle or hot code migration.I usually do normal patching cycle, but sometimes hot patch as well (but not often)
Database data objects such as tables, indexes, and sequences should be created in CUSTOM Schema
Database code objects such as packages, functions, procedures and triggers must be created in the APPS schema
If you are just having custom objects then you may not create Custom application, though recommended.
which all custom objects vanish
Always having a CUSTOM_TOP its good to have, so that you can identify the files. Yes all the custom objects needs to go under apps schema.
You can apply the code using two ways -
1. Open a patch cycle and apply the code.
2. Apply the code on hot mode and later you run fs_clone.
MOS - Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2 (Doc ID 1577661.1)
Thanks Prasant, Pravin, Michael and ALL,