Oracle to KingbaseES Migration Checklist_ Prerequisites,

Prerequisites: Defining Version Boundaries and Environment Constraints

Before initiating any migration activity, you must establish the technical baseline. KingbaseES is a commercial product, not an open-source alternative. Licensing and support agreements must be secured before deployment. The migration strategy relies on specific version compatibility between the source Oracle system and the target KingbaseES V009R002C012.

The environment must support the dual-track architecture required for safe data synchronization. This involves provisioning hardware and network resources for both systems to run in parallel. You must verify that the target environment meets the hardware requirements for KingbaseES and that the Oracle source system allows for the necessary read access required by the synchronization tool.

Checklist for Prerequisites:

• License Verification: Confirm commercial licensing for KingbaseES V009R002C012 is active. Do not assume community or trial versions are suitable for production migration.
• Version Compatibility: Verify the supported Oracle source versions. While KingbaseES supports a wide range of Oracle features, specific version constraints exist for the migration tools.
• Network Configuration: Ensure low-latency connectivity between the Oracle primary and KingbaseES target. The KFS tool requires stable, high-throughput connections for real-time incremental synchronization.
• Toolchain Availability: Download and validate the installation packages for KDMS (structure migration assessment), KDTS (one-click migration), and KFS (Kingbase FlySync).
• Role Definition: Assign a dedicated team for the migration. This includes DBAs for schema conversion, developers for PL/SQL refactoring, and architects for the dual-track setup.
• Data Sovereignty Check: Review regulatory requirements for your specific industry. KingbaseES is a commercial product with global deployment capabilities. Do not assume local data center presence or local regulatory approval without explicit vendor confirmation. Users in Malaysia must contact the vendor directly for specific compliance details and local support availability.

Phase 1 Architecture: Setting Up Dual-Track Real-Time Synchronization

The first phase of the migration establishes the "Oracle Primary, KingbaseES Backup" architecture. The goal is to keep both systems in sync while the application continues to write to Oracle. This phase validates the data path and the synchronization engine before any cutover occurs.

You will use the KFS (Kingbase FlySync) tool to enable real-time incremental data synchronization. Note: The provided evidence explicitly supports KingbaseES to Oracle synchronization. While the technical context implies bidirectional capabilities, the specific tool claim for Oracle-to-KingbaseES sync requires verification against the latest vendor documentation. Ensure the configuration aligns with the supported direction for your specific version.

Step-by-Step Setup:

1. Initialize KFS Instance: Deploy the KFS agent on the KingbaseES target server. Configure the agent to connect to the Oracle source database using a dedicated read-only account.
   • Vendor-specific parameters to be verified: Specific configuration file paths and connection string parameters must be confirmed in the KFS documentation.
2. Define Synchronization Rules: Create a synchronization task in the KFS console. Select the specific schemas and tables to replicate. Ensure that the "Oracle Mode" is enabled on the KingbaseES side to handle Oracle-specific data types correctly.
3. Establish Initial Consistency: Run an initial full data load from Oracle to KingbaseES. This populates the target with historical data.
4. Enable Incremental Sync: Switch KFS to incremental mode. The tool will now capture change data capture (CDC) events from the Oracle redo logs and apply them to KingbaseES in near real-time.
5. Monitor Lag: Continuously monitor the replication lag. A lag greater than a few seconds indicates a potential bottleneck. Investigate network throughput or target database load before proceeding.
6. Verify Data Consistency: Run periodic row-count and checksum comparisons between the Oracle source and the KingbaseES target. Ensure that the counts match and that no data corruption occurs during the sync process.

This phase may run for weeks or months depending on the data volume and the stability of the application. Do not proceed to schema migration until the data synchronization is stable and verified.

Schema Assessment: Automating Structure Migration with KDMS

Once the data layer is synchronized, you must assess the schema structure. Complex Oracle objects, such as partitioning strategies, advanced data types, and stored procedures, often require manual intervention. The KDMS (Kingbase Database Migration Assessment) tool automates this assessment by scanning the Oracle database and generating a compatibility report.

KDMS identifies objects that can be automatically converted and those that require manual refactoring. It distinguishes between standard SQL objects and proprietary Oracle extensions.

Assessment Procedure:

1. Connect to Source: Launch KDMS and connect to the Oracle source database.
2. Run Assessment: Execute a full schema assessment. The tool analyzes tables, indexes, views, triggers, sequences, and stored procedures.
3. Review Compatibility Report: Examine the generated report. Look for the "Conversion Success Rate" and the list of "Unsupported Objects."
   • High Success Rate: Standard tables, indexes, and simple views usually convert automatically.
   • Manual Intervention Required: Complex partitioning, specific Oracle system views, and advanced PL/SQL features may need rewriting.
4. Identify Specific Incompatibilities: The report will flag specific objects that do not map directly to KingbaseES. For example, certain Oracle-specific system views may not be available in standard mode but are supported in Oracle Mode.

Key Objects Requiring Attention:

• Partitioning: Verify that the partitioning strategy (e.g., range, list, hash) is supported in KingbaseES.
• System Views: Check if the application relies on specific Oracle system views. KingbaseES V009R002C012 supports views like V$VERSION, V$SESSION, V$LOCKED_OBJECT, ALL_PART_INDEXES, DBA__PART_INDEXES, and USER_PART_INDEXES when Oracle mode is enabled.
• Triggers: Complex triggers with multiple actions or specific exception handling may require syntax adjustments.

PL/SQL Translation: Validating Enhanced Compatibility Features

The most critical part of the migration is the translation of PL/SQL code. KingbaseES V009R002C012 introduces specific enhancements to improve Oracle compatibility. These features reduce the amount of manual refactoring required for complex stored procedures and packages.

You must verify that your code utilizes these features correctly. The KDTS (Kingbase Database One-Click Migration Tool) can perform the initial translation, but you must validate the output against the specific capabilities of KingbaseES V009R002C012.

Enhanced Compatibility Features in V009R002C012:

• ANYDATASET Collection Type: KingbaseES supports the ANYDATASET collection type with member functions and procedures. This allows for dynamic handling of different data types within a single collection, matching Oracle behavior.
• NEW Initialization: The database supports NEW initialization for nested tables and varrays in PL/SQL. This simplifies the initialization of collection variables without requiring manual loop logic.
• DETERMINISTIC Keyword: You can declare the DETERMINISTIC keyword in the package header only. KingbaseES does not require repeating the declaration in the package body, simplifying maintenance.
• PARALLEL_ENABLE: Functions can be declared with the PARALLEL_ENABLE subclause to indicate concurrency support, improving performance for parallel execution.
• Package Capacity: KingbaseES packages support up to nearly 10,000 functions. This is a significant capacity increase compared to older versions or other databases.
• String and Aggregation Functions:
  • The CONCAT function supports arbitrary numbers of parameters in Oracle mode.
  • The LISTAGG function supports the optional WITH GROUP clause.
  • TIMESTAMPADD and multi-format TO_TIMESTAMP functions are supported.

Validation Example:

Consider a stored procedure that initializes a nested table. In standard Oracle, you might use specific syntax. In KingbaseES V009R002C012, the NEW keyword is supported for initialization.

Note: The exact syntax my_table := NEW my_nested_table_type(); is a vendor-specific implementation detail. Verify the precise syntax against the official KingbaseES documentation before executing.

-- Example of NEW initialization (Verify syntax with official docs)
DECLARE
  my_table my_nested_table_type;
BEGIN
  -- Syntax to be verified: my_table := NEW my_nested_table_type();
  my_table := NEW my_nested_table_type();
END;

Action Required:
Run the KDTS tool to convert your PL/SQL objects. Review the generated code for every stored procedure, function, and trigger. Ensure that the NEW keyword is used where appropriate and that the DETERMINISTIC keyword is placed correctly in the package header. Do not assume the tool handles every edge case perfectly.

Data Integrity: Validating Billions of Rows Without Locking Production

Before cutover, you must validate that the data in KingbaseES matches the data in Oracle exactly. This validation must occur without locking the production system or causing performance degradation.

Validation Strategy:

1. Row Count Verification: Compare the row counts of all critical tables between Oracle and KingbaseES. This is a fast, low-overhead check.
2. Checksum Validation: For large tables, use a checksum algorithm (e.g., MD5 or CRC32) on a subset of columns. Calculate the checksum on the Oracle side and the KingbaseES side. Compare the results.
3. Sample Data Comparison: Select random samples of rows from both systems. Compare the values of every column. This ensures that data types and encoding are preserved correctly.
4. Application-Level Testing: Run the application’s read queries against KingbaseES. Verify that the results match the Oracle results. This is the most reliable test for business logic.
5. Continuous Monitoring: During the parallel run, continue to monitor the KFS synchronization lag and the data consistency checks. Any discrepancy must be investigated immediately.

Failure Mode Handling:
If a data inconsistency is detected, pause the KFS synchronization. Investigate the root cause. It could be a data type mismatch, a character encoding issue, or a timing problem in the sync process. Do not proceed with the cutover until all inconsistencies are resolved.

Specific Failure Examples based on KDMS Assessment:

• PL/SQL Compilation Errors: If the KDMS report flags unsupported Oracle-specific functions, the application may fail to start or throw runtime errors.
• Data Type Mismatches: If ANYDATASET or specific collection types are not handled correctly, data insertion may fail or return null values.
• Partitioning Errors: If the partitioning strategy is not fully supported, queries may fail or return incomplete results.

Cutover Execution: Switching to KingbaseES as Primary

The final phase involves switching the application to use KingbaseES as the primary database. This is the "Phase 2" architecture where KingbaseES becomes the primary system and Oracle becomes the backup.

Note: The evidence for "Phase 2" architecture specifically references KingbaseES V8. While V009R002C012 is the target version for this guide, verify that the V009R002C012 version supports the same dual-system cutover strategy as V8.

Cutover Steps:

1. Stop Application Writes: Pause the application to stop writing new data to Oracle. This ensures a clean break point.
2. Final Sync: Allow KFS to complete the final incremental synchronization. Verify that the lag is zero and that the data is fully consistent.
3. Update Connection Strings: Change the application’s database connection strings to point to the KingbaseES instance.
4. Enable Writes: Restart the application. The application now writes to KingbaseES.
5. Monitor Performance: Watch the KingbaseES performance metrics closely. Ensure that the system handles the load without issues.
6. Disable KFS (Optional): Once the system is stable and the Oracle system is no longer needed for writes, you can reconfigure KFS to run in a one-way sync from KingbaseES to Oracle for backup purposes.

Verification:
Confirm that the application is functioning correctly. Run the same validation checks performed in the parallel run phase. Ensure that all business transactions complete successfully.

Rollback Strategy: Executing a Safe Reversion to Oracle

A rollback strategy is essential. If the cutover fails or critical errors are detected, you must be able to revert to the Oracle primary system immediately.

Rollback Procedure:

1. Stop Application Writes: Immediately pause the application to prevent data corruption.
2. Revert Connection Strings: Change the connection strings back to the Oracle instance.
3. Resume Oracle Writes: Restart the application. The application now writes to Oracle again.
4. Synchronize Back: If the application writes to KingbaseES during the failed cutover, you must handle the data divergence.
   • If the cutover window was short, the amount of data written to KingbaseES may be negligible.
   • If significant data was written, you must manually reconcile the data or restore the Oracle system from a backup taken before the cutover.
5. Investigate Root Cause: Analyze why the cutover failed. Was it a PL/SQL error, a performance bottleneck, or a data integrity issue?
6. Re-Plan: Update the migration plan based on the findings. Fix the identified issues before attempting another cutover.

Decision Matrix:

FAQ

What are the specific version constraints for Oracle and KingbaseES in a migration scenario?

KingbaseES V009R002C012 supports a wide range of Oracle versions, but specific constraints apply to the migration tools. Verify the supported Oracle versions in the official KingbaseES documentation before starting. The migration tools (KDMS, KDTS, KFS) must be compatible with both the source Oracle version and the target KingbaseES version.

How can we verify the accuracy of automated PL/SQL translation before production cutover?

Run the KDTS tool to generate the translated code. Manually review the output for every stored procedure and function. Execute the code in a test environment and compare the results with the Oracle version. Pay special attention to complex features like ANYDATASET, NEW initialization, and DETERMINISTIC declarations.

Is there a supported rollback procedure if the migration fails during the final cutover?

Yes. The standard rollback procedure involves stopping the application, reverting the connection strings to Oracle, and restarting the application. If data was written to KingbaseES during the failed cutover, you must reconcile the data or restore the Oracle system from a pre-cutover backup. A tested rollback plan is a mandatory prerequisite for cutover.

What are the documented failure modes for KingbaseES when handling complex Oracle triggers?

Failure modes often include syntax errors in complex trigger logic, unsupported Oracle-specific functions, or data type mismatches. KingbaseES V009R002C012 supports many Oracle features, but not all. The KDMS assessment report will identify specific triggers that require manual refactoring.

How do we validate data sovereignty compliance for a cross-border database migration in Malaysia?

KingbaseES is a commercial product with global deployment capabilities. Regulatory requirements for data sovereignty in Malaysia vary by industry. Do not assume local data center presence or local regulatory approval without explicit vendor confirmation. You must conduct a specific compliance audit for your industry and region. KingbaseES provides the tools for data management, but compliance certification remains the user’s responsibility.

💡 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!