Dbvisit Replicate provides dedicated functionality to manage database migrations, facilitating the creation and updating of the replacement database from the legacy system.
Using a product such as Dbvisit Replicate to facilitate data replication we can use an approach that addresses all of the issues identified above. A typical approach is as follows:
- Briefly lock database to instantaneously record the status of the database.
- Production application continues uninterrupted.
- Migrate database content up to the point recorded above.
- Initiate data replication, applying incremental changes made to the legacy database since the recorded point.
- From this point on, the replacement database continues to be updated with changes in real-time as they are made in the legacy database.
- Switch the application from the legacy database to the replacement database so the replacement database becomes the production data repository.
- Once the replacement system is in production, it is possible to reverse the flow of updates to the legacy database (for Oracle databases). Keeping the legacy database current in this way allows reversion to the legacy database, without loss of data, in the event an error is discovered in the replacement database.
The general approach to enable data migration using Dbvisit Replicate is a two-step process.
Step 1: Instantiation
The first step is to instantiate the legacy database in a known state. To achieve this, Replicate momentarily (for a matter of seconds) locks the legacy database and extracts the Oracle System Change Number (SCN). The SCN identifies the exact state of the database at that point in time.
Replicate then uses one of several methods to create an exact copy of the database (in whole or in part), as at the recorded SCN, in the replacement (target) database management system (Oracle, SQL Server or MySQL). This process can run in parallel with normal application operation, with no downtime required beyond the brief database lock required to extract the SCN.
Step 2: Synchronization
Simultaneously with the instantiation process, Replicate keeps a track of all updates made to the legacy database subsequent to the recorded SCN.
Dbvisit Replicate uses its own highly efficient change data capture (CDC) technology, based on Oracle’s redo logs, to detect changes in the legacy database.
Once the instantiation is complete Replicate is able to begin applying the updates it has identified. As this application process takes place Replicate continues to record changes to the legacy database. Eventually, once the historic updates have been applied, changes made to the legacy database are applied to the replacement database in real time.
In addition to the built-in conflict detection and resolution processes, Dbvisit Replicate ensures all committed records are securely delivered to the target database even in the event of an outage. This ensures that the replacement database is always updated with changes made to the legacy system.
Dbvisit Replicate uses public key cryptography to securely send data from the legacy database to the replacement database. When exchanging data outside of a LAN, either over a WAN or over the Internet, public and private keys are used to encrypt and sign the data, ensuring that the data is exchanged securely and providing confidence to the recipient that the data has not been modified in transit. Within a LAN environment this security can be tuned off.