The online patching cycle is divided into five phases:
Patching Cycle Overview
The key actions in the various stages of the online patching cycle can be summarized as follows
- Synchronizes patch edition and run edition on the file system.
- Creates a new patch edition in the database.
- Executes patch drivers to update patch edition.
- Patches applied: can be one or many, including customizations.
- Compiles invalid objects.
- Generates derived objects.
- 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.
Delete obsolete code and seed data to recover space.
Each of the phases will now be discussed in more detail
On the file system:
The following actions are taken in this phase. On the file system
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.
By default, synchronization is incremental: that is , only files that were changed in the last patch application are copied.
In the 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
(have a new definition created) in that edition.
Storage objects (such as transaction tables) are not copied
The following actions are taken in this phase:
- Patches are applied to the patch edition. During this process, any changed stub objects will become actual code objects in the patch edition.
- The changes introduced by the patches are made in the isolation of the patch edition
Changes to code objects are only visible in the patch edition of the file system and database.
Changes to tables are stored in new columns or rows that are only visible to the patch edition.
At this point, users still remain connected to the application and performing their work.
This phase is used to perform the final operations that can be executed while the application is online:
- 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.
This phase involves:
- 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.
A restart of application tier services on the new run edition.Although the cutover phase does require a short period of application tier services downtime, the online patching cycle can be paused for as long as required prior to running this phase. You could, for example, add such a pause to ensure that the downtime period will be outside business hours.
The database remains open throughout the entire online patching cycle, including cutover.
The following database actions are taken in this phase, which occurs after users have been brought back online to the newly-patched application:
- Old code objects that are no longer visible in the run edition are dropped.
2. Old data (rows or columns) that are no longer visible in the run edition is deleted or dropped.
3. Old database editions that no longer contain actual objects are dropped.