What are the advantages to moving to split-schema?
Working on a Pega 7.1.7 Upgrade Plan, my team has asked the question - "should we move to split-schema".
It's a great question, and one that I could not find a lot of information on.
So, Pega Community - should I move to Split Schema? Why?
-Ben
***Updated by moderator: Lochan to close 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.
Pegasystems Inc.
US
To take advantage of high availability features. For example you can keep your current system up and running while you are doing the rules schema part of the upgrade and only have to take it down for the much shorter time that it takes to update the data schema.
Pegasystems
US
Would considerations regarding db backup be a factor as well ?
When we send out hot fixes from Pega to a customer, we typically say "please backup your pegarules db in case anything goes wrong with the hot fix installation". So, for example, in the unlikely event that the system is unusable after the hot fix is installed, the pegarules db can be restored from the backup, and the system will be back to the way it was before the hot fix was installed.
If the work objects and pegarules are in the same db container (non-split schema), then the backup of the pegarules db will necessarily include the work db as well. If the schema is split, it become possible to backup the pegarules db without having to backup the work db at the same time. /Eric
Pegasystems Inc.
US
Confirming Celeste Dufresne 's info is https://pdn.pega.com/introducing-pega-7/high-availability-what-s-new-in-pega-7, the section Upgrade production PRPC.
Capgemini
IN
As per the document I can see that split schema is required. But not sure how it is helping it to have high availability. Can anyone provide some more details?
-Saikat
Pegasystems Inc.
US
Hi Ben,
“Split schema” refers to the idea of classifying the database tables used by PegaRULES into two categories : Rules tables and Data tables.
The primary goal for this is to decrease the amount of time a system must be unavailable during an upgrade. As such, this epic is a key part of the “high availability” goal.
The principle behind this idea is that rules change significantly from one release to the next, whereas data and work transcend releases. During an upgrade, one would install a completely new set of rules tables, while keeping the data tables (essentially) untouched.
The system would be up and running during this time. Once the system administrator is ready “pull the trigger” and start using the new version he can then update the PegaRULES table mapping to point to the new rules schema.
This last step would require some downtime, but not as nearly as much as upgrades do today, when the system needs to be down during the whole upgrade process.
Hope this information might be helpful to understand how we are achieving “High Availability” feature with split schema concept.
Regards,
Mahesh