Posted: 28 Jul 2016 14:22 EDT Last activity: 1 Aug 2016 10:10 EDT
Migration of History tables for Work items and data items. How to address if they were initially missed? which ones should be [now] migrated without impacting performance/functionality?
using Pega 7.1.8, we have performed a few migrations to a test environment. Via some performance/optimization testing we discovered that we had mistakenly not migrated any Work item History table definitions. (one item that led us down this path was that optimized fields in DEV did not result in the appropriate column add SQL statements being generated when migrating to a different environment) When performing the packaging wizard, it was observed that a LOT of History items were identified to be migrated. The concern is that some previous coding mistakes has resulted in this list being large. We would like to minimally add only the necessary history tables and thus minimize the potential impact on functionality/perfomance in the test environment. (And then migrate the data from pr_history into the new history tables as appropriate) What is the normal best practice? And given that, how should we proceed in fixing this.?
***Updated by moderator:Marissa. Removed user added Ask the Expert and #helpme tags. Apologies for confusion, shouldn't have been an end-user option***
There are couple of points here- since you have migrated a lower version (assuming 6.x) product to 7.x version the clasees (work, implementation, fw) will automatically create the history classes. Check if this point is done - meaning the history classes exists in the system. If yes then you are half done - you need to check if the the D-A-TableName instances are available for these history clasess - else get those instances migrated in a separate package from the lower version pega product.
Secondly if you have a DBA - check with them if they can get a good image of the histroy classes data (which you want in the current upgraded pega environment). IF yes then you should be able to copy that data from the history data tables for those specific classes etc to the pega_data schema.
For Work object the solution is bit more tricky since for work object you have lot more dependencies; you need the information about the following pega tables: assignment, attachment,link attachment, work, history. Since you missed to package while importing to the newer pega version while upgrading you would need to package all these dependencies together in a file to get it correctly done.
I would suggest you to try with a very small set of records to check how it impacts your current process of upgrade (not impacting any other work) and then proceed to import the data into the corresponding tables in the upgraded pega.
I would suggest you to collaborate with the DBA who understands the pega table structures (including the BLOB anc CLOB structure very well) before migrating any data - since if the image copy of the history / work/assignment tables are not done correctly the columns may get messed up.