Best option to update prpc v7.1.5 to v7.1.9
Can you guys help me decide which way is best between In-Place and Out-of-place updates when we upgrade one ML to another in terms of effort required and also overall?
And also, is this (https://docs.pega.com/pega-719-platform-update-guide) document the right guide for the same?
Accepted Solution
Pegasystems Inc.
US
https://docs-previous.pega.com/pega-719-platform-upgrade-guide
I am not sure why you would want to migrate the temporary schema and not the actual rules schema from DEV to higher environments. The temporary schema (assuming you are using 2 database process that requires a tempoary schema) would not have any changes that you made in DEV after the upgrade.
There is a section in the upgrade guide called "Typical Enterprise Application Upgrade Process" which provides general guidelines for what you want to do. You would essentially migrate your rules schema from DEV to UAT, upgrade your data schema, test, and then migrate rules from UAT to production, upgrade data schema.
Pegasystems Inc.
US
Is your 7.1.5 environment a split schema or are you planning on moving to a split schema in 7.1.9? Is the 7.1.5 environment dev which can be down for a period of time during the update or a production environment that you want to keep up as long as possible? What database are you on?
Yes that is the correct update guide you want to use. There is actually a section in that guide which talks about in-place vs out-of-place updates. As the guide says, and Iam trying to get at with the questions above, it depends on how much downtime is exceptable and also if you are already at a split schema or plan on going to a split schema with this update.
JPMC
US
Thank you Celeste Dufresne for your response! Yes my current 7.1.5 application is already having spilt schema, underlying DB is Oracle and server is WebLogic. We want to minimize production downtime which should not exceed for an hour and in worst case at most 2 hours. We can afford to have DEV downtime.
so based on my need I think out-of-place is the right option? If so then is there any guide for 7.x specific to out-of-place update process?
Updated: 27 Oct 2015 11:52 EDT
Pegasystems Inc.
DE
Hi Dhirendra,
we did an in place update for the production system from 7.1.6 to 7.1.8. Out of place is great but also means some additional work and basically you need more space (as schema is copied and renamed later). We did inplace update consisting of 12 million customer and around 30 million address within 1 hour. You can increase the speed of the update process by increasing the commit size in setupDataase.properties file. Update processes uses "commit.rate" property internally for commit size. For safety and backup during update, create a dump of the pega rules and data schema using oracle database pump utility . Then adjust the commit.rate property. You should always test on pre-production and test system before you do it on production.
use
commit.rate=500
(default is 100)
Pegasystems Inc.
US
While it is possible to do an in-place upgrade in production within your allotted time certainly in production it seems like an out-of-place update is a much safer option. As Prasanna indicates the upping the commit.rate will increase the speed as you will be issuing a commit less often.
Whether you choose to do in-place or out-of-place in production doesn't mean that you also need to do an out-of-place upgrade in DEV. You could do an in-place update in DEV and then migrate the updated rules schema to other higher level environments. You would still need to do the data schema upgrade in the higher environments but that is the only time when your higher level environment would need to be down.
The out-of-place update procedure is the same as an out-of-place upgrade except you will be using different media and running the update script instead of the upgrade.
JPMC
US
Thank you Prasanna Tuladhar & Celeste Dufresne !!
This is really good information for me. I read some more articles on PDN and It seems that out-of-place is more resource intensive and effort than in-place update as pointed by Prasanna because creating a temporary schema and interacting with other teams will require more time. So I am planning to go for in-place update one by one in all environments upto pre-prod and then fix any issue in dev and move them to QA/UAT and get them tested and finally apply the update and apply the code fix in PROD at once.
Can you please help me with any known issues after update from one ML to another(If Any)?
JPMC
US
Can someone please answer my below query:
If we use out-of -place schema then can the temporary schema created and upgraded on DEV rulebase, can be used as a source for migrating the updated rulebase to all environment including production? If so then we can save lot of time creating the temporary schema one for each environment.
Accepted Solution
Pegasystems Inc.
US
https://docs-previous.pega.com/pega-719-platform-upgrade-guide
I am not sure why you would want to migrate the temporary schema and not the actual rules schema from DEV to higher environments. The temporary schema (assuming you are using 2 database process that requires a tempoary schema) would not have any changes that you made in DEV after the upgrade.
There is a section in the upgrade guide called "Typical Enterprise Application Upgrade Process" which provides general guidelines for what you want to do. You would essentially migrate your rules schema from DEV to UAT, upgrade your data schema, test, and then migrate rules from UAT to production, upgrade data schema.
JPMC
US
Thanks Celeste Dufresne!! This seems much better option, I didn't think though it earlier. Thanks once again!