Clone/Copy Pega Database


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.


- 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***


Keep up to date on this post and subscribe to comments

September 2, 2019 - 8:35am

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.