Applying a patch without downtime

The Pega patch process is zero-downtime when you use the out-of-place process so you can continue working in your application while you patch your system.

The patch process involves four schemas:

• Data schema – your existing data schema. This will be your data schema after the patch as well.
• Rules schema – your existing rules schema. This schema is upgraded during the patch.
• A temporary data schema (Dtmp) – a schema you create on the same database for temporarily staging the data during the patch. You discard this schema after the patch.
• New rules schema (Rn) – a rules schema you create on the same database for staging the rules during the patch. This schema will become the rules schema after the upgrade.

Pega provides client-run scripts that copy and replace application rules and that copy data between these schemas appropriately throughout the patch as described below.

Clients apply patches by completing the following steps:

1. Prepare the cluster for the patch by configuring the high availability cluster settings.
2. Create a new rules schema and a new temporary data schema in your existing database. Leave these new schemas empty.
   
   

3. Migrate the rules structure and content and data structure from the existing rules and data schemas to the new rules and temporary data schemas. Running the migration script creates any required tables in the new rules and temporary data schemas, and copies and moves the rule content.
   
   

4. Patch the new rules schema. This process uses the temporary data schema in which it creates and modifies any necessary data tables to store interim data content; these tables and data are discarded when the temporary data schema is removed.
   
   

5. For Oracle databases, you must grant access to the new rules schema tables by using migrate.sh again to generate the necessary rules objects (GRANT statements) which will link the existing data schema to the new rules schema after you patch the new rules schema.
6. Patch the existing data schema.
   
   

7. Redeploy the application to run using the new rules, as described in Reconfiguring the application server.
   
   

8. Revert the high availability cluster settings you modified at the beginning of the patch process.
9. Using a database editing tool, delete the old rules and temporary data schemas from your database.

• For High Availability systems: Preparing the cluster for patching

  Pega Platform can automatically move rules between the old and new rule schemas after the patch process is complete on a system configured for high availability. This allows you to continue making rule changes throughout the patch process. To enable this functionality, you must update the cluster settings to prepare for the patch.

• Migrating to the new rules schema

  Use the migrate script to migrate the rules tables and other required database objects from the existing rules schema to the new rules schema. To minimize the time required, run the migration scripts from the same data center as the database server.

• Patch methods for the migrated rules schema

  Use either the Installation and Upgrade Assistant or a command-line tool to patch the migrated rules schema. Use a command-line tool to patch the migrated rules schema.

• For Oracle databases only: Granting access to the new rules schema tables

  Grant access to link the data and new patch schema.

• Patching the data schema

  Run the script to patch the data schema.