Application Containers
Lab 8: Application Patches
Overview
In Lab8 we define an application patch. Patches are comparable to the application upgrades that we've seen in previous labs, but there are three important differences.
- The types of operation that are allowed in a
patch are more limited. Essentially operations which are destructive are not
allowed, including:
- Drop a table, column, index, trigger...
- Create *or replace* view, package, procedure...
- Patches do not involve creation of Application Root Clones.
- Patches are not version-specific. This means that a single patch may be applied to multiple application versions.
Execution
- Open a terminal window
- Change directory to /u01/HOL/app_containers/
- source the environment. At command prompt execute source cdb1.env
- sqlplus /nolog
- At the SQL prompt execute SQL>@08.Patch_301.sql
Review of Application Container Lab8:
1. Define patch 301 for application wmStore.
a. Add column for financial quarter to wm_Orders.
b. Create a new index on wm_Orders.
c. Add more seed data to wm_List_of_Values.
d. Update data in wm_Orders to set the appropriate value for the newly added denormalized column.
2. Propagate the Upgrade to three franchises (but not to all).
Detailed Steps
Phase 1: Declare beginning of application patch.
Connected to Master Application Root Notice that patches are positive integers. (Compare this with upgrades, which are character strings.)
Phase 2. Upgrade the application schema.
Phase 3. Add more seed data to wm_List_of_Values.
Phase 4. Update orders to specify the appropriate financial quarter.
Remember the sequence of these operations. We shall refer to these in a future lab.
1. Add column wm_Orders.Financial_Quarter_Code.
2. Create index wm_Orders_M1 on wm_Orders.
3. Add rows to wm_List_of_Values
4. Update orders to specify the appropriate financial quarter.
The previous section included some standard DML (updates in this case) to change existing data in the normal course of an upgrade. One curiosity in this case is that the actual data to be updated is in the Application PDBs, not in Application Root. (Notice that no rows were updated by any of these update statements in Application Root.) These statements are captured in Application Root, and will be replayed in the Application PDBs for each tenant / franchise when they synchronize.
Phase 5. Declare the end of the patch definition.
We have now completed the definition of the application patch. As with upgrades, patches are defined in a "begin / end" block. Between the begin and end statements, the patch contains a typical set of SQL statements (both DDL and DML). We have also seen how the steps in the upgrade script are captured in Application Root, to be replayed subsequently in the Application PDBs as they are sync'ed. The patch is applied to the Application PDBs by synchronizing them. In this lab, we'll patch three franchises – Tulsa, California and Tahoe.
Phase 6. Sync Application PDBs for three franchises.
Do not patch NYC yet.
Click Here to Go to Lab 9