Upgrade in same database but with separate schemas
Hi all! We are considering two approaches to upgrading our application. We want to do the upgrade with one database but are not sure on the best way to handle it. Since work will still be happening during the upgrade we thought to create new schemas in the same database and perform the upgrade on those copied schema. Any opinions or guidance is highly appreciated!
Existing Data Schema
APP_RULE_DEV
APP_DATA_DEV
Create new rules and data Schema
NAPP_RULE_DEV (Copy data from APP_RULE_DEV)
NAPP_DATA_DEV (Copy data from APP_DATA_DEV)
This is from 7.4 to 8.5.4
Oracle Database
First Approach:
We are copying the rules schema and data schema to new schemas in the same database. We are planning on upgrading on the new schemas like it is an in-place upgrade.
What are the risks with doing the upgrade this way?
I believe this would be using the upgrade.sh and setupDatabase.properties files only as opposed to using the temporary schema and migration files.
Second Approach:
Create blank temp rule schema (would be dropped after upgrade)
NAPP_RULE_TEMP
Property File Update
=====================
Hi all! We are considering two approaches to upgrading our application. We want to do the upgrade with one database but are not sure on the best way to handle it. Since work will still be happening during the upgrade we thought to create new schemas in the same database and perform the upgrade on those copied schema. Any opinions or guidance is highly appreciated!
Existing Data Schema
APP_RULE_DEV
APP_DATA_DEV
Create new rules and data Schema
NAPP_RULE_DEV (Copy data from APP_RULE_DEV)
NAPP_DATA_DEV (Copy data from APP_DATA_DEV)
This is from 7.4 to 8.5.4
Oracle Database
First Approach:
We are copying the rules schema and data schema to new schemas in the same database. We are planning on upgrading on the new schemas like it is an in-place upgrade.
What are the risks with doing the upgrade this way?
I believe this would be using the upgrade.sh and setupDatabase.properties files only as opposed to using the temporary schema and migration files.
Second Approach:
Create blank temp rule schema (would be dropped after upgrade)
NAPP_RULE_TEMP
Property File Update
=====================
1) migrateSystem.Properties (Migrate rule schema)
Source rule schema NAPP_RULE_DEV
Source data schema NAPP_DATA_DEV
Target rule schema NAPP_RULE_TEMP
Target data schema
2) setupDataBase.Properties (Upgrade rule schema)
rule schema NAPP_RULE_TEMP
data schema NAPP_RULE_TEMP
3) setupDataBase.Properties (Upgrade data schema)
rule schema NAPP_RULE_TEMP
data schema NAPP_DATA_DEV
Upgrade Execution Steps
=======================
Out of place (Upgrading with one database)
a) Migrating the rules tables with one database
nohup ./migrate.sh &
b) Upgrading the rules schema
nohup ./upgrade.sh &
c) Upgrading the data schema
nohup ./upgrade.sh & --dataOnly true
Post Upgrade
==============
- Truncate/empty NAPP_RULE_DEV
- Copy NAPP_RULE_TEMP into NAPP_RULE_DEV
- Drop NAPP_RULE_TEMP
Citicorp Services India Private Limited
IN
Hi @Benneal92,
It depends on how we want the upgrade to be executed
1. In Place Upgrade - the limitation with this approach is it will take long time for upgrade and more down time is required.
2. Out of Place Upgrade - Advantage with this method is downtime shall be reduced. and from database point of view we need to do more tasks such creating temporary schema to copy rules and upgrade.
The following community link shall help more on this.
Thanks,
Pegasystems Inc.
AU
@Benneal92 The risk with your First Approach is that, once you copy the Rules and Data schemas, if there are any changes to the Rules/data in original schemas, you will have to copy the "delta" data post upgrade into the new schemas. Else you will have to take full downtime from the time you start making the copy.
Pega usually recommends the out-of-place Rules schema upgrade and in-place data schema upgrade, where you make a copy of the Rules schema and upgrade the copy (make sure there are no Rule changes after the copy is made, if there are, create a RAP of the changes, that can be applied after upgrade). The original data schema is then upgraded in-place, so that you dont have to deal with "delta" data migration. Your downtime is only when the Data schema upgrade is in progress. If you are upgrading from 8.4.2 and above, you can make use of zero downtime upgrades, explained here https://community.pega.com/knowledgebase/articles/keeping-current-pega/86/premises-upgrade-process-pega-infinity-release-842-and-later-other-application-servers-and-databases
If you can afford a large downtime, then the easiest option is in-place upgrade. Please ensure you make a DB backup before starting any activities, so that you can revert back, if you run into any challenges.