Solution for Migrating Heterogeneous OLTP Databases to GBase 8s

Leading global database products such as Oracle and DB2 have long been deeply entrenched in the core business systems of industries across China. When organizations seek to replace or modernize these systems, they face a host of challenges during the heterogeneous database transition—including data migration, application compatibility, and new system stability—all aimed at reducing the risks of database architecture migration.

Drawing on our GBase 8s migration expertise, the following presents an overview of the complete migration approach:

The migration process provides a guiding framework for the entire migration initiative, enabling its organized and systematic execution. The key process steps are:

This phase focuses on pre-migration research and evaluation, as well as designing the plan that guides migration execution. Key aspects include:

1. Pre-Migration Assessment Scope and Key Points

The priority is understanding customer requirements and current pain points so that tailored improvement solutions can be delivered after migration. Pre-migration assessment is a mandatory part of the migration project and must not be omitted. It may be conducted before or after contract signing, depending on project progress.

1.1 Objectives of Pre-Migration Assessment

• Define the migration scope

• Estimate migration workload, implementation timeline, staffing requirements, and skill sets needed

• Identify technical challenges and key project risks

1.2 Pre-Migration Assessment Content

• Current state of the migration system: architectural topology of the original database, configurations, upstream and downstream dependencies, and original database version

• System operating conditions: application scenarios, criticality assessment, application deployment architecture, business types, approximate CRUD operation ratios, concurrency, and total number of business system users

• System performance requirements: response latency during peak periods, batch processing concurrency, data volume processed, processing time, data lifecycle, etc.

• Interface details: application development language, ORM framework version in the development environment, database access protocol, connection pool configuration, long vs. short connections, and third-party tool support requirements

2. Migration Solution Design

Based on the pre-migration assessment findings and addressing the customer’s specific system usage requirements and pain points, the migration solution defines the replacement and transformation plan, which mainly includes:

• Hardware configuration and deployment plan for the migration system;

• Tailored solution that addresses customer requirements and pain points;

• Migration steps and activities;

• Implementation plan and milestones.

3. Hardware Resource Estimation

Hardware sizing for the GBase 8s cluster adopts a reverse-derivation approach: first, obtain detailed configuration information of the original database; then determine the per-server specifications and the number of servers required for the GBase 8s cluster based on total CPU cores, memory capacity, disk capacity, and data volume growth trends. In principle, the total CPU cores, memory capacity, disk capacity, and number of disk drives across all servers in the GBase 8s cluster should not be less than those of the original system. For scenarios where this reverse approach is not applicable, you may also refer to the recommended hardware configuration for GBase 8s clusters.

GBase 8s delivers a comprehensive, seamless migration solution that minimizes risk and ensures smooth operations when migrating your database applications to GBase 8s. The process consists of three phases. In Phase 1, after completing a full backup and restore, real-time data synchronization is established from the primary source database to the standby GBase 8s database using data synchronization tools. After the first phase runs stably for a period, the primary and standby roles are swapped, entering Phase 2: the GBase 8s cluster database supports business operations, and business data is synchronized back to the source database in real time. In the final phase, the original database system is cut over and decommissioned, completing the seamless migration.

Next, you need to plan ahead for technical challenges including full and incremental data migration, and data comparison before and after migration.

Evaluating the Full Data Migration Approach: Key Considerations

The time window for migrating the full dataset largely determines whether it is a one-time operation or split into batches. The following factors must be carefully considered:

• Source data volume [requires testing to evaluate the data compression ratio of the source database];

• Allowable downtime window [during which the source database must be in read-only mode with light load; often a hard constraint];

• Source database export performance [requires testing to determine capacity];

• Number of migration tool servers, their I/O performance, and network bandwidth to the GBase 8s cluster [migration environment constraints];

• Loading performance of GBase 8s cluster nodes [consider both I/O and network bandwidth].

Estimate the migration time window using the following formula:

Total migration time = Source database export time + GBase 8s loading time + Data verification time

Additional considerations for data migration:

• The export performance of the source database must be tested;

• When estimating the utilization of 10 Gigabit bandwidth, apply a redundancy factor—typically multiply the calculated rate by 0.5;

• The overall time window should be evaluated assuming serial export and loading to provide a buffer for unexpected events, while the actual execution can be designed with a multi-concurrent approach.

Data verification involves comparing the processing results of the same data between the source system and the migrated system. Consistency of results indicates that the migration process was correct.

Common Data Verification Methods:

Total Verification: Compare count, sum, and average values.

Subtotal Verification: Perform a GROUP BY on dimensions within the table, then verify the count, sum, or average of a key metric for each group.

Discrepancy Analysis: When an inconsistent table is found, bring the compared tables into a unified environment for detailed analysis—for example, by executing a MINUS operation to identify differing rows and investigate further.

Verification Report: The verification report is the tangible output of the reconciliation work. It records and analyzes data consistency issues, provides traceability for previously resolved problems, and builds a knowledge base of common verification challenges.