Plan for disaster recovery with Pro2
- Last Updated: March 30, 2020
- 3 minute read
- OpenEdge
- Version 12.2
The role of a Replicated SQL database in your business is a major point to consider in planning for Disaster Recovery (D/R) in a Pro2 replication environment. Another point to consider is the size of your source and target databases and the length of time required to restore and to reload the data to the SQL target.
When is it necessary to reset the SQL target database
Generally, the target SQL database must be loaded whenever the source database or repl database need to be restored from backup. Bulk-loading the data from the source OpenEdge database to the target SQL database can take a long time. This time may range from days or weeks depending upon the size of the database. Your disaster recovery plan should be clear on what situations require a full re-bulk load of the data and the steps required to do so.
ROWID in the replication process. The
ROWID is the unique record identifier in the
OpenEdge database. Pro2 uses the ROWID to store and
identify the corresponding record in the SQL database. Two important facts about how
ROWID’s are assigned in the OpenEdge database
are: - The order in which records are created and deleted determines
their
ROWID. - When a record is deleted from the OpenEdge database, its
ROWIDcan be used again for a subsequently created record.
ROWID’s could
be completely different than the original values stored in the target SQL database
and any subsequent changes result in invalid data in the target SQL database. Why back up the repl database?
The repl database contains valuable information. Understanding the roles of the various tables in the repl database is helpful in determining a backup strategy for the repl database. The repl database contains many tables and its essential to back up the database to proper functioning of the too.
- The repl database contains all the mapping information for the replication of the databases, tables and fields between the source and target.
- The repl properties contain configuration settings such as log file location, logical delete tables and specification of procedure templates which are stored in the ReplProperties table.
- The replqueue table stores information on change events. This
information includes the
ROWIDof the record changed, event date/time, and queue thread.
Restrictions with online backups
- The backups of the source database and the repl database could be out-of-sync depending on the timing of the online backups for the repl database and the source database.
- The ReplQueue may have transactions that were not included in the backup of the source database if the source database backup occurred first.
- The ReplQueue in the backup of the repl database might be missing committed transactions if the repl database backup occurred first.
Pro2 and after-imaging
After-imaging can be enabled and running on the source database concurrently with Pro2 replication. If after-imaging is enabled and running on the source database, it does not need to be enabled on the repl database. However, if after-imaging is not enabled on the repl database, the disaster recovery plan must include re-seeding the target SQL database.
Pro2 and OpenEdge replication
OpenEdge Replication is a Progress product that maintains a replicated copy of the source database as part of a disaster recovery scheme. Pro2 replication can be running concurrently with OpenEdge replication. If the target SQL database and the repl database are part of the disaster recovery solution, the OpenEdge replication configuration needs to be modified to include them.