How to reduce planned downtime for OpenEdge applications with Pro2?

2023 05 23 · 2 min read

Regular maintenance that involves significant system downtime can cause interruptions for users trying to access the system. However, there are methods to reduce downtime for most maintenance tasks.  

If you have in mind a Progress OpenEdge upgrade, transitioning to the cloud, platform migration, undertaking a dump and load process, or any other major project that will cause the database to be unavailable for hours on end, it is of utmost importance to commence by contemplating a few essential elements. First, you need to be clear about what activities will require downtime and how long they will last. If the estimated duration of downtime exceeds the acceptable period, you need to use innovative approaches to shorten the downtime. This is where Pro2 steps in. 

In this blog post, we will explore how Progress OpenEdge services – particularly Pro2 – can help you minimise downtime due to database dump and load or replication processes.    

Are you curious about how Pro2 works? Let us look more closely! 

Pro2 is divided into two parts: Change Data Capture (CDC) and Replication. CDC saves updates, creates, and deletes in the database using Replication Triggers or Native CDC (11.7+) in a table named ReplQueue.  

The Replication function then replicates the most recent record to the target database indefinitely. The source and destination records are linked using the source record’s ROWID. The target table contains an additional column called prrowid that records the source ROWID and has a unique index. 

Pro2 can replicate the OpenEdge database to MSSQL, Oracle or other OpenEdge databases. Moreover, it is also possible to replicate several source databases into one or multiple target databases. 

Bulk load method is used for the initial copy of the whole database, which transfers all tables with all its records. Only after that, we can use real-time replication. However, this is a part that takes, by far, the most time. 

Pro2 – a solution to dump and load downtime woes 

The image below depicts the functionality of Pro2 in generating a newly dumped and loaded database, which is then the focal point of Pro2 replication. 

Figure 1

Box 1 is where the current production database is running with users connected. Box 2 is where a new database is receiving updates from the production database. The dump and load process are accomplished by the bulk load process described above. 

To replace the database in Box 1 with the new database in Box 2, follow these steps: 

• Ensure that the replqueue in Box 1 is empty; 
• Shut down the database running in Box 1; 
• Remove the prrowid field and index from the database in Box 2; 
• Back up the database running in Box 2; 
• Restore the backed-up database to Box 1; 
• Start up the database on Box 1. 

Typically, for the majority of databases, the required downtime is under two hours, and frequently, it’s even less than one hour, regardless of the size of the database. 

How to manage Pro2 customers effectively? 

If you are a Pro2 customer, then you have an extra challenge. You not only need to take downtime for the dump and load process on your production database, but you also need to take downtime on the target database for the bulk load process. This is because all the ROWIDs changed on the source database. 

The bulk load process can take three to five days to complete, which may not seem like a big deal initially, as no business processes depend on the target database. However, over time, that target database becomes as critical as the source production database, if not more critical. Therefore, a three- to five-day outage for most customers to build out the Pro2 target is unacceptable. 

Once again, Pro2 comes to the rescue 

We can utilise Pro2 to construct a supplementary channel for these consumers once more. This approach entails moving data from a Progress OpenEdge database to a destination database, as previously defined. The target database in this instance is MSSQL, and the platform is being migrated from HPUX to Linux. The graphic below depicts this procedure. 

Figure 2

In the picture above, Box 1 and Box 2 exist. First, we build the path to Box 3, which is the dump and loaded database similar to the database in Figure 1. Then we build out the path from Box 3 to Box 4. The trick to make this work with Pro2SQL is to enable second-pass replication, where the second-pass replicates to the OpenEdge database in Box 3. Once the bulk load is completed for Box 3, then the path from Box 3 to Box 4 is created and bulk loaded. 

The go-live process is to migrate to Box 3 and Box 4. The downtime required for the cutover is the time it takes to remove the prrowdid field and index for the database in Box 3. The typical downtime is less than one hour 

We understand that reducing project downtime is crucial for success. However, limited downtime windows require creative solutions. Parallel processing may not be enough. That is why we have a solution – Progress OpenEdge services, which offers specialised tools to reduce downtime to just a few hours. 

Progress OpenEdge services are the ultimate solution for businesses looking to stay ahead of the curve in today’s digital age. With its cutting-edge services and expert development, OpenEdge provides unparalleled performance and scalability for companies of all sizes. 

So, if you want to consult about Progress OpenEdge development, please contact us – the Baltic Amadeus team. We take pride in being experts in the field, and we are committed to ensuring that your project runs smoothly and efficiently.