Discussion
JP Morgan
IN
Last activity: 6 Apr 2018 19:26 EDT
Upgrade from Pega 5.5 to 7.2. pr_log and pr_sys tables missing in generate DDL Scripts
Dear Team,
We are upgrading from Pega 5.5 to Pega 7.2 using Single Schema upgrade. When we ran generate DDL query and reviewed the SQL queries generated we see that create queries for below tables are missing. Please let me know how can I get create SQL queries for below tables and the reason why they are missing in query generated by DDL script in first place. Also let me know can go ahead and run upgrade.sh (by disabling generate and apply DDL parameters) without below tables being created.
pr_log_reportstats
pr_sys_cache_entry
pr_sys_cache_dep
pr_sys_cache_impl
Venugopal Adep
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Updated: 2 May 2016 6:33 EDT
Cognizant
IN
Only when the deployment user cannot have the privileges specified in the V7.2.0 upgrade guide; we resort to creating DDLs + requesting our DBAs to apply them.
If the deployment user has the required privileges then we need not bother creating (OR) applying DDLs. Try leaving the 3 bypass flags "as is" (shown below) and do not set them to "=true".
Purge everything the upgrade.sh has created so far and try once more.
- bypass.pega.schema
- bypass.udf.generation
- bypass.trigger.control
Among the tables you have listed pr_log_reportstats was newly added in V7
pr_sys_cache_entry / pr_sys_cache_dep / pr_sys_cache_impl are present in V6. Could you confirm if they are present in V5 too ?
Kindly share the reason for not performing a split schema upgrade ?
JP Morgan
IN
Vignesh, Thanks for your response.
We had initial discussion with one of the engineer from Pega ([email protected]). As per him, our database size is huge so he suggested first doing Single Schema Upgrade and test everything and then split the schema. Need your inputs from your if this is the best approach (Single Schema upgrade + Test and then Split the schema)?
Venugopal Adep
Updated: 2 May 2016 7:24 EDT
Cognizant
IN
Assuming the application's rule base is huge ( referring only to the number of rows in the pr4_XYZ tables )
In such cases you could perform the following 3 steps and verify if they help to bring down your rule base size.
- Skim all the non-OOTB rulesets to a new Major version (0M-01-01). Then purge all the old rule set versions below this new major version.
- Purge any rule set that is not required for the functioning of the application. Every application has one or two such rule sets.
- Purge any decommissioned / half-cooked / abandoned modules from your application.
Hoping these steps are feasible and they help reducing the size of the rule base in the application.
I have never performed a single schema P7 upgrade hence I cannot comment on the approach mentioned.
JP Morgan
IN
Thanks Vignesh,
We have already done the steps you have mentioned (skimming, purging etc). We want to have second opinion on what are the considerations which may prompt us to go for Single Schema upgrade initially, instead of Split schema upgrade. Is there any upper limit on the data size for Split schema upgrade? If possible please involve someone from your team to get the response. Do you have any numbers on what was the maximum size of database which was upgraded to 7.x successfully? We want to save lot of rework latter on as Single Schema vs Split Schema is a big decision.
Note: In our case the we are upgrading from 5.5 to 7.2
Venugopal Adep
Cognizant
IN
We are not aware of any "upper limit on the data size" for a split schema upgrade.
(When we say "data size" I assume we are referring only to the number of rules in the application and not the number of
work objects)
None of the folks/teams I consulted with have ever performed a single schema upgrade.