"The following diagram illustrates the three-step process for data migration using Dbvisit Replicate:"

How it works

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.

How it works

In order to ensure that all changes are reflected in the new replacement database, and none are missed, the traditional approach to data migrations involves an application outage for the period of time it takes to copy the legacy data to the new database. As databases grow in size and complexity, this process takes longer to complete. At the same time, with around the clock demand for systems, the availability of batch windows and planned system outages is reducing.

The traditional approach works as follows:

• Stop application processing against legacy database
• Migrate full legacy database to the replacement database
• Test replacement database
• Restart application, with processing against the replacement database

This approach has several major limitations:

• The application outage associated with the migration can be significant, and exceed the available planned outage or batch window.
• This is a one-time operation, with no opportunity to revert to the original database without discarding the replacement database and starting from scratch.
• If there is an error in the replacement database it is necessary to recreate the full database from scratch, with another full outage.
• If an error is found in the replacement database and it is necessary to revert to the legacy database, any changes applied to the replacement database are lost.

Using data replication techniques to deliver data migration reduces the application outage time to almost zero and allows us to create an environment whereby the migration can be performed over a period of time.

The data replication approach enabled by Dbvisit Replicate also provides significant opportunity to improve the quality, effectiveness and efficiency of testing associated with a large scale database or application migration. This includes functional, performance and load testing.

By providing a full-size replica of the existing production database, testing can be performed in an environment that exactly matches production. This includes the size of the database, along with the full array of data it holds. The on-going synchronization process ensures that testing continues to use up-to-date data from the production environment.

Dbvisit suggests the following basic approach for enabling testing of the replacement database and/or application:

• Instantiate the replacement database and update it with production data to the point to be tested.
• Turn off transmission of changes to the replacement database. Note that data changes made to the legacy database continue to be identified and cached at the production (legacy) site.
• Backup replacement database.
• Test the new system using the production data in the replacement database environment.
• Restore the replacement database from the backup taken above. This resets the database to the state of the production database at the time the backup was taken.
• Re-establish the connection from the legacy system to continue synchronization of changes. This process works through changes cached while the replacement database was “offline” and then continues to apply production changes as they are identified.

Learn more about the features of Dbvisit Replicate, our powerful, affordable oracle database replication software.