This article explains how to use DSC to migrate Oracle SQL/PLSQL scripts offline to GaussDB(DWS). It focuses on the two conversion modes, Bulk and BLogic, as well as log-based troubleshooting and PACKAGE migration prerequisites, helping teams reduce script refactoring complexity, downtime risk, and manual rewrite costs. Keywords: GaussDB(DWS), Oracle migration, DSC.
Technical specifications are easy to review at a glance
| Parameter | Description |
|---|---|
| Tool name | DSC (Database Schema Convertor) |
| Target database | GaussDB T / GaussDB A / GaussDB(DWS) |
| Source database | Oracle, Teradata, Netezza, MySQL, DB2 |
| Execution mode | Command-line tool |
| Operating system | Linux, Windows |
| Connection method | Offline execution, no direct connection to the source database required |
| Typical protocols/interfaces | Local file input/output, log archiving |
| GitHub stars | Not provided in the source |
| Core dependencies | Java runtime environment, DSC executable scripts/tool package |
The hardest part of this migration is application SQL scripts rather than the data itself
When an enterprise moves from Oracle to GaussDB(DWS), the highest-risk area is usually not data movement. The real challenge is compatibility refactoring for application-layer SQL, DDL, and PL/SQL. Manual script rewrites are slow and can easily introduce semantic drift.
DSC standardizes this process. It reads exported script files, applies built-in syntax conversion logic, generates target scripts compatible with GaussDB, and outputs logs at the same time so teams can perform batch auditing before migration.
You can quickly determine whether DSC fits your migration scope
DSC supports migration for SQL schemas, SQL queries, and procedural objects from some databases. In Oracle scenarios, it can process both standard DDL and PL/SQL, but you should use different conversion modes for each.
# Core decision logic: identify the script type first
# 1. Standard DDL such as tables, views, indexes, and sequences -> bulk
# 2. PL/SQL-based objects such as functions, procedures, and packages -> blogicThis decision determines the command parameters and migration order. It is the first major branch in the entire workflow.
The standard DSC migration workflow should follow three steps
First, export the Oracle SQL scripts that you want to migrate to a Linux or Windows server where DSC is installed. The input here is a file set, not a live database connection.
Second, run the DSC command and explicitly specify the input directory, output directory, log directory, source database type, application language, and conversion type. Third, inspect the conversion results and log files in the output directories to locate errors and make follow-up corrections.
Use the following command to migrate standard Oracle DDL on Linux
./runDSC.sh \
--source-db Oracle \
--input-folder /opt/DSC/DSC/input/oracle/ \
--output-folder /opt/DSC/DSC/output/ \
--log-folder /opt/DSC/DSC/log/ \
--application-lang SQL \
--conversion-type bulk \
--targetdb gaussdbAUse this command to batch-convert standard DDL that does not contain PL/SQL, such as tables, views, indexes, and sequences.
Use the same parameter structure for standard Oracle DDL migration on Windows
runDSC.bat ^
--source-db Oracle ^
--input-folder D:\test\conversion\input ^
--output-folder D:\test\conversion\output ^
--log-folder D:\test\conversion\log ^
--application-lang SQL ^
--conversion-type bulk ^
--targetdb gaussdbAThe main differences between Windows and Linux are the script entry point and path syntax. The migration semantics remain the same.
Bulk mode is best for fast batch conversion of structural objects
Bulk mode targets standard DDL and works well for structural scripts such as tables, views, indexes, and sequences. Its advantages are speed and low dependency requirements, which makes it ideal for establishing the target-side schema foundation and type context first.
After execution finishes, the console displays migration progress, file count, log path, and elapsed time. The log file is the primary source for locating failed statements and incompatible syntax.
********************** Schema Conversion Started *************************
DSC process start time : Mon Jan 20 17:24:49 IST 2020
Statement count progress 100% completed [FILE(1/1)]
Schema Conversion Progress 100% completed
Total number of files in input folder : 1
Log file path : ....../DSC/DSC/log/dsc.log
DSC process end time : Mon Jan 20 17:24:49 IST 2020
DSC total process time : 0 seconds
********************* Schema Conversion Completed ************************This output indicates that the tool completed file-level conversion. Your next focus should be log auditing and result validation.
BLogic mode is used for procedural objects such as functions, procedures, and PACKAGEs
If the script contains PL/SQL logic such as functions, stored procedures, or package definitions, switch to BLogic mode. These objects involve variable declarations, control flow, type inference, and contextual dependencies, so their conversion complexity is significantly higher than standard DDL.
The original material also shows that you can run the tool through a Java JAR entry point. In practice, this is still the same migration toolchain.
java -jar migrationtool.jar \
--source-db Oracle \
--input-folder D:\test\migration\input \
--output-folder D:\test\migration\output \
--log-folder D:\test\migration\log \
--application-lang SQL \
--conversion-type blogicUse this command to migrate Oracle objects that include procedural logic, such as functions, procedures, and PACKAGEs.
After BLogic execution, review the valid file count and error logs carefully
Compared with Bulk mode, BLogic output often includes additional fields such as valid files and error log information. This means the tool is not only converting content, but also screening input validity.
Total number of files in input folder : 1
Total number of valid files in input folder : 1
Error Log file :
Log file path : ....../DSC/DSC/log/dsc.logIf the number of valid files is smaller than the total input count, some scripts usually fail the tool’s preprocessing conditions due to formatting, encoding, or syntax boundary issues.
Oracle PACKAGE migration must follow a context-first, logic-second sequence
PACKAGE migration is a classic Oracle migration challenge. The original requirement is explicit: the package specification and package body must be split into separate files and placed in the same input path for migration.
More importantly, if a PACKAGE contains declarations such as tbName.colName%TYPE, which depend on table column types, you cannot skip the Bulk phase. You must migrate the related table creation scripts first so that the tool can build the necessary data dictionary context before it migrates the PACKAGE.
CREATE OR REPLACE PACKAGE p_emp AS
-- Define a RECORD type
TYPE re_emp IS RECORD(
rno emp.empno%TYPE,
rname emp.empname%TYPE
);
END;This Oracle package specification depends on the column types of the emp table. Without the prerequisite table structure context, the tool cannot expand these types correctly.
Running Bulk first allows DSC to generate a type dictionary for BLogic
GaussDB does not currently support Oracle-style tbName.colName%TYPE syntax directly inside CREATE TYPE, so the migration tool must first resolve the actual data types of emp.empno and emp.empname.
After Bulk mode migrates the table creation scripts, DSC generates the corresponding dictionary metadata internally. Then, when you run BLogic, the record type can be expanded into an explicit type definition.
CREATE TYPE p_emp.re_emp AS (
rno NUMBER(4),
rname VARCHAR2(10)
);This shows that PACKAGE migration is not just a single-command task. It is a staged conversion process that depends on context.
The QR codes and brand images do not carry core technical information
AI Visual Insight: This image shows a community QR code intended to guide readers into a discussion group. It does not include database migration topology, command execution output, or architecture details, so it has no direct technical value for migration implementation.
AI Visual Insight: These images display a WeChat profile card and account branding. They provide contact information only and do not involve DSC parameters, Oracle compatibility rules, or GaussDB(DWS) target object mappings, so you can safely ignore them during technical review.
A layered validation strategy makes Oracle to GaussDB(DWS) migration more reliable
First, verify that standard DDL can be generated and executed successfully on the target side. Next, validate whether logical objects such as functions, procedures, and packages preserve semantic equivalence. Finally, run end-to-end application integration tests. This approach separates structural issues, syntax issues, and runtime issues into distinct validation layers.
For team collaboration, the safest approach is to organize input scripts by object type in separate directories and archive Bulk and BLogic logs independently. This prevents issue triage from becoming noisy and overlapping.
# Recommended directory layout
input/
ddl/ # Tables, views, indexes, sequences
plsql/ # Functions, procedures, package spec, package body
output/
log/This directory split significantly improves maintainability and traceability during batch migration.
FAQ
1. Why does DSC enable a zero-downtime-style migration approach?
Because DSC processes offline exported SQL scripts rather than rewriting objects directly in the production database. It can complete syntax conversion without a direct database connection, which allows teams to finish most script migration work in advance while the business remains online.
2. How should you choose between Bulk and BLogic?
Use Bulk for standard DDL. Use BLogic for PL/SQL-based functions, procedures, and PACKAGEs. If an object depends on table column type inference, run Bulk first to build the dictionary, and then run BLogic.
3. What are the most common pitfalls in PACKAGE migration?
First, the package specification and package body are not split into separate files. Second, the related table creation scripts are not migrated first, so declarations such as %TYPE cannot be expanded. Third, teams trust the console success message alone and fail to inspect partial syntax conversion failures in the logs.
Core takeaway: This article focuses on application SQL script migration from Oracle to GaussDB(DWS). It systematically explains the capability boundaries of DSC, the migration workflow, the differences between Bulk and BLogic modes, execution commands, and PACKAGE migration precautions, helping teams complete database syntax conversion offline and with lower risk.