How to Migrate from Oracle Database to KingbaseES

Prerequisites: Validating Architecture and Domestic Hardware Compatibility

Before initiating the migration process, you must verify the foundational constraints of the target environment. The migration strategy relies on a dual-system redundancy architecture, which requires specific hardware support and commercial software licensing.

Disclaimer on Local Support: The provided evidence does not confirm the existence of KingbaseES offices, engineers, or data centers in Malaysia. Users should verify local support availability directly with the vendor.

Hardware Architecture Verification

KingbaseES V8 is designed to support domestic CPU architectures. If your enterprise infrastructure relies on or plans to migrate to domestic hardware, ensure compatibility with the following processors:

• Loongson
• Phytium
• Zhongguo (Note: Verify specific vendor mapping for this architecture)
• Galaxy

Verify that the operating system and kernel versions on these domestic platforms are certified for KingbaseES V8. KingbaseES is commercial software. It is not open-source or source-available. Do not assume community support exists for these specific configurations.

Software Version and Licensing

• Source System: Oracle Database (Version to be verified against KingbaseES compatibility matrix).
• Target System: KingbaseES V8.
• Licensing: Ensure you have valid commercial licenses for KingbaseES V8 before deployment.
• Synchronization Tools: Identify the specific tools available for your version. FlySync is used for Oracle to KingbaseES synchronization. KFS is used for KingbaseES to Oracle synchronization.

Environment Checklist

• Confirm domestic CPU architecture support (Loongson, Phytium, Zhongguo, Galaxy).
• Verify KingbaseES V8 installation media and license keys.
• Confirm network connectivity between Oracle and KingbaseES nodes.
• Allocate sufficient storage for real-time log buffering.
• Prepare rollback scripts based on the dual-system architecture logic (specific scripts must be developed based on vendor guidelines).

Phase 1 Architecture: Configuring Oracle as Primary with KingbaseES as Real-Time Backup

In the first phase of the migration, Oracle remains the primary transactional system. KingbaseES V8 operates as a backup system with real-time data synchronization. This phase allows you to validate data consistency and query performance without disrupting the production application.

Objective

Establish a read-only or query-offload replica of the Oracle database in KingbaseES while maintaining full write capability on the Oracle side.

Configuration Steps

1. Initialize KingbaseES Instance
   Install KingbaseES V8 on the target hardware. Configure the instance to accept incoming synchronization connections. Ensure the database encoding matches the Oracle source to prevent character set conversion issues.

2. Configure FlySync for Data Synchronization
   Deploy FlySync to bridge the Oracle source and KingbaseES target.

   • Point the source connection to the Oracle database instance.
   • Point the target connection to the KingbaseES instance.
   • Enable real-time synchronization mode to capture incremental changes.
   • Note: Specific command-line arguments and configuration parameters for FlySync are not provided in this guide. Refer to official KingbaseES documentation for exact syntax.

3. Validate Initial Data Sync
   Allow FlySync to perform an initial full data load. Monitor the synchronization lag to ensure it remains within acceptable thresholds.

4. Enable Query Offloading (Optional)
   Once data consistency is confirmed, you may route read-only queries to KingbaseES to reduce the load on the Oracle primary system. This step validates the "business offloading" capability mentioned in the solution strategy.

Conditional Outcomes

• Oracle continues to handle all write transactions.
• KingbaseES holds a near real-time copy of the data.
• Conditional: The solution claims to allow smooth migration without changes to original application code, but this is contingent on the results of a compatibility scan. If unsupported features are found, refactoring is required.

Schema Translation Strategy: Managing PL/SQL Dialect Gaps

Heterogeneous migration involves significant differences between Oracle PL/SQL and the KingbaseES dialect. While the solution claims to support smooth migration without application changes, this is contingent on the compatibility of specific SQL constructs.

Identifying Dialect Gaps

Oracle and KingbaseES differ in several areas:

• Packages and Procedures: Syntax for defining and calling PL/SQL packages may differ.
• Triggers: Trigger syntax and event handling can vary.
• Data Types: Specific Oracle data types may require mapping to KingbaseES equivalents.
• Advanced Features: Partitioning strategies and proprietary security modules may not have direct equivalents.

Compatibility Scanning Procedure

Since specific command-line arguments for schema conversion tools are not provided in the evidence package, follow this vendor-neutral procedure:

1. Extract Schema Definitions
   Export the Oracle schema definitions, including all packages, triggers, and stored procedures.

2. Run Compatibility Analysis
   Use the vendor-provided analysis tool (if available) or a manual review process to scan the extracted definitions against KingbaseES syntax rules.

   • Flag unsupported keywords.
   • Identify complex PL/SQL logic that may require refactoring.

3. Manual Refactoring
   For identified gaps, manually rewrite the PL/SQL code to match KingbaseES dialect standards.

   • Update syntax for package definitions.
   • Adjust trigger bodies to match KingbaseES event syntax.
   • Map Oracle-specific data types to KingbaseES equivalents.
   • Note: Specific PL/SQL conversion rules are not provided in the evidence and must be derived from the vendor’s documentation.

4. Unit Testing
   Execute the converted PL/SQL code in a test environment. Verify that the logic produces the same results as the Oracle version.

Critical Warning

Do not assume 100% compatibility. The "no application change" claim is valid only if the compatibility scan confirms that no unsupported features are used. If the scan reveals unsupported features, you must plan for code refactoring before the cutover.

Phase 2 Transition: Swapping Roles with KFS for Real-Time Sync

Once Phase 1 is stable and schema translation is validated, proceed to the cutover. In this phase, KingbaseES becomes the primary system, and Oracle transitions to a backup role.

Objective

Switch the application traffic to KingbaseES while maintaining a real-time backup of the data in Oracle for safety.

Configuration Steps

1. Stop Write Access to Oracle
   Temporarily halt write transactions on the Oracle database to ensure data consistency during the role swap.

2. Configure KFS for Reverse Synchronization
   Deploy KFS to synchronize data from KingbaseES back to Oracle.

   • Point the source connection to the KingbaseES primary instance.
   • Point the target connection to the Oracle backup instance.
   • Enable real-time synchronization to capture all new transactions.
   • Note: Specific configuration parameters and command syntax for KFS are not provided in this guide. Refer to official KingbaseES documentation for exact syntax.

3. Verify Data Consistency
   Run data consistency checks between KingbaseES and Oracle. Ensure that the row counts and checksums match.

4. Execute Cutover
   Update the application connection strings to point to KingbaseES.

   • Disable the Oracle primary role.
   • Enable the KingbaseES primary role.
   • Resume write transactions on KingbaseES.

5. Monitor Synchronization
   Watch the KFS synchronization lag. Ensure that Oracle is receiving updates in real-time.

Conditional Outcomes

• KingbaseES handles all production traffic.
• Oracle serves as a real-time backup.
• Conditional: If KingbaseES fails, Oracle can take over immediately, provided the synchronization lag is within acceptable limits and the application is compatible.

Validation Protocol: Verifying Data Consistency and Transaction Integrity

Data integrity is the primary concern during migration. You must validate that no data is lost or corrupted during the synchronization phases.

Consistency Checks

1. Row Count Verification
   Compare the total row count of critical tables in Oracle and KingbaseES.

   -- Run on Oracle
   SELECT COUNT(*) FROM critical_table;
   -- Run on KingbaseES
   SELECT COUNT(*) FROM critical_table;
   

   The results must match exactly.

2. Checksum Validation
   Generate checksums for the data in both systems.

   • Use a standard hashing function (e.g., MD5 or SHA-256) on the data columns.
   • Compare the checksums to ensure data integrity.

3. Transaction Log Review
   Review the synchronization logs from FlySync and KFS. Look for any errors, warnings, or dropped records.

4. Application-Level Testing
   Run the application’s critical business workflows against KingbaseES. Verify that the output matches the expected results.

Failure Indicators

• Row count mismatches.
• Checksum discrepancies.
• Synchronization lag exceeding the defined threshold.
• Application errors during critical workflows.

Failure Scenarios and Rollback Procedures

A robust migration plan includes a clear rollback strategy. The dual-system redundancy architecture provides a safety net for failure scenarios.

Scenario A: Data Inconsistency Detected

If data consistency checks fail during Phase 2 or after cutover:

1. Stop Application Writes: Immediately halt all write transactions to KingbaseES.
2. Revert Connection Strings: Switch the application connection strings back to the Oracle instance.
3. Resume Oracle Operations: Reactivate the Oracle database as the primary system.
4. Investigate Discrepancies: Analyze the synchronization logs to identify the source of the data loss.

Scenario B: KingbaseES Performance Degradation

If KingbaseES fails to meet performance requirements:

1. Scale Resources: Attempt to scale KingbaseES resources (CPU, memory, I/O).
2. Rollback: If performance does not improve, revert to Oracle as the primary system.
3. Optimize Schema: Review the schema and indexes in KingbaseES to identify optimization opportunities before the next attempt.

Scenario C: Critical PL/SQL Failure

If PL/SQL code fails to execute correctly after cutover:

1. Revert to Oracle: Switch traffic back to Oracle.
2. Refactor Code: Fix the PL/SQL code in the test environment.
3. Retest: Re-run the compatibility scan and unit tests.
4. Retry Cutover: Attempt the cutover again once the code is verified.

Rollback Checklist

• Confirm Oracle is in a consistent state.
• Verify application connection strings are updated to Oracle.
• Ensure no data is lost during the rollback process.
• Document the failure reason for future analysis.
• Note: Specific rollback scripts are not provided in the evidence and must be developed based on the specific architecture and vendor guidelines.

Search Intent Fulfillment

This guide provides a high-level architectural overview of the migration strategy from Oracle to KingbaseES. It outlines the dual-system redundancy approach, supported hardware architectures, and the general workflow for schema translation and data synchronization.

Deep-Dive Limitation: This article does not contain specific command-line arguments, configuration file examples, or vendor-validated rollback scripts for FlySync or KFS. To execute a detailed technical migration, users must access the official KingbaseES documentation and verify specific parameters, version compatibility matrices, and tool configurations directly with the vendor.

FAQ

Does the migration require changes to the original application code?

The solution claims to allow smooth migration without changes to original applications or production databases. However, this is contingent on the results of a compatibility scan. You must run a compatibility scan to verify that no unsupported Oracle features are used. If unsupported features are found, code refactoring will be required.

Which domestic CPU architectures are supported for the KingbaseES target environment?

KingbaseES V8 supports domestic CPU architectures including Loongson, Phytium, Zhongguo, and Galaxy. Verify that your target hardware is compatible with these architectures before deployment. Note that "Zhongguo" requires clarification regarding the specific vendor or chip family in your context.

What are the specific version constraints and prerequisites for migrating Oracle to KingbaseES?

Specific version compatibility matrices between Oracle and KingbaseES V8 are not provided in this guide. You must consult the official KingbaseES documentation or contact the vendor to verify the supported Oracle source versions.

Are there vendor-verified tools available for heterogeneous migration to KingbaseES?

Yes. FlySync is used for synchronizing data from Oracle to KingbaseES. KFS is used for synchronizing data from KingbaseES to Oracle. These tools enable real-time data synchronization and dual-system redundancy. Specific configuration commands for these tools must be verified against official documentation.

How can I verify PL/SQL compatibility before executing the migration?

You must extract the Oracle schema definitions and run a compatibility analysis using the vendor-provided tools or a manual review process. Identify unsupported keywords, syntax differences, and complex logic that requires refactoring. Conduct unit testing in a test environment to validate the converted code. Specific conversion rules are not provided in this guide and must be derived from vendor documentation.

Is local support available in Malaysia?

The provided evidence does not confirm the existence of KingbaseES offices, engineers, or data centers in Malaysia. Users should verify local support availability directly with the vendor.

💡 More Resources

If you would like to dive deeper into KingbaseES and its application practices across various industries, we have compiled the following official resources to help you get started quickly and develop and operate with efficiency:

• Kingbase Community: A one-stop interactive platform for technical exchanges, Q&A, and experience sharing—join forces with fellow DBAs and developers.
• Kingbase Solutions: One-stop full-stack database migration and cloud-native solutions, supporting smooth migration of multi-source heterogeneous data, ensuring high availability, real-time integration, and sustained high performance.
• Kingbase Case Studies: Real-world user scenarios and implementation outcomes, showcasing KingbaseES’s outstanding capabilities in high availability, high performance, and IT adaptation.
• Kingbase Documentation: Authoritative and comprehensive product manuals and technical guides, covering the entire lifecycle from installation and deployment to development, programming, and operations management.
• Free Download: Get the latest installation packages, drivers, tools, and patches, supporting multiple platforms and domestic chip architectures.
• Digital Construction Encyclopedia: Covers digital strategy planning, data integration, metrics management, database visualization applications, and more to empower enterprise digital transformation.

Open Source Resources:

• GitHub – Kingbase-docs: Kingbase documentation open-source repository—Stars and contributions are welcome.
• Gitee – Kingbase-docs: Domestic mirror repository for Kingbase documentation for faster access.

Welcome to explore the resources above and begin your Kingbase journey!