1.3.5. ORACLE转GOLDENDB_MYSQL功能约束汇总

1.3.5.1. 支持版本

GOLDENDB_MYSQL V_ALL-DBV6.1.03.10SP1P1

1.3.5.2. 升级脚本

统一SQL自定义对象脚本可以通过升级工具进行执行，打入目标数据库。建议使用超级用户执行，或者通过具有 CREATE 、EXECUTE、GRANT、SELECT、UPDATE、INSERT权限的用户来执行。 unisql-upgrade-.jar 升级工具jar包位于sql 目录下
业务使用的用户或后续新增的用户，需要确保有访问database和schema的权限。分配方法如下，需要root用户来执行： call unisql.GrantUnisqlPermissions(); 如果初始化时指定了非unisql数据库。则 call 指定的数据库.GrantUnisqlPermissions();

1.3.5.3. sqlplus命令行指令

PROMPT 指令仅替换为无功能的sql(例如: select 1)，不兼容实际功能。具体替换的sql可通过配置项 unisql.global.replace.sql 配置。另外如果需要兼容多条语句合并转换的情况，需要开启配置项 unisql.splitsql.transform.multisql 为1。

1.3.5.4. 语法约束

insert all 不支持多表插入，一条语句仅支持插入一个表；例如：

insert all into t1 values (...) into t2 values (...) select 1 from dual

insert all 语句中的 select 语句会被忽略.
rownum 仅支持 >, >=, =, <=, < 操作符及能用作别名
comment语句仅支持表表注释，不支持列注释(不报错不生效)。
表空间不支持 create/drop tablespace 均是语法糖处理，并且语法中 datafile 仅支持一个。
create/drop user高级选项不支持，例如 DEFAULT TABLESPACE、TEMPORARY TABLESPACE、CASCADE 选项均会被忽略
create user 语句不支持在匿名块中执行
create sequence 在使用 cycle 选项时需要加 cache 选项
grant赋权支持 CONNECT, RESOURCE, DBA, UNLIMITED TABLESPACE, CREATE/DROP/INSERT/UPDATE/DELETE/SELECT ANY TABLE, CREATE/DROP ANY INDEX, CREATE ANY DIRECTORY 但权限范围不完全一致。
GRANT一条语句仅支持一个permission和一个user;

1.3.5.4.1. 删除索引

DROP [ hint ] INDEX [schema.]index_name;

hint 仅处理 unisql_table_name(table_name), table_name 仅支持 [schema.]table_name, 其他格式不支持
有 hint，先从 hint 中查找表名；未获取到表名，再从元数据中查找表名；都没查到，报索引对应表查找失败

1.3.5.4.2. 索引重命名

ALTER [ hint ] INDEX [schema.]current_index_name RENAME TO new_index_name;

hint 仅处理 unisql_table_name(table_name), table_name 仅支持 [schema.]table_name, 其他格式不支持
有 hint，先从 hint 中查找表名；未获取到表名，再从元数据中查找表名；都没查到，报索引对应表查找失败

1.3.5.5. 存储过程

存储过程和函数不支持转换，仅部分支持匿名块(见下文).

1.3.5.6. 匿名块限制

1.3.5.6.1. 变量数据类型差异

BINARY_FLOAT, BINARY_DOUBLE 源库和目标库精度存在差异，以实际目标库为准。如1.3 在Oracle中输出为1.29999995E+000（不同环境可能存在差异），而在Goldendb-MySQL中输出为1.3 。
CHAR(N) CHARACTER(N) NCHAR(N) 最大支持255 。
NCHAR VARYING(N) NVARCHAR2(N) RAW(N) 最大支持2000 。
VARCHAR2(N) VARCHAR(N) Oracle N 最大支持32767, Goldendb-MySQL N 最大支持16383 。
DECIMAL(p,s) DEC(p,s) NUMBER(p,s) NUMERIC(p,s) p 应该位于 [1,38] 之间，s 应该位于 [0,30] 之间，s应该小于p ，另外ORACLE中小数0会截断掉，Goldendb-MySQL中小数0会保留。
FLOAT Oracle 与 Goldendb-MySQL 精度存在差异，目标库精度更高。

1.3.5.6.2. 变量声明

不支持BLOCK中出现重名的变量
单行注释只支持独立一行的场景，但不支持混入到一个语句中的场景，如下示例不支持：

EXECUTE IMMEDIATE v_sql
        INTO v_emp_name, v_salary -- 接收查询结果
        USING v_emp_id; -- 传入绑定变量值

1.3.5.6.3. 注释

转换后注释将会被丢弃

1.3.5.6.4. 异常

预定义的异常仅支持: NO_DATA_FOUND 和 OTHERS ，其他的异常未做支持。
ORACLE 匿名块静态语句时编译时会检查语义，因此不会触发运行时异常。而Goldendb-MySQL 编译时未检查语义，因此会触发运行时异常。所以 OTHERS 在源库不会捕捉到这类异常，而在目标库中会捕捉到。例如：静态语句SELECT 查询不存在的表。
ORACLE 会产生除0异常，而Goldendb-MySQL中不会产生除0异常，因此 OTHERS 在源库可以捕获到该类异常，而在目标库不会不会到该类异常。
sqlcode 使用的是目标库的 MYSQL_ERRNO ; sqlerrm 使用的是目标库的 MESSAGE_TEXT 。 Oracle和Goldendb-MySQL的错误码和错误信息是不一致的，以实际运行时的错误码和错误信息为准。
GOLDENDB_MYSQL 存在部分版本不支持定义 sqlcode 和 sqlerrm 变量，所以会将 sqlcode 和 sqlerrm 替换为 unisql_mysql_errno 和 unisql_message_text 。替换范围为赋值语句和存储过程调用表达式，其他语句不支持。

1.3.5.6.5. 错误码

sqlcode 使用的是目标库的 MYSQL_ERRNO ; sqlerrm 使用的是目标库的 MESSAGE_TEXT 。 Oracle和Goldendb-MySQL的错误码和错误信息是不一致的，以实际运行时的错误码和错误信息为准。

1.3.5.6.6. 动态SQL

当且仅当 dynamic_sql_string 为字符串文本时，会对 dynamic_sql_string 进行SQL语句转换，其他情况（EXECUTE IMMEDIATE 变量，EXECUTE IMMEDIATE 表达式）只会透传。如果透传语句中包含了绑定参数，因为目标库不支持 :1 的语法，会报错。
当 dynamic_sql_string 使用Q语法(不支持多字节的Q语法）包裹字符串时，转后会改写为单引号的形式。
USING bind_arg 未支持指定OUT/IN修饰关键字。
USING bind_arg 语句中的绑定参数个数需要与 USING 指定的绑定参数个数完全一致。
不支持动态语句中为匿名块。

1.3.5.6.7. 游标

只支持静态游标
不支持游标带参数
隐式游标只支持notfound和isopen，并且只支持在IF/CONTINUE/EXIT中判断隐式游标
如 FOR xx IN (SELECT 语句）形式的 CURSOR FOR中 xx变量的访问仅支持赋值语句和存储过程调用表达时中有效访问，如 v := xx.v
记录类型遍历，如下例子中, 在Oracle中variable必须是记录类型，不能是简单类型。而目标库中并不支持记录类型
```
CURSOR FOR
FOR variable IN ( Select ... ) LOOP
        statements
END LOOP;
```
统一SQL会转换为简单类型列表，且使用text类型接收结果。这会导致variable不支持整体使用，这会触发隐式转换可能会导致预期结果不一致。

1.3.5.6.8. 标签

不支持匿名块带标签名称。

1.3.5.7. 函数限制

1.3.5.7.1. `TO_NUMBER` 函数

不支持第三个参数调用（nls_language）

不支持 DEFAULT ... ON CONVERSION ERROR 子句

select TO_NUMBER('abc' DEFAULT 0 ON CONVERSION ERROR) from dual;

fmt参数仅支持部分格式例如，TO_NUMBER('123.40', '999.99') 是支持的，而 TO_NUMBER('123.40', 'FM999.99') 是不支持的。

1.3.5.7.2. REGEXP_REPLACE 函数

因 GoldenDB 的限制，REGEXP_REPLACE 的第二，第三个参数仅支持字符串常量表达式，不支持其他格式，如：列，函数，子查询，绑定参数等.

例如, 以下均不支持:

-- 列表达式
SELECT REGEXP_REPLACE(t_table.source_col, t_table.pattern_col, '替换值') FROM t_table;

-- 函数调用
SELECT REGEXP_REPLACE('abc123def', SUBSTR('\d+', 1, 2), '数字') FROM dual;

-- 子查询
SELECT REGEXP_REPLACE('abc123def', (SELECT '\d+' FROM dual), '数字') FROM dual;

正则表达式中反斜杠处理行为与Oracle不一致在 Oracle 反斜杠不带转义，而 GoldenDB 中会进行转义，所以需要 '\\\\' 匹配 \\ 字符串
```
-- GoldenDB中执行报错
SELECT REGEXP_REPLACE('abc\def', '\\') AS result FROM dual;
```
正则表达式本身的兼容性依赖 GoldenDB 本身的支持，本版本未充分测试。

函数REGEXP_REPLACE 参数6 match_param取值x 在goldendb-mysql执行报错，具体报错sql和报错信息示例如下:

-- GoldenDB中执行报错
SELECT REGEXP_REPLACE('a b c', 'a b c', 'XX', 1, 1, 'x');
-- ERROR 1210 (HY000): Incorrect arguments to regexp_replace

1.3.5.7.3. REGEXP_SUBSTR 函数

因 GoldenDB 的限制，REGEXP_REPLACE 的第二个参数仅支持字符串常量表达式，不支持其他格式，如：列，函数，子查询， 绑定参数 等. 同 REGEXP_REPLACE 函数的限制1。
正则表达式反斜杠转义行为同 REGEXP_REPLACE 函数的说明
正则表达式本身的兼容性依赖 GoldenDB 本身的支持，本版本未充分测试。

参数5 match_param取值x 在goldendb-mysql执行报错，具体报错sql和报错信息示例如下:

-- GoldenDB中执行报错
SELECT REGEXP_SUBSTR('dacdACD', 'a.d', 1, 1, 'x') AS a FROM dual;
-- ERROR 1210 (HY000): Incorrect arguments to regexp_replace

不支持第6个参数

1.3.5.7.4. ROW_NUMBER 函数

不能在WHERE子句中直接引用，需通过子查询/CTE包装

-- 直接引用会报错
SELECT col1 FROM table_name WHERE ROW_NUMBER() OVER (ORDER BY col2) <= 10;

ORDER BY列无唯一标识时，行号顺序非确定性
```
SELECT employee_id, salary, ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn FROM employees;
```
若ORDER BY列（如salary）存在重复值，多次执行可能返回不同的行号顺序，顺序随机。

PARTITION BY 和 ORDER BY 子句不支持使用数字，报错sql示例如下：

-- 在goldendb-mysql执行报错
SELECT id, ROW_NUMBER() OVER(ORDER BY 3 DESC) as rn FROM test_table;
SELECT id,id1,name,ROW_NUMBER() OVER (PARTITION BY 2 ORDER BY id) AS rn FROM test_table;
-- ERROR 3592 (HY000): Window '<unnamed window>': ORDER BY or PARTITION BY uses legacy position indication which is not supported, use expression.

1.3.5.7.5. LTRIM/RTRIM 函数

字符串类型支持 CHAR, VARCHAR
输入参数如果是数值类型，不保证结果严格一致例如：如下sql在oracle中为 .23 而在goldendb中为 23 sql SELECT LTRIM(1.23 ,1.0) from DUAL
输入和返回字符串支持最大长度为16383个字符

1.3.5.7.6. TO_CHAR 函数

仅支持一个和两个参数。
to_char(null) 在 oracle 中返回空字符串，而在oracle中返回null。
to_char 的第二个参数仅支持字符串常量;
to_char 第一个参数支持类型timestamp, date, int, number, decimal, float, double。其中number和decimal需要带精度;
to_char 第二个参数支持时间格式 YYYY/YY/MM/DD/HH24/HH12/MI/SS/MON, 数值常量格式 9/0/./FM ;

1.3.5.7.7. SUBSTR 函数

SUBSTR(str,pos[,len])

Oracle 和 GoldenDB-MySQL 在数值的内部存储和显示格式上存在差异。例如，对于数值 0.01，Oracle 在某些情况下（如使用默认格式化规则时）可能显示为 .01，而 GoldenDB-MySQL 则保留前导 0，显示为 0.01。此外，对于精度超过 38 位的数值和 Char 数据类型存储固定字符数的数值，两者的处理方式不一致。
日期类型的行为受日期格式影响，不同的日期格式可能导致 GoldenDB-MySQL 和 Oracle 的行为不一致。
在 GoldenDB-MySQL 中， pos 和 len 类型为整数。当处理浮点数时，Oracle 和 GoldenDB-MySQL 都会隐式转换为整数。然而，Oracle 向零取整，而 GoldenDB-MySQL 则是四舍五入。
在 GoldenDB-MySQL 中，null 和空字符串不相等，而在 Oracle 中，null 和空字符串被视为相等，均为 null。
pos 和 len 参数不支持空字符串。
不支持作为列的默认值使用：在实现 SUBSTR 功能时，使用自定义函数，而 GoldenDB-MySQL 的列默认值不允许调用自定义函数。

1.3.5.7.8. RPAD 函数

RPAD(str,len[,padstr])

Oracle 和 GoldenDB-MySQL 在数值的内部存储和显示格式上存在差异。例如，数值 0.01 在 Oracle 中可能在某些情况下（如使用默认格式化规则时）显示为 .01，而在 GoldenDB-MySQL 中则保留前导 0，显示为 0.01。此外，对于精度超过 38 位的数值以及以 Char 数据类型存储固定字符数的数值，两者的处理方式不一致。
日期类型的行为受日期格式影响，不同的日期格式可能导致 GoldenDB-MySQL 和 Oracle 的行为不一致。
在 GoldenDB-MySQL 中， len 类型为整数。不支持空字符串。
返回值的数据类型不一致，oracle的返回值数据类型和 str的数据类型保持一致，GoldenDB-MySQL的返回值数据类型是 varchar。
不支持作为列的默认值使用：在实现 RPAD 功能时，使用自定义函数，而 GoldenDB-MySQL 的列默认值不允许调用自定义函数。

1.3.5.7.9. LPAD 函数

LPAD(str,len[,padstr])

Oracle 和 GoldenDB-MySQL 在数值的内部存储和显示格式上存在差异。例如，数值 0.01 在 Oracle 中可能在某些情况下（如使用默认格式化规则时）显示为 .01，而在 GoldenDB-MySQL 中则保留前导 0，显示为 0.01。此外，对于精度超过 38 位的数值以及以 Char 数据类型存储固定字符数的数值，两者的处理方式不一致。
日期类型的行为受日期格式影响，不同的日期格式可能导致 GoldenDB-MySQL 和 Oracle 的行为不一致。
在 GoldenDB-MySQL 中， len 类型为整数。不支持空字符串。
返回值的数据类型不一致，oracle的返回值数据类型和 str的数据类型保持一致，GoldenDB-MySQL的返回值数据类型是 varchar。
不支持作为列的默认值使用：在实现 LPAD 功能时，使用自定义函数，而 GoldenDB-MySQL 的列默认值不允许调用自定义函数。

1.3.5.7.10. NVL 函数

NVL(param1, param2)

Oracle 和 GoldenDB-MySQL 在数值的内部存储和显示格式上存在差异。例如，对于数值 0.01，Oracle 在某些情况下（如使用默认格式化规则时）可能显示为 .01，而 GoldenDB-MySQL 则保留前导 0，显示为 0.01。此外，对于精度超过 38 位的数值和 Char 数据类型存储固定字符数的数值，两者的处理方式不一致。
日期类型的行为受日期格式影响，不同的日期格式可能导致 GoldenDB-MySQL 和 Oracle 的行为不一致。
在 GoldenDB-MySQL 中，null 和空字符串不相等，而在 Oracle 中，null 和空字符串被视为相等，均为 null。
Oracle param1 和 param2不支持的类型转换：（1）param1 为日期类型，param2 必须为时间类型；（2）param1 为字符串类型，param2 为不能为日期类型；GoldenDB-MySQL没有这个限制。
GoldenDB-MySQL 语法不支持 having 子句的表达式中nvl函数包含表字段。

1.3.5.8. 系统视图

所支持的系统视图中 owner 字段为数据库名称，需保证用户名和数据库名相同。
all_objects 表中的object_type 字段含义可能有差异，在 GoldenDB 仅包含 TABLE、VIEW、INDEX、SEQUENCE， GoldenDB 的TABLE不仅仅指的单纯的表，还包含分区表的分区。DATA_OBJECT_ID、OBJECT_ID由于数据库的差异，生成内容也有差异。
all_users 中的username字段仅表示用户，USER_ID固定为null，CREATED 字段可能受密码变更的影响, username是大小写敏感的。
使用双引号包裹的标识符，在oracle是大小写敏感的而在goldendb中是大小写不敏感的。
索引建议显式命名，系统自动命名的索引和oracle不一致
user_ind_columns/all_ind_columns 视图中 column_length 字段不保证和oracle一致
Oracle的all_objects 用户可查询显示当前用户有权限访问的（包括自己创建的和被授权的）的相关对象，而GoldenDB all_objects可查询整个数据库的相关对象，若仅查询当前用户有权限访问的对象，可在where子句中对owner进行条件限制；
GoldenDB 视图字符字段的collation默认设置为utf8_general_ci，如果指定视图字符字段比较时候，要保持比较两端的collation一致,而源库Oracle就没有这样的要求;
all_indexes视图
- 目标库创建后的OWNER, INDEX_NAME, INDEX_TYPE, TABLE_OWNER, TABLE_NAME默认为小写，为了和oracle保持一致使用all_indexes视图时，都转成了大写
- 索引名称未指定时，两边库自动生成的索引名称不一致
- 主键索引目标库为 PRIMARY
- INDEX_TYPE,两边库特性不一样因此有些不一致
- OWNER 字段在目标库中仅仅指的是数据库名称，目标库可指用户或模式名称；
- 在oracle是查询当前用户有权限的对象，goldendb_mysql那边information_schema.all_*无论有无权限都查询出来。所以使用需要加上owner过滤条件，否则目标库查询出来的会多很多。
user_indexes视图
- 目标库创建后的OWNER, INDEX_NAME, INDEX_TYPE, TABLE_OWNER, TABLE_NAME默认为小写，为了和oracle保持一致使用all_indexes视图时，都转成了大写
- 索引名称未指定时，两边库自动生成的索引名称不一致
- 主键索引目标库为 PRIMARY
- INDEX_TYPE,两边库特性不一样因此有些不一致
- OWNER 字段在目标库中仅仅指的是数据库名称，目标库可指用户或模式名称；
- 只能查询到有权限的表
user_tables视图
- 目标库创建后的TABLE_NAME , TABLESPACE_NAME , CLUSTER_NAME , IOT_NAME默认为小写，为了和oracle保持一致使用user_tables视图时，都转成了大写
- TABLESPACE_NAME，两边库特性不一样因此不一致
- 需要保证用户名和数据库名相同，会将当前的数据库名当作用户名；
- 只能查询到有权限的表

all_tab_columns视图

目标库创建后的OWNER ,TABLE_NAME , COLUMN_NAME , DATA_TYPE, DATA_TYPE_MOD, DATA_TYPE_OWNER默认为小写，为了和oracle保持一致使用all_tab_columns视图时，都转成了大写
OWNER 字段在目标库中仅仅指的是数据库名称，目标库可指用户或模式名称；
在oracle是查询当前用户有权限的对象，goldendb_mysql那边information_schema.all_*无论有无权限都查询出来。所以使用需要加上owner过滤条件，否则目标库查询出来的会多很多。

DATA_TYPE通过统一sql转换后类型不一致，使用时需要注意，如下：

Oracle DATA_TYPE

统一SQL转换后DATA_TYPE

自定义all_tab_columns视图中DATA_TYPE

BINARY_FLOAT

float

FLOAT

BINARY_DOUBLE

double

DOUBLE

BLOB

longblob

LONGBLOB

CLOB

longtext

LONGTEXT

NCLOB

longtext

LONGTEXT

CHAR

char

CHAR

CHARACTER

char

CHAR

DATE

datetime

DATETIME

TIMESTAMP

timestamp

TIMESTAMP

DECIMAL

decimal

DECIMAL

DEC

dec

DECIMAL

NUMBER

decimal

DECIMAL

NUMERIC

numeric

DECIMAL

DOUBLE PRECISION

double

DOUBLE

FLOAT

float

DOUBLE

REAL

real

DOUBLE

INTEGER

bigint

BIGINT

INT

bigint

BIGINT

SMALLINT

bigint

BIGINT

LONG

mediumtext

MEDIUMTEXT

LONG RAW

longblob

LONGBLOB

NCHAR

nchar

CHAR

NCHAR VARYING

nvarchar

VARCHAR

NVARCHAR2

nvarchar

VARCHAR

RAW

varbinary

VARBINARY

VARCHAR

varchar

VARCHAR

VARCHAR2

varchar

VARCHAR

BFILE

不支持

—

TIMESTAMP(n) WITH TIME ZONE

不支持

—

TIMESTAMP(n) WITH LOCAL TIME ZONE

不支持

—

INTERVAL YEAR(n) TO MONTH

不支持

—

INTERVAL DAY(p) TO SECOND(s)

不支持

—

ROWID

不支持

—

UROWID(n)

不支持

—

XMLTYPE

不支持

—

DATA_LENGTH列的「物理存储最大字节数」不一致，oracle中VARCHAR2(100) 的DATA_LENGTH为100（字节），goldendb-mysql中VARCHAR(100)的DATA_LENGTH为400（字节）utf8mb4
DATA_PRECISION列的「精度」，针对于oracle中NUMBER(s,p)定义了s精度则相等，没有定义精度直接是NUMBER的和其他类型则不相等。

user_tab_columns视图

目标库创建后的TABLE_NAME , COLUMN_NAME , DATA_TYPE, DATA_TYPE_MOD, DATA_TYPE_OWNER默认为小写，为了和oracle保持一致使用user_tab_columns视图时，都转成了大写
需要保证用户名和数据库名相同，会将当前的数据库名当作用户名；
只能查询到有权限的表