What is Pro2 and how does it work?
Pro2 consists of two main components:
- Change Data Capture (CDC).
- Replication.
CDC captures all database changes (inserts, updates, and deletes) using either replication triggers or Native CDC (available from version 11.7+). These changes are stored in a table called ReplQueue.
The replication process continuously applies these changes to the target database. Records are linked using the source record's ROWID, which is stored in the target table in an additional field called prrowid (with a unique index).
Pro2 supports replication:
- From OpenEdge to MSSQL, Oracle, or other OpenEdge databases.
- From multiple source databases to one or more target databases.
For the initial setup, a bulk load is used to copy the entire database. After that, real-time replication keeps systems in sync.
The main challenge is that the bulk load step is the most time-consuming.
Reducing dump and load downtime with Pro2
Pro2 allows you to prepare a fully synchronised database in parallel, significantly reducing downtime during the final switch.
How it works
- Box 1: Current production database (live system).
- Box 2: New database being prepared via bulk load and replication.
While users continue working on the production database, Pro2 keeps the new database up to date in near real time.
Cutover process
To switch with minimal downtime:
- Ensure the ReplQueue is empty (all changes replicated).
- Shut down the production database.
- Remove the prrowid field and index from the new database.
- Back up the new database.
- Restore it to the production environment.
- Start the database.
Result
Downtime is typically under 2 hours and often under 1 hour, regardless of database size.
Managing Pro2 environments with minimal disruption
For Pro2 users, there is an additional challenge.
Not only does the production database require downtime, but the target database must also be rebuilt due to ROWID changes. This involves another bulk load, which can take three to five days.
Initially, this may not seem critical. However, over time, the target database often becomes as important as the production system, if not more.
A multi-day outage in such cases is not acceptable for most businesses.
Using Pro2 to eliminate long target downtime
Pro2 can also address this issue by introducing a secondary replication path.
Extended setup
- Box 1 → Box 3: New OpenEdge database (prepared via dump and load).
- Box 3 → Box 4: Target database (e.g. MSSQL).
Second-pass replication
- Enable replication from Box 1 to Box 3.
- Once the bulk load to Box 3 is complete, start replication to Box 4.
- This avoids rebuilding the final target database from scratch.
Go-live process
- Switch operations to Box 3 and Box 4.
- Perform a short downtime step: remove the prrowid field and index.
Result
Cutover downtime is typically less than one hour.
Key takeaways
Reducing downtime in OpenEdge projects requires more than standard parallel processing. With the right setup, Pro2 allows you to:
- Prepare databases in parallel.
- Keep systems continuously in sync.
- Reduce cutover downtime to under one hour.
- Avoid multi-day outages in target environments.
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 our expertise and are committed to ensuring your project runs smoothly and efficiently.
