Upgrading AES from UAT to PROD
Hello! I am planning to upgrade AES from 7.1 to AES 7.3. I plan to override the existing 7.1 database with the new 7.3 database. I do not need to save the existing data. If I copy the AES UAT database into production that will copy the test data into production. In looking at the AES database, I have a list of tables that can be truncated in production. AES will start collecting new data/statistics when configured. My question is: can you verify that these tables can be truncated with no impacts? Am I missing any tables that should be truncated?
pegaam_dailymetrics_index, pegaam_action_index, pegaam_alert, pegaam_cluster_data, pegaam_crit_event, pegaam_dailymetrics, pegaam_email_recipient, pegaam_exception, pegaam_guardrail, pegaam_index, pegaam_ind_change, pegaam_perf_stats, pegaam_node_health, pegaam_node_stats. pegaam_topoffenders, pegaam_action_work, pegaam_exception_work,
Thanks!
Fred
***Edited by Moderator Marissa to update categories***
Updated: 16 Apr 2018 6:45 EDT
Pegasystems Inc.
IN
Hi Fred,
If you are planning to upgrade to AES 7.3 then I would suggest to follow below article instead of copying the tables from environment to another.However you do not need data of UAT in PROD so It's better to create new tables instead of copying and truncating them.If you truncate the tables then also there would not be any effect because agents run periodically to update data of these tables.
Please go through below pdn link and let me know if you need any other detail.
Thanks,
Abhinav
Updated: 22 Jan 2020 1:57 EST
Highmark Health
US
Hi Abhinav,
In my development environment, I did install Pega 731 and AES 73 from scratch. It would be a faster implementation (ie. upgrade) if I copied the database. I realize that would have to reconfigure the system name and AES nodes, etc. The rules are the same, so I would be re-importing what I did in development. I'm just trying to find some efficiencies. Thanks!
Pegasystems Inc.
US
you can upgrade and truncate - or just install from scratch. Do you have significant configuration or customization work in place?
Updated: 22 Jan 2020 1:57 EST
Highmark Health
US
If I install from scratch or copy the DB, I will have to do the system configuration and configure the monitored nodes. Either way, I would have only a Pega731/AES7.3 rules in the database. This would be a fresh start. If I upgrade, then I would have to delete the Pega718/AES717 rules. If I copy the DB, what Data tables should be truncated? I have a good idea in my original post, but just wanted to confirm it. Thanks!
Pegasystems Inc.
US
How many monitored nodes are you talking about? Configuration of monitored nodes in AES is normally two things
a- updating connection strings in class PegaAES-Data-Nodes
b- creating node specific decision tables for monitoring thresholds.
If you were to export class PegaAES-Data-Nodes and ruleset PegaAESConfiguration (the production ruleset) you'd be able to restore all node-level configuration after a fresh install.
If you were to install a fresh PegaRules schema and upgrade the PegaData (some new tables/columns in AES plus normal Pega upgrade tables/columns) there is nothing you have to truncate specifically - things should work.
Updated: 22 Jan 2020 1:57 EST
Highmark Health
US
Good idea about exporting the PegaAES-Data-Nodes, PegaAES-Data-Clusters and even the PegaAES-Data-NodeHealth - that will take care of both - the connection strings and the decision tables for monitored nodes. I can create a product rule and export the data and re-import it. That will save time/effort on re-configuration.
In prod, there are about 65 nodes. QA 1 has about 80 nodes and QA 2 has about 39 nodes.
So your recommendation is to do a fresh install vs. a db copy. In either instance, I can import the config settings. Since the rules are the same - why can't I copy the DB from test to prod?
Thanks!
Pegasystems Inc.
US
you can copy DB. I find it as much / more work to clean up a cloned DB than to install fresh but that's a personal preference.