Convert Oracle DDL to MySQL with the right data types and a pre-flight query for every risky column

How do I convert Oracle DDL to MySQL?

Extract the DDL with DBMS_METADATA.GET_DDL or let a converter read the catalog, strip the Oracle storage clauses (TABLESPACE, PCTFREE, STORAGE, LOGGING), swap double quotes for backticks on any quoted identifier, and then map the types. AWS SCT and SQLines both produce a workable first draft, and you will keep most of it. The real work is finding the defaults to reject, because each one produces valid MySQL DDL and a successful load.

One tool you may expect to use is missing from that list. The MySQL Workbench manual names seven supported migration sources: SQL Server, Access, MySQL, PostgreSQL, SQL Anywhere, SQLite and Sybase ASE. Oracle is not one of them. It can only go through the generic ODBC path, which the manual describes as "less automatic", so if your plan assumed Workbench would map Oracle types for you, the mapping table below is the job you actually have.

Oracle to MySQL data type mapping table

Every row was checked against the Oracle 19c SQL Language Reference and the MySQL 8.4 Reference Manual on 1 October 2026. Integer ranges are for signed MySQL types.

What is the MySQL equivalent of Oracle DATE?

DATETIME. Oracle's reference is explicit: "For each DATE value, Oracle stores the following information: year, month, day, hour, minute, and second." MySQL DATE stores the calendar date and nothing else. Converters get this right, and SQLines, for one, publishes DATE to DATETIME. The damage comes from hand-edited DDL, find-and-replace scripts and ORMs that regenerate the schema from names, all of which keep the word DATE and drop the time of day on every row.

Nothing fails when that happens. Row counts match, every date is correct, and the only clue is that every order now appears to have been placed at midnight. The check is one line, listed in the table further down. Run it even if you are sure, because it also tells the business whether reports that group by hour are about to change.

What is the MySQL equivalent of Oracle NUMBER?

It depends on how the column was declared, which is why NUMBER is the hardest type on this route. NUMBER(p,s) with a positive scale is an exact decimal and becomes DECIMAL(p,s). NUMBER(p) is an integer, and the right MySQL integer depends on p: NUMBER(10) can hold 9,999,999,999, which is past the INT ceiling of 2,147,483,647, and NUMBER(19) can exceed BIGINT. A bare NUMBER with no precision is, in Oracle's words, "the maximum range and precision for an Oracle number", and many older schemas declare every money and quantity column that way because Oracle never forced a choice.

The worst choice for any of them is DOUBLE. MySQL's manual says floating-point numbers "are approximate and not stored as exact values", and that comparing them for equality "may lead to problems." Yet the published Oracle to MySQL examples in AWS's SCT guide convert a procedure parameter declared p_state IN NUMBER to par_P_STATE DOUBLE, and a NUMBER variable to DOUBLE as well. SQLines lists bare NUMBER as "DECIMAL(p,s) or DOUBLE". If your procedures add up invoices, change every DOUBLE in the converted signatures to the DECIMAL the table column uses. Totals that are wrong by a fraction of a cent tend to surface later, when customers are sent reminders that disagree with their statements, so check the procedure output and not only the table data.

Does MySQL treat empty strings as NULL like Oracle?

No, and this is the one difference no type mapping can fix. Oracle states that it "treats a character value with a length of zero as null", so an Oracle database has never held an empty string. MySQL stores '' as a value distinct from NULL. The migrated data is fine, because there were no blanks to migrate. The change shows up after cutover, when the same application code that wrote '' into Oracle and got NULL now writes '' into MySQL and gets a blank.

Three things drift from there. Reports that count missing values with IS NULL start to undercount. Columns declared NOT NULL, which in Oracle quietly kept blanks out too, start accepting them. And unique indexes on optional text columns, where Oracle allowed many NULLs, now allow one blank and reject the second. The fix is a decision per column, enforced in MySQL with a CHECK constraint, which MySQL has enforced since 8.0.16.

How do I convert Oracle sequences to MySQL?

MySQL has no CREATE SEQUENCE, so the usual Oracle pattern of a sequence plus a BEFORE INSERT trigger becomes an AUTO_INCREMENT column, and the trigger is dropped. After the load, set every AUTO_INCREMENT above the highest loaded value with ALTER TABLE t AUTO_INCREMENT = n. A sequence shared by several tables, common in older billing schemas, has no direct equivalent and needs a single-row counter table updated in a transaction, or keys generated by the application.

A missed reset is easy to spot, just not in testing. The first real insert after cutover collides with a loaded key, and the symptom is the order or signup endpoint returning errors on a Monday morning. Have something checking your API endpoints every 30 seconds through the cutover window, so the page reaches you before it reaches customers.

Why do table and column names break after the move?

Oracle stores unquoted identifiers in upper case, so a converter emits ORDERS and CUSTOMER_ID. MySQL on Linux keeps table names exactly as created and compares them case sensitively, because the default for lower_case_table_names on Unix is 0. Application SQL written as select * from orders then fails. AWS asks for the setting to be 1 on RDS and Aurora targets, and MySQL 8.4 says it "can only be configured when initializing the server". Set it in the parameter group before you create the instance, or lower-case every name in the DDL.

How do I verify an Oracle to MySQL DDL conversion?

Run the checks on Oracle before the load, not on MySQL after it. Most of them read the data dictionary rather than scanning tables, so the whole list takes about an hour on a schema of any size. Replace APP with the schema owner and t and col with the table and column you are checking.

After the load, reconcile on values rather than counts. For each table compare the row count, the SUM of every numeric column, the MIN and MAX of every date, and the number of rows whose time is not midnight. Then insert one test row per table inside a transaction you roll back, to prove each AUTO_INCREMENT starts in the right place. A green row-count report is the most misleading artifact in this kind of project, because it passes on a migration that dropped every time of day.

Two pieces of scope belong in the plan rather than in a surprise. PL/SQL packages, procedures and triggers need a code converter or a person, and SCT's extension pack emulates several Oracle functions inside the target. The other is ordering: Oracle sorts NULLs last in an ascending ORDER BY and MySQL sorts them first, so any paginated screen that orders on a nullable column shows a different first page. Add an explicit expression such as ORDER BY col IS NULL, col where it matters.

The tool comparison for this route, with what each one bills by, is on our Oracle to MySQL migration tools page. If the target is still undecided, the same source is covered for PostgreSQL in Oracle to PostgreSQL migration tools, with the procedural side in converting PL/SQL to PostgreSQL, and for a warehouse in the Oracle to Snowflake data type mapping. Another commercial engine into the same target is mapped in convert SQL Server data types to MySQL, and the budget model for any of these programs is in what a data migration really costs.