Clone/Copy Pega Database
Hi,
Writing up my experience on cloning the Pega database.
Having done a quick search of the community site, it doesn't seem there are postings regarding the topic of "cloning" the Pega database.
Cloning the database, or taking a "full snapshot/backup" of an existing instance and porting it over to a new database instance may save time as well as ensure *everything* has been copied/moved over.
Consideration:
- the target database ideally should be of the same database software and version as the source.
- use database tool of choice to perform a complete clone/copy of the schemas, such as "rules" and "data" schemas, if using split-schema Pega configuration
- use database tool of choice to import the data into the new target database instance, with schemas intact
- validate the target database user, roles, permissions are set according to the Pega installation guides
- update the tables <data_schema>.pr_data_admin and <data_schema>.pr_sys_statusnodes to remove references to the prior nodes
- adjust application server connectivity to target database (if necessary)
- start up application server and login to Pega (with credentials from prior instance).
- validate the system to ensure the code base is intact
- Done!
This process has worked with Oracle and SQL Server installations, and as of today, it has also worked for migrating from Azure SQL "standalone" / "singleton" to Azure SQL Managed Instance.
Good luck.
***Edited by Moderator: Lochan to convert post to discussion and tag as developer knowledge share***
Proximus
BE
Hi,
It's indeed working fine and not much documented.
We do that pretty often and I would add few steps to ensure all is working fine.
- in case of environmental values, we create in source environment the circumstances of the specific rules with the target system name.
Post Refresh, before starting the new system:
- all agents schedules are cleared, since they'll be created as per the new server(s)
- I also truncate: pr_sys_statusdetails, pr_perf_stats
- Depending on the needs you can also truncate or not pr_sys_queue* tables
Hi,
It's indeed working fine and not much documented.
We do that pretty often and I would add few steps to ensure all is working fine.
- in case of environmental values, we create in source environment the circumstances of the specific rules with the target system name.
Post Refresh, before starting the new system:
- all agents schedules are cleared, since they'll be created as per the new server(s)
- I also truncate: pr_sys_statusdetails, pr_perf_stats
- Depending on the needs you can also truncate or not pr_sys_queue* tables
Then I restart the system as prpc/pega with agents disabled (in prconfig.xml) to perform few changes without processing:
- If Authentication service are not using same credentials, you need to update to new environment values
- We change the system name as well then when needed Access Group of default requestor type
- DSS are to be aligned also, as well as Production level of new system name
Then from prconfig.xml I remove system name reference to prpc, I back enable agents and final restart will make it as a new system with all environmental values updated.
It's indeed very useful for preparing new env.
We also often work with rules schema export/import when there are major (and long lasting) changes. This partial DB activity works fine also for quickly moving lots of changes.
Anthony
StellarNexus Consulting UG
DE
Anthony_Gourtay Very true. I have done this a few times and never thought of documenting the process.
Good initiative!
JPMC
IN
HI When we are doing a copy for the higher environment
What are the tables which are to be truncated
For example we dont need operators to be move so we need to truncate teh operators table
So is there any list of tables which we need to truncate
Proximus
BE
Hello,
Tables you can clear are mentioned above.
It's better to do refresh for lower env than for higher ones.
For higher one, you should/could export/import only the Rules schema, not the whole DB except if it's a clean one.
If you truncate operator table, you won't be able to log in the system.
You could delete some records, based on a certain pattern, yet making sure not to delete technical operators.
You can truncate: pr_sys_statusdetails, pr_perf_stats, pr_sys_queue* tables, pr_sys_statusnodes;
Then you can also delete from pr_data where pxobjclass = 'Data-Agent-Queue' ; Regards
Anthony