Pega Update and Upgrade (out of Box) and Migration script issues ?
Can we get a clear statement from Product or Upgrade/Update Team from pega why Pega recomends using migration script for Out of box approach and recommends against using vendor specifics tool ? The only reasonable explanation I can see is that there are several stored procedures and functions which might have hard-coded schema names in it and needs to be taken care of if standard migration scripts are not used.
The migrations script or Update guide also does NOT say what to do if there are failures during coping process due to constratint violation etc.
Also copying 10-20 gb of data which this script uses is not performant as it copies gigabytes of data to and from Database. Database Vendor tools in such cases would definitely perform better since data would NOT have been transferred. Also there is less risk with network and connection issues should they go wrong.
Also why does the migration script (migrate.sh) not do some kind of pre-validation checks beforehand with rules data if there are new contraints etc.. introduecd in new pega version ?
The main issue is that if the schema copying of RULE schema fails the customer has to cleanup the new RULE schema objects, cleanup and fix the data or records in old RULE schema and restart from beginning. This cost about 2-3 hours of time and unecessary hassle. There should definitely be a better error handling.
***Edited by Maryrita, Moderator: moved to Product Support from Applicaitons***
EPAM Systems, Inc.
ES
Hi Tulap,
I understand the pain you are mentioning above, but apart from the script which are implicitly updated by Pega's internal engine there are other constraints, thus Pega recommends to use the standard migration techniques.
I am not fully aware of an alternative. But I have found an internal mesh post discussion related to something sort of
Link :- https://collaborate.pega.com/question/script-or-executable-file-automating-import-function-prpc
Kindly notify if it helps. I hope, we all get some other insight regarding detailed explanation with other developers.
Regards,
Asif
Pegasystems Inc.
US
The renaming of schema names within stored procedures and triggers is one reason why Pega recommends using the migrate script instead of database specific tools. Also there are other steps that happen where some tables are truncated in order to get them ready for an upgrade. Plus when you are migrating as part of a split schema upgrade you only want to copy the rules tables plus a copy of the pr_data_admin table which is needed for the upgrade but will eventually reside in the data schema.
As for the time that a migrate script takes verses a database specific tool, the migrate script actually only clones the table structure, without any constraints, so that it can quickly bulk copy the contents of the table to the new schema. The adding of the table constraints needed for the new version you are upgrading too are done during the upgrade of the rules schema itself. So you should never get a constraint violation while running the migrate script.