Oracle 到 GaussDB 迁移实战：PL/SQL 转 PL/pgSQL 关键技巧

1. 从Oracle到GaussDB：为什么PL/SQL迁移这么重要

最近几年，越来越多的企业开始从Oracle转向GaussDB。作为华为自主研发的分布式数据库，GaussDB不仅成本更低，在扩展性和性能方面也有独特优势。但很多DBA在实际迁移过程中，最头疼的就是PL/SQL代码的转换问题。

我参与过十几个大型Oracle系统的迁移项目，发现存储过程和触发器的迁移往往占整个迁移工作量的60%以上。这是因为PL/SQL和PL/pgSQL虽然看起来很相似，但在语法细节、异常处理、动态SQL等方面存在不少差异。如果不注意这些细节，轻则导致功能异常，重则可能引发数据一致性问题。

举个例子，某金融机构在迁移对账系统时，就因为没处理好异常处理的差异，导致夜间批处理任务静默失败，第二天才发现对账不平。后来花了整整一周时间才排查出问题所在。所以今天，我想分享一些PL/SQL转PL/pgSQL的实战经验，帮你避开这些"坑"。

2. PL/SQL与PL/pgSQL的核心语法差异

2.1 变量声明和作用域

Oracle的PL/SQL中，变量声明通常放在BEGIN之前：

-- Oracle PL/SQL DECLARE v_count NUMBER; v_name VARCHAR2(100); BEGIN -- 业务逻辑 END;

而在GaussDB的PL/pgSQL中，变量声明要放在特定的块里：

-- GaussDB PL/pgSQL DO $$ DECLARE v_count INTEGER; v_name VARCHAR; BEGIN -- 业务逻辑 END $$;

这里有几个关键区别：

1. GaussDB使用INTEGER而不是NUMBER
2. 字符串类型是VARCHAR而非VARCHAR2
3. 整个代码块需要用DO $$...$$包裹

2.2 循环结构的转换

循环是最常用的控制结构之一，但两种语言的写法差异很大。比如Oracle的FOR循环：

-- Oracle FOR i IN 1..10 LOOP DBMS_OUTPUT.PUT_LINE('Index: ' || i); END LOOP;

在GaussDB中要改成：

-- GaussDB FOR i IN 1..10 LOOP RAISE NOTICE 'Index: %', i; END LOOP;

注意两点变化：

1. 输出语句从DBMS_OUTPUT.PUT_LINE变为RAISE NOTICE
2. 字符串拼接使用%占位符而不是||

3. 动态SQL的处理技巧

3.1 EXECUTE IMMEDIATE的转换

Oracle中常用的动态SQL执行方式：

-- Oracle DECLARE v_sql VARCHAR2(200); v_result NUMBER; BEGIN v_sql := 'SELECT COUNT(*) FROM users WHERE status = ''active'''; EXECUTE IMMEDIATE v_sql INTO v_result; END;

在GaussDB中等效的写法：

-- GaussDB DO $$ DECLARE v_sql TEXT; v_result INTEGER; BEGIN v_sql := 'SELECT COUNT(*) FROM users WHERE status = ''active'''; EXECUTE v_sql INTO v_result; END $$;

主要变化：

1. 去掉IMMEDIATE关键字
2. 字符串类型用TEXT而不是VARCHAR2

3.2 带参数的动态SQL

更复杂的情况是带参数的动态SQL。Oracle中的写法：

-- Oracle DECLARE v_sql VARCHAR2(200); v_dept_id NUMBER := 10; v_count NUMBER; BEGIN v_sql := 'SELECT COUNT(*) FROM employees WHERE department_id = :dept_id'; EXECUTE IMMEDIATE v_sql INTO v_count USING v_dept_id; END;

GaussDB的等效实现：

-- GaussDB DO $$ DECLARE v_sql TEXT; v_dept_id INTEGER := 10; v_count INTEGER; BEGIN v_sql := 'SELECT COUNT(*) FROM employees WHERE department_id = $1'; EXECUTE v_sql INTO v_count USING v_dept_id; END $$;

关键区别：

1. 参数占位符从:dept_id变为$1
2. USING子句的用法类似，但位置参数从1开始编号

4. 异常处理的实战转换

4.1 基本异常处理结构

Oracle的异常处理：

-- Oracle BEGIN -- 业务代码 EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUT.PUT_LINE('No data found'); WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM); END;

GaussDB中的对应写法：

-- GaussDB DO $$ BEGIN -- 业务代码 EXCEPTION WHEN NO_DATA_FOUND THEN RAISE NOTICE 'No data found'; WHEN OTHERS THEN RAISE NOTICE 'Error: %', SQLERRM; END $$;

注意事项：

1. 异常类型名称可能不同（GaussDB使用PostgreSQL的异常类型）
2. 错误输出使用RAISE NOTICE而非DBMS_OUTPUT

4.2 自定义异常的处理

Oracle中定义和使用自定义异常：

-- Oracle DECLARE e_custom EXCEPTION; PRAGMA EXCEPTION_INIT(e_custom, -20001); BEGIN IF some_condition THEN RAISE e_custom; END IF; EXCEPTION WHEN e_custom THEN DBMS_OUTPUT.PUT_LINE('Custom error occurred'); END;

GaussDB的实现方式：

-- GaussDB DO $$ DECLARE e_custom TEXT := 'custom_error'; BEGIN IF some_condition THEN RAISE EXCEPTION '%', e_custom; END IF; EXCEPTION WHEN OTHERS THEN IF SQLSTATE = 'P0001' AND SQLERRM LIKE '%custom_error%' THEN RAISE NOTICE 'Custom error occurred'; END IF; END $$;

这里有几个重要差异：

1. GaussDB没有直接的EXCEPTION类型定义
2. 需要通过错误代码和消息内容来判断自定义异常
3. 使用RAISE EXCEPTION而不是RAISE

5. 性能优化建议

5.1 避免分布式事务陷阱

GaussDB是分布式数据库，跨节点的分布式事务性能开销很大。在转换存储过程时，要特别注意：

-- 不推荐的写法（可能导致分布式事务） UPDATE node1.table1 SET ...; UPDATE node2.table2 SET ...;

应该尽量改为单节点操作，或者使用本地临时表：

-- 更好的写法 CREATE TEMP TABLE temp_data AS SELECT ... FROM node1.table1; UPDATE temp_data SET ...; INSERT INTO node2.table2 SELECT * FROM temp_data;

5.2 合理使用分片键

在GaussDB中，如果查询条件不包含分片键，会导致全分片扫描：

-- 低效查询（缺少分片键） SELECT * FROM large_table WHERE create_date > '2023-01-01';

应该在存储过程中确保关键查询都带上分片键：

-- 高效查询（使用分片键user_id） SELECT * FROM large_table WHERE user_id = in_user_id AND create_date > '2023-01-01';

6. 实用迁移工具和技巧

6.1 使用华为UGO工具

华为的UGO（数据库对象迁移工具）可以自动转换70%左右的PL/SQL代码。基本使用步骤：

1. 安装配置UGO服务
2. 创建Oracle到GaussDB的迁移项目
3. 执行语法转换
4. 人工复核转换结果

虽然不能100%自动转换，但能大幅减少手工工作量。我在最近一个项目中，UGO处理了约300个存储过程，其中65%可以直接使用，剩下的需要少量调整。

6.2 代码对比和测试策略

建议采用以下测试流程确保迁移质量：

1. 单元测试：对每个存储过程/触发器进行独立测试
2. 集成测试：验证多个存储过程的交互逻辑
3. 性能测试：对比Oracle和GaussDB的执行效率
4. 回归测试：确保不影响现有功能

可以使用开源工具如pgTAP进行自动化测试：

-- 示例测试用例 BEGIN; SELECT plan(1); SELECT ok(1 = 1, 'basic test'); SELECT * FROM finish(); ROLLBACK;

7. 常见问题解决方案

在实际迁移过程中，我遇到过几个典型问题：

1. 日期处理差异：Oracle的SYSDATE在GaussDB中要用CURRENT_TIMESTAMP替代，但注意时区设置可能不同。

2. 分页查询转换：Oracle的ROWNUM要改为GaussDB的LIMIT/OFFSET：

-- Oracle SELECT * FROM ( SELECT a.*, ROWNUM rn FROM ( SELECT * FROM large_table ORDER BY create_date ) a WHERE ROWNUM <= 100 ) WHERE rn > 50; -- GaussDB SELECT * FROM large_table ORDER BY create_date LIMIT 50 OFFSET 50;

3. 空值处理：NVL()函数要改为COALESCE()，但要注意两者的细微差异。

4. 序列使用：Oracle的sequence.nextval在GaussDB中要用nextval('sequence_name')。

8. 迁移后的调优经验

完成代码转换只是第一步，要让存储过程在GaussDB上高效运行，还需要：

1. 分析执行计划：使用EXPLAIN ANALYZE查看查询性能
2. 优化分布式查询：避免跨节点的大数据量传输
3. 调整内存参数：适当增加work_mem等参数
4. 监控慢查询：利用GaussDB的监控视图定位性能瓶颈

一个实际案例：某电商平台的订单统计存储过程，在Oracle上运行需要2秒，迁移到GaussDB后变成了8秒。通过分析发现是因为缺少分片键导致全分片扫描。加上user_id分片条件后，性能提升到1.5秒，比原来Oracle还快。