ORACLE数据库迁移至MYSQL方案（2015年）
ORACLE和MYSQL作为两款使用最广泛的关系型数据库软件，在各项功能上以及编程语法上还是存在很大的差异的，因此要实现将系统从ORACLE迁移至MYSQL数据库上，数据的迁移仅仅是一方面，最大的挑战在于代码层面的改动，整个迁移的大致工作如下：
1、ORACLE与MYSQL功能上的区别：
(1)字段类型的对比：
| 序号 |
ORACLE |
MYSQL |
| 1 |
VARCHAR2 |
VARCHAR |
| 2 |
DATE |
DATETIME |
| 3 |
TIMESTAMP |
DATETIME |
| 4 |
NUMBER |
DECIMAL |
| 5 |
INTEGER |
DECIMAL(22,0) |
| 6 |
CLOB |
TEXT |
| 7 |
BLOB |
LONGBLOB |
(2)常用功能语法上的对比：
| 序号 |
对比项 |
ORACLE |
MYSQL |
| 1 |
空字符的判断 |
NAME IS NULL |
NAME=' ' |
| 2 |
from |
select 1 from dual; |
select 1; |
| 3 |
like的用法 |
NAME like 'a%' |
NAME like 'a%' |
| 4 |
日期格式化 |
获取系统日期:SYSDATE() |
获取系统日期:now() |
|
|
主键 |
一般通过Oracle序列生成： |
Auto_increment属性实现自增获得唯一值 |
| 5 |
分页(常用写法) |
SELECT T2.* |
SELECT * FROM TEST_TEST1 ORDER BY SID DESC LIMIT 0,4 |
| 6 |
字符串链接 |
SELECT sid || username|| PASSWORD FROM TEST |
SELECT CONCAT(SID , USERNAME, PASSWORD) FROM TEST |
| 7 |
分组函数 |
SELECT EMPNO,JOB, COUNT(1), SUM(SAL),SUM(COMM) FROM EMP; |
SELECT EMPNO,JOB, COUNT(1), SUM(SAL),SUM(COMM) FROM EMP; |
| 8 |
分析函数 |
row_number() over (partition by xx order by xx) |
Mysql不支持 |
| 9 |
并行 |
支持SQL级别并发处理 |
不支持 |
(3)数据库对象类型对比：
| 序号 |
数据库对象类型 |
ORACLE |
MYSQL |
迁移方案 |
| 1 |
PROCEDURE |
(1)建存储过程用create procedure XXX 或 create or replace procedure XXX 两种语法 |
(1) 建存储过程只能用create procedure XXX一种语法 |
由于ORACLE跟MYSQL编写存储过程的语法差异，需重新修改存储过程代码 |
| 2 |
TRIGGER |
(1)包含DML触发器、替代触发器(视图)、系统触发器（DDL语句/系统事件） |
(1)只支持DML触发器 |
由于语法差异以及触发器功能实现的差异，需修改触发器代码 |
| 3 |
FUNCTION |
支持 |
支持 |
|
| 4 |
PACKAGE |
支持 |
不支持 |
需将PACKAGE使用存储过程替换 |
| 5 |
VIEW |
支持 |
支持 |
如涉及到使用MYSQL不支持的内置函数需转换 |
| 6 |
Materialized view |
支持 |
不支持 |
采用视图替换或者修改代码直接方案基表方式 |
| 7 |
JOB |
支持比较完善 |
支持比较简单 |
按需修改 |
| 8 |
DBLINK |
支持 |
无 |
可使用FEDERATED引擎实现dblink访问功能，需修改程序代码 |
| 9 |
SEQUENCE |
支持 |
无 |
可使用MYSQL自增列实现序列功能，需修改表结构添加自增列 |
| 10 |
SYNONYMS |
支持 |
无 |
需修改程序代码直接访问物理表 |
| 11 |
CURSOR |
(1)静态游标(隐式游标,显示游标)、ref游标 |
(1)只支持静态游标 |
由于功能上的差距，需修改CURSOR代码 |
2、程序代码上的改动：
(1)前台代码改动：
由于前台代码均采用标准的SQL编写，需要改动的内容相对较少，主要考虑MYSQL内置函数的差异上需要改动，需梳理前台代码。
(2)后台代码改动：
由于涉及不同数据库在功能上以及编程语法上的差距，因此后台代码的改动将非常大，包括数据类型的差异、对象类型的差异、编程语法上的差异等等，整个后台的代码几乎相当于重新编写，工作量非常巨大，经过调查，针对我们目前的数据库，有如下部分数据对象需要修改：
附表格：
| OWNER |
OBJECT_TYPE |
数量 |
整改措施 |
| QHIEX_PROD |
PACKAGE |
4 |
需将PACKAGE使用存储过程替换 |
| QHIEX_PROD |
PROCEDURE |
1 |
由于ORACLE跟MYSQL编写存储过程的语法差异，需重新修改存储过程代码 |
| QHIEX_PROD |
SEQUENCE |
155 |
可使用MYSQL自增列实现序列功能，需修改表结构添加自增列 |
| QHIEX |
SEQUENCE |
98 |
可使用MYSQL自增列实现序列功能，需修改表结构添加自增列 |
3、ORACLE数据迁移至MYSQL
(1)字段类型的调整：
数据迁移主要需要注意的地方在于字段类型支持的差异上，比如ORACLE常用的VARCHAR2类型以及CLOB类型在MYSQL中都不存在，因此我们需要稍微调整下字段类型，针对我们数据库目前的现状，有如下字段类型需要修改：
附表：
| DATA_TYPE |
COUNT(*) |
整改措施 |
| VARCHAR2 |
3194 |
使用MYSQL VARCHAR类型替代 |
| NUMBER |
1522 |
使用MYSQL DECIMAL类型替代 |
| DATE |
776 |
使用MYSQL DATETIME类型替代 |
| CHAR |
544 |
无需整改 |
| CLOB |
89 |
使用MYSQL TEXT类型替代 |
| NVARCHAR2 |
34 |
使用MYSQL VARCHAR类型替代 |
| TIMESTAMP(6) |
16 |
使用MYSQL DATETIME类型替代 |
| BLOB |
12 |
使用MYSQL LONGBLOB类型替代 |
| FLOAT |
6 |
无需整改 |
| LONG RAW |
4 |
使用MYSQL LONGTEXT类型替代 |
| LONG |
2 |
使用MYSQL LONGTEXT类型替代 |
(2)数据迁移：
目前MYSQL官方发布了一个将数据由SQL Server或Oracle中移植到MySQL中的工具包MySQLMigration Toolkit，该工具支持LOB字段数据的迁移，由于个创数据库目前的数据量相对较少，数据量目前统计将近17G左右，可以在停机的状态下使用该工具进行数据迁移，经过统计，目前个创数据库的表清单数量以及数据量分布如下：
附表：
| OWNER |
数量 |
数据量 |
| QHIEX_PROD |
357 |
6.7G |
| QHIEX |
162 |
10G |
4、系统测试（包括数据迁移的测试）
程序经过大量的修改后，测试以及BUG的修复往往是耗时最长也是最为重要的一环，各个功能都需要经过全面的测试以及验证工作，从而避免生出上线后出现的各种问题