Want to know what happens in each phase of Patching Cycle in R12.2 here you go..
Before want to know about the something on phases:
In traditional patching, application of a patch is a single logical operation. In online
patching, it can be thought of as a series of related steps:
1. A copy is made of the code of the running system that resides in both the file system and database.
2. Patches are applied to the copy while users continue to access the running system.
3. The copy becomes the new running system.
4. The original running system (now obsolete) is recycled for use in future patching cycles.
The key actions in the various stages of the online patching cycle can be summarised as follows:
Prepare phase:
• Synchronizes patch edition and run edition on the file system.
• Creates a new patch edition in the database.
Apply phase:
• Executes patch drivers to update patch edition.
• Patches applied: can be one or many, including customizations.
Finalize Phase:
• Compiles invalid objects.
• Generates derived objects.
Cutover Phase:
• Configures patch edition file system to be the new run edition file system.
• Configures patch edition of database to be the new run edition.
• Restarts application tier services.
Cleanup Phase:
• Delete obsolete code and seed data to recover space.
Let's go in detail of each phase:
Prepare:
1. The patch file system is synchronized with the run file system.
2. The patch edition files become an exact copy of the run edition files.
Note: By default, synchronization is incremental: that is, only files that were changed in the last patch application are copied.
In Database:
1. A patch edition is created in the database.
3. As patches are applied to the patch edition, code objects are actualized (have a new definition created) in that edition.
Note:
The three types of database edition are:
• Run: Online users connect to this edition, which is always the default database edition. The run edition will always exist.
• Patch: Patching tools connect to this edition. A child of the run edition, the patch edition exists only while a patching cycle is in progress.
Apply:
1. Patches are applied to the patch edition. During this process, any changed stub objects will become actual code objects in the patch edition.
2. The changes introduced by the patches are made in the isolation of the patch edition.
3. Changes to code objects are only visible in the patch edition of the file system and database
4. Changes to tables are stored in new columns or rows that are only visible to the patch edition.
Note: At this point, users still remain connected to the application and performing their work.
Finalize:
This phase is used to perform the final operations that can be executed while the application is online:
1. Invalid objects are compiled.
2. Derived objects are generated.
3. Any actions that must be performed at cutover are pre-computed and stored for quick execution at that time.
Cutover:
1. Shutdown of application tier services
2. Execution of any required cutover actions to maintain non-editioned objects and data.
3. Configuration of the patch edition of the file system as the new run edition
4. Configuration of the patch edition of the database as the new run edition
5. Restart of application tier services on the new run edition.
Note: The database remains open throughout the entire online patching cycle, including cutover
Cleanup:
The following database actions are taken in this phase, which occurs after users have been brought back online to the newly-patched application:
1. Old code objects that are no longer visible in the run edition are dropped.
2. Old data (rows or columns) that is no longer visible in the run edition is deleted or dropped.
3. Old database editions that no longer contain actual objects are dropped.
Before want to know about the something on phases:
In traditional patching, application of a patch is a single logical operation. In online
patching, it can be thought of as a series of related steps:
1. A copy is made of the code of the running system that resides in both the file system and database.
2. Patches are applied to the copy while users continue to access the running system.
3. The copy becomes the new running system.
4. The original running system (now obsolete) is recycled for use in future patching cycles.
Two complete file systems are always present in an Oracle E-Business Suite Release 12.2 system. the run file system is the one currently in use by the running application, while the patch file system is the either being patched or awaiting the start of the next online patching cycle. In other words, the two file systems swap roles with every online patching cycle.
In the database, there is also a run edition and patch edition, but they do not swap roles back and forth as in the file system: the patch edition only comes into existence during a patching cycle, and becomes the new run edition at the end of the cycle. The former database run edition (the old edition) and the obsolete objects it contains are discarded at the end of an online patching cycle, and the space reclaimed during the cleanup phase
The key actions in the various stages of the online patching cycle can be summarised as follows:
Prepare phase:
• Synchronizes patch edition and run edition on the file system.
• Creates a new patch edition in the database.
Apply phase:
• Executes patch drivers to update patch edition.
• Patches applied: can be one or many, including customizations.
Finalize Phase:
• Compiles invalid objects.
• Generates derived objects.
Cutover Phase:
• Configures patch edition file system to be the new run edition file system.
• Configures patch edition of database to be the new run edition.
• Restarts application tier services.
Cleanup Phase:
• Delete obsolete code and seed data to recover space.
Let's go in detail of each phase:
Prepare:
1. The patch file system is synchronized with the run file system.
2. The patch edition files become an exact copy of the run edition files.
Note: By default, synchronization is incremental: that is, only files that were changed in the last patch application are copied.
In Database:
1. A patch edition is created in the database.
2. All code objects in the patch edition begin as pointers to code objects in the run edition. Code objects in the patch edition begin as lightweight "stub objects" that point to the actual object definitions, which are inherited from earlier editions. Stub objects consume minimal space, so the database patch edition is initially very small in size.
3. As patches are applied to the patch edition, code objects are actualized (have a new definition created) in that edition.
Note:
Creating a copy of the database part of the running system has been accomplished by taking advantage of the Oracle Database 11g R2 Edition-Based Redefinition (EBR) feature.
The three types of database edition are:
• Run: Online users connect to this edition, which is always the default database edition. The run edition will always exist.
• Patch: Patching tools connect to this edition. A child of the run edition, the patch edition exists only while a patching cycle is in progress.
• Old: When a patch edition is promoted to be the run edition, the previous run edition is now regarded as an old edition. There may be zero or more old editions at a given time. They are discarded when a full cleanup (described later) is performed. You cannot connect to an old edition.
Apply:
1. Patches are applied to the patch edition. During this process, any changed stub objects will become actual code objects in the patch edition.
2. The changes introduced by the patches are made in the isolation of the patch edition.
3. Changes to code objects are only visible in the patch edition of the file system and database
4. Changes to tables are stored in new columns or rows that are only visible to the patch edition.
Note: At this point, users still remain connected to the application and performing their work.
Finalize:
This phase is used to perform the final operations that can be executed while the application is online:
1. Invalid objects are compiled.
2. Derived objects are generated.
3. Any actions that must be performed at cutover are pre-computed and stored for quick execution at that time.
Cutover:
1. Shutdown of application tier services
2. Execution of any required cutover actions to maintain non-editioned objects and data.
3. Configuration of the patch edition of the file system as the new run edition
4. Configuration of the patch edition of the database as the new run edition
5. Restart of application tier services on the new run edition.
Note: The database remains open throughout the entire online patching cycle, including cutover
Cleanup:
The following database actions are taken in this phase, which occurs after users have been brought back online to the newly-patched application:
1. Old code objects that are no longer visible in the run edition are dropped.
2. Old data (rows or columns) that is no longer visible in the run edition is deleted or dropped.
3. Old database editions that no longer contain actual objects are dropped.
