Recreates the patch edition file system as an exact copy of the run edition file system.
It is a stand-alone command used for file system cloning.
It can be used to synchronize the run and patch file systems.
It must be run from run file system and before the next prepare phase is run.
It is useful if the APPL_TOPs have become very unsynchronized.
It is a heavyweight process, taking a backup of the entire current patch APPL_TOP and then cloning the run APPL_TOP to create a new patch APPL_TOP.
As well as being resource-intensive, this method is very time-consuming and requires several manual actions by the user.therefore be used only when necessary.
It can be re-run with option force=yes to restart from begining with same session id and force=no , startr from where it left.
It is an alternate to PREPARE phase.
PREPARE Vs fs_clone
fs_clone from Run File System(or) phase=apply from patch File system , is both does the same task?
PREPARE phase only synchronizes APPL_TOP or application stack so if you have applied any patches using adpatch or adop then PREPARE will synchronize that as well. But the important point to note is that PREPARE phase does not synchronize Technology Stack so if you have applied any Tech stack patches using OPatch or Smart update then PREPARE phase will not sync that. So please note that if you applied tech stack patches on run file system instead of patch file system and if you start another online patching cycle without doing fs_clone then all your technology patches could be lost as your patch file system did not contain these patches and once you do cutover and fs_clone in new patching cycle, it will overwrite old run file system with patch file system.
It is a stand-alone command used for file system cloning.
It can be used to synchronize the run and patch file systems.
It must be run from run file system and before the next prepare phase is run.
It is useful if the APPL_TOPs have become very unsynchronized.
It is a heavyweight process, taking a backup of the entire current patch APPL_TOP and then cloning the run APPL_TOP to create a new patch APPL_TOP.
As well as being resource-intensive, this method is very time-consuming and requires several manual actions by the user.therefore be used only when necessary.
It can be re-run with option force=yes to restart from begining with same session id and force=no , startr from where it left.
It is an alternate to PREPARE phase.
PREPARE Vs fs_clone
fs_clone from Run File System(or) phase=apply from patch File system , is both does the same task?
PREPARE phase only synchronizes APPL_TOP or application stack so if you have applied any patches using adpatch or adop then PREPARE will synchronize that as well. But the important point to note is that PREPARE phase does not synchronize Technology Stack so if you have applied any Tech stack patches using OPatch or Smart update then PREPARE phase will not sync that. So please note that if you applied tech stack patches on run file system instead of patch file system and if you start another online patching cycle without doing fs_clone then all your technology patches could be lost as your patch file system did not contain these patches and once you do cutover and fs_clone in new patching cycle, it will overwrite old run file system with patch file system.
>>Prepare – Starts a new patching cycle.
>>Prepare phase internally runs fs_clone if it is not run in the previous patching cycle.
>>FS clone mode can be only executed when there is no active patching cycle going on in the system.
FS Clone might be needed to be executed some of the below scenarios.
The previous Online Patching cycle was aborted.
If we make any manual changes to the run edition file system
FMW or Middle-tier technology components are patched.
After applying a big application RUP patch.
Loss of patch edition file system or corruption.
Restart failed fs_clone from the beginning:
adop phase=fs_clone force=yes
Oracle E-Business Suite Release 12.2: Online Patching FAQ (Doc ID 1583902.1)
No comments:
Post a Comment