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 a backup. Bulk loading the data from the source OpenEdge database to the target SQL database can take a long time. This time may range up to days depending upon the size of the database. Your disaster recovery plan should be clear on what situations require a full bulk load of the data and the steps required to do so.

To answer the question of when to reset, it is important to understand the role of 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 ROWID can be used again for a subsequently created record.
Therefore, even if you know which records were created and deleted during the time the source database or repl database were lost and you reapply those changes to a restored version of the database, the ROWID’s could be 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 replication database contains valuable information. Understanding the roles of the various tables in the replication database is helpful in determining a backup strategy for the replication database.

Reasons to back up the database are:
  • The repl database contains all the mapping information for the replication of the databases, tables and fields between the source and target databases.
  • The repl properties file 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 about change events. This information includes the ROWID of the record changed, event date and time, and queue thread.

Restrictions with online backups

You must be cautious when you use online backups as part of your disaster recovery solution. Some of the important points to take note of are:
  • 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 replication queue may have transactions that were not included in the backup of the source database if the source database backup occurred first.
  • The replication queue in the backup of the repl database might be missing committed transactions if the repl database backup occurred first.
Progress recommends that online backups are used only in conjunction with after-imaging.

Pro2 and after-imaging

After-imaging can be enabled and an on the source database concurrently with Pro2 replication. If after-imaging is enabled and running on the source database, then after-imaging does not need to be enabled on the replication database. However, if after-imaging is not enabled on the replication 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 run concurrently with OpenEdge Replication. If the target SQL database and the replication database are part of the disaster recovery solution, then the OpenEdge Replication configuration must be modified to include them.