Question
CYBG
GB
Last activity: 28 May 2019 1:28 EDT
6.1 to 7.4 Upgrade - missing step in Upgrade documentation?
We are intending to upgrade a PRPC application from 6.1 SP2 to 7.4. In the "Pega74-upgrade_0.pdf" (downloaded from the PDN) it says that for single-to-split schema upgrade, we need to do the following:
- If we upgrade with two DBs, we run the following in order: migrate.bat, upgrade.bat, migrate.bat (again), upgrade.bat (again, with "--dataonly true").
- If we upgrade with one DB, we run the following in order: migrate.bat, upgrade.bat, upgrade.bat (again, with "--dataonly true"), i.e. we omit the second run of migrate.bat.
Is this correct? Or is this step missing by accident?
***Edited by Moderator Marissa to update SR Details***
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Pegasystems Inc.
IN
Hello!
On reviewing the SR we see that it is resolved by performing the below steps.
Hello!
On reviewing the SR we see that it is resolved by performing the below steps.
- Ensure you have a the database backup, ensure you have a core admin user
- Change the system name to “prpc”
- Create a new Oracle RULES schema (same database)
- Migrate the rules to the new schema
- Generate the Upgrade SQL for the Rules schema
- Modify the SQL
- Apply SQL directly to the scheme (sqlplus)
- Run the Rules schema upgrade
- Run the Data schema upgrade
- Run the additional SQL against each schema (this is necessary on 6.1SP2 system upgrades REF: https://community.pega.com/knowledgebase/documents/pega-731-platform-upgrade-guide Pg 86)
Thank you,
Pegasystems Inc.
IN
Hi,
It can be little confusing, but I will try to explain what going on here.
For scenario in which you created two new schema PEGA74DATA and PEGA74RULES
- If we upgrade with two DBs, we run the following in order: migrate.bat, upgrade.bat, migrate.bat (again), upgrade.bat (again, with "--dataonly true").
Here migrate.bat (for Rules migration) followed by upgrade.bat (for Rules upgrade). Then migrate.bat(for moving tables from 6.3 schema to a new schema you would have created for 7.4 data schema) and finally upgrade.bat(for upgrading on the migrated schema i.e., 7.4 data schema)
For scenario in which you created one new schema PEGA74RULES and would use the old PEGA63 schema for data
- If we upgrade with one DB, we run the following in order: migrate.bat, upgrade.bat, upgrade.bat (again, with "--dataonly true"), i.e. we omit the second run of migrate.bat.
Here migrate.bat (for Rules migration) followed by upgrade.bat (for Rules upgrade). Now you omit the migrate if you still want to continue the schema of 6.3 schema as it still has the data (NOTE: till now in this step you have done only rule migrate and upgrade). So since you want to continue with the same schema you can run the upgrade.bat on 6.3 schema.
I did this long back, so attaching the upgrade script I followed. You can refer this, it should help clear your doubts.
Hi,
It can be little confusing, but I will try to explain what going on here.
For scenario in which you created two new schema PEGA74DATA and PEGA74RULES
- If we upgrade with two DBs, we run the following in order: migrate.bat, upgrade.bat, migrate.bat (again), upgrade.bat (again, with "--dataonly true").
Here migrate.bat (for Rules migration) followed by upgrade.bat (for Rules upgrade). Then migrate.bat(for moving tables from 6.3 schema to a new schema you would have created for 7.4 data schema) and finally upgrade.bat(for upgrading on the migrated schema i.e., 7.4 data schema)
For scenario in which you created one new schema PEGA74RULES and would use the old PEGA63 schema for data
- If we upgrade with one DB, we run the following in order: migrate.bat, upgrade.bat, upgrade.bat (again, with "--dataonly true"), i.e. we omit the second run of migrate.bat.
Here migrate.bat (for Rules migration) followed by upgrade.bat (for Rules upgrade). Now you omit the migrate if you still want to continue the schema of 6.3 schema as it still has the data (NOTE: till now in this step you have done only rule migrate and upgrade). So since you want to continue with the same schema you can run the upgrade.bat on 6.3 schema.
I did this long back, so attaching the upgrade script I followed. You can refer this, it should help clear your doubts.
Don't follow it as a guide, its an old file I don't remember if I made some mistake while writing everything.
But the concept of those two steps is what I explained above.
Hope this helps.
Thank You
-
Susmita Deb
CYBG
GB
Thank you Shekhar. This makes sense. I will try using the three-step method (migrate/upgrade/upgrade) in a test region and see how it goes.
CYBG
GB
Hi Shekhar,
I have tried both methods in your instructions. Unfortunately both failed - the first way refused to run step 3, and the second appeared to run correctly but afterwards the application could not be started due to missing tables in the DB, i.e. the scripts had not copied everything.
I will continue to investigate different combinations of settings and let you know the correct ones when (if) I find them. In the meantime, may I suggest that the upgrade guides be improved to be less confusing? I am sure I am not the only person who has found the descriptions less than clear!
Cheers,
Mike.
Pegasystems Inc.
US
Hi Mike,
The upgrade steps depends on the various factors like single/split schema, single user/dual user, UI/Command-line approach,..so on. So to cover all these approaches into a single document its always a challenging task for the documentation team. But if we are clear with our approach at the initial stage then we can go through the document accordingly to make it little easier. By the way may i know what kind of upgrade approach you are planning to do?
- Single to Split schema? If yes, are you planning to use your 6.x schema as the data schema for 7.x system or you would prefer to create the separate schema for data schema?
- Command line approach or GUI approach? GUI approach is bit user friendly than Command line.
- Single user or dual user configuration?
- Which Database vendor and Application Server?
This information might help us to understand your approach.
Regards,
Mahesh M
CYBG
GB
Hi Mahesh,
We have raised an SR with Pega to address this issue. Many thanks for your help to date,
Mike.
Pegasystems Inc.
US
Hi Mike!
Could you let us know the SR ID so that we may track this for you?
Thanks!
CYBG
GB
Hi Marissa,
It's SR-C95009.
Accepted Solution
Pegasystems Inc.
IN
Hello!
On reviewing the SR we see that it is resolved by performing the below steps.
Hello!
On reviewing the SR we see that it is resolved by performing the below steps.
- Ensure you have a the database backup, ensure you have a core admin user
- Change the system name to “prpc”
- Create a new Oracle RULES schema (same database)
- Migrate the rules to the new schema
- Generate the Upgrade SQL for the Rules schema
- Modify the SQL
- Apply SQL directly to the scheme (sqlplus)
- Run the Rules schema upgrade
- Run the Data schema upgrade
- Run the additional SQL against each schema (this is necessary on 6.1SP2 system upgrades REF: https://community.pega.com/knowledgebase/documents/pega-731-platform-upgrade-guide Pg 86)
Thank you,