Application Containers
Lab 2: Upgrade from v1 to v2
Overview
In this lab we upgrade Application wmStore from v1 to v2. Despite each franchise having a
separate tenant PDB, there is only one master application definition to be upgraded
– in Application Root. We run the upgrade script only once, against the
Application Root. It is then simply a matter of synchronizing the tenant PDBs
for each franchise for them to be upgraded to the new version. Note that this
model allows for granular (per tenant/franchise) upgrade schedules. Let's get
started!
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>@02.Upgrade_v1_v2.sql
Review of Application Container Lab2:
In this lab, we have worked through the following stages:
1. Upgrade application wmStore to v2.
2. Synchronize all Application Tenant PDBs.
An important advantage of Multitenant, with Application Containers is that, as we've seen, we have the opportunity to upgrade individual tenants / franchises on their own schedule if appropriate. This demonstrates how Multitenant with Application Containers allows an Application administrator to manage many tenants as one, but retain granular control when appropriate.
Detailed Steps
Phase 1: Upgrade Application.
Phase 1a: -- Begin the master application upgrade.
Connect to the common user / application schema owner – wmStore_Admin. Notice that the version is expressed as a character string. What now follows is the standard upgrade script for the application. Note that this is basically unchanged from the application upgrade script that would have been run for a standalone installation in a non-CDB.
Phase 1b: Upgrade Schema.
Phase 1c: Upgrade Seed Data.
In the preceding section we upgraded the master application definition in our application root, wmStore_Master, from v1 to v2. This process started with the statement:
alter
pluggable database application wmStore
begin upgrade '1.0' to '2.0'
/
Following this we had a standard application upgrade script. We now have to designate the end of the master application upgrade.
Phase 1d: End the master application upgrade.
With Application Container, we only need to upgrade the application once. Tenant (franchise) PDBs are simply "sync'ed" with this master definition. This is simply a matter of connecting to each tenant (franchise) PDB in turn and issuing the sync command. Let's do that now.
Phase 2. Sync Application PDBs for three of four franchises.
We have now synchronized the application definition in three of the four tenant (franchise) PDBs with the master definition. Franchise NYC has not yet upgraded. Let's confirm that there are now different application versions in use. To do this, we'll connect to one franchise that has upgraded, and look at definition of a table changed in the upgrade. Then, we'll connect to the franchise that has not upgraded, and confirm that the old table definition is still in effect there.
· First, connect to Franchise Tulsa and look at the table definition there.
Show definition of table wm_Products.
· Now, connect to Franchise NYC and look at the table definition there.
Show definition of table wm_Products.
Phase 3: Queries
Show definition of table wm_Products in &Franchise. Notice that Tulsa has the new column Local_Product_YN, added during the upgrade to v2.0. Now let's switch to NYC, and look at the definition of wm_Products there. Notice that NYC does not have the new column Local_Product_YN, because this franchise / tenant has not yet upgraded to v2.0. This is an important advantage of Multitenancy with Application Container. It is not necessary to enforce a simultaneous business-wide application upgrade. Tenants / franchises can upgrade on an individual schedule if necessary.
Click Here to Go to Lab 3