1. 千万级数据导出的挑战与解决方案

做过Oracle数据导出的朋友都知道，小数据量（比如20万行以内）用PL/SQL Developer或者SQL*Plus的spool命令就能轻松搞定。但当你面对的是千万级甚至上亿条数据时，这些传统方法就会暴露出致命缺陷：导出速度慢如蜗牛，还经常半路崩溃，让你前功尽弃。

我去年就遇到过这样的坑。当时需要从一张700万行的交易表中导出CSV报表，用PL/SQL Developer跑了半小时才导出10%的数据，最后直接卡死。后来经过反复测试和对比，发现sqluldr2和存储过程方案才是处理海量数据导出的利器。前者700万数据只需12分钟，后者也只要23分钟，效率提升不是一点半点。

这两种方案各有优劣：

• sqluldr2适合有查询权限的普通用户，能在从库执行，但工具已停止维护
• 存储过程需要DBA权限且只能在主库运行，但作为原生方案不存在版本兼容问题

接下来，我会用实际案例带你深入这两种方案的配置细节和性能对比，帮你避开我踩过的那些坑。

2. sqluldr2实战指南

2.1 工具特点与安装

sqluldr2是Oracle数据导出的神器，虽然官方早已停止更新（最新版本基于Oracle 10.2），但在12c、19c等高版本中依然能稳定运行。它的核心优势有三点：

1. 并行导出：自动利用多线程加速
2. 内存优化：分批处理避免OOM
3. 灵活输出：支持CSV、TXT等多种格式

安装步骤很简单：

1. 下载压缩包（包含Windows和Linux版本）
2. Linux平台需要赋予执行权限：

chmod +x sqluldr2_linux64_10204.bin

3. 确保目标目录（如/data/bak）存在且Oracle用户有写入权限

注意：sqluldr2要求密码直接跟在用户名后（如user/pwd），这在生产环境存在安全风险，建议使用临时账号并立即修改密码。

2.2 关键参数与实战案例

最常用的导出命令格式如下：

./sqluldr2_linux64_10204.bin user/pwd@db \ query="select * from transactions" \ head=yes \ file=/data/bak/transactions.csv

针对千万级数据，这几个参数能大幅提升性能：

• batch=yes：每100万行生成一个文件
• rows=500000：明确指定每批处理50万行
• charset=UTF8：避免中文乱码
• safe=yes：自动处理特殊字符

比如处理分区表时，可以这样优化：

./sqluldr2_linux64_10204.bin user/pwd@db \ query="select * from orders partition(P_2023)" \ file=/data/orders_%B.csv \ batch=yes rows=1000000 \ charset=ZHS16GBK

这里的%B会自动生成序号（如orders_01.csv），避免单个文件过大。

2.3 性能优化技巧

通过多次实测，我总结了这些提速经验：

1. 视图转临时表：复杂视图先物化为临时表再导出，700万数据能从30分钟降到12分钟
2. 避开高峰期：在从库执行时选择业务低峰期
3. 网络隔离：如果导出到远程服务器，确保网络带宽≥1Gbps
4. SSD存储：将输出目录挂载到SSD磁盘，IO速度提升5倍

监控导出进度可以用tail -f查看日志：

tail -f /data/bak/export.log

3. 存储过程方案详解

3.1 存储过程工作原理

与sqluldr2不同，存储过程方案利用Oracle原生UTL_FILE包实现数据导出。其核心流程是：

1. 创建数据库目录对象指向物理路径
2. 通过游标逐行读取数据
3. 用UTL_FILE将数据写入CSV文件

这种方案的优点是无需第三方工具，所有操作都在数据库内部完成，特别适合严格管控的环境。但需要特别注意两点：

1. 必须由SYSDBA或拥有UTL_FILE权限的用户执行
2. 输出目录必须在数据库服务器本地

3.2 完整实施步骤

首先创建目录对象（需要DBA权限）：

CREATE OR REPLACE DIRECTORY EXPORT_DIR AS '/data/bak'; GRANT READ, WRITE ON DIRECTORY EXPORT_DIR TO export_user;

然后部署存储过程（完整代码见附录）。重点参数说明：

• P_QUERY：要执行的SQL语句
• P_DIR：之前创建的目录对象名
• P_FILENAME：输出文件名

执行示例：

BEGIN sql_to_csv('SELECT * FROM transactions', 'EXPORT_DIR', 'transactions.csv'); END; /

3.3 性能对比实测

在相同环境下测试700万数据导出：

• sqluldr2：12分钟（视图查询占80%时间）
• 存储过程：23分钟（UTL_FILE单线程写入是瓶颈）

但存储过程有个独特优势——可以实时转换数据格式。比如我在处理日期字段时，直接在存储过程中格式化：

EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_DATE_FORMAT=''YYYY-MM-DD''';

4. 方案选型建议

4.1 决策矩阵

4.2 场景化推荐

选择sqluldr2当：

• 你没有DBA权限但有查询权限
• 数据量超过500万行
• 需要在从库执行减轻主库压力
• 需要分批次导出（如按天分区）

选择存储过程当：

• 你有DBA权限或能获得支持
• 数据库版本较新（12c以上）
• 需要实时转换数据格式
• 环境限制无法安装第三方工具

4.3 混合方案

对于超大规模数据（如亿级以上），我推荐组合使用两种方案：

1. 用存储过程拆分数据范围（如按ID分段）
2. 对每个分段使用sqluldr2并行导出
3. 最后合并CSV文件

这既能避免单线程瓶颈，又不需要全量数据查询权限。具体实现可以用Shell脚本调度：

# 获取最小最大ID MIN_ID=$(sqlplus -s user/pwd <<EOF set heading off select min(id) from transactions; exit; EOF ) # 分段导出 for ((i=$MIN_ID; i<=$MAX_ID; i+=1000000)); do ./sqluldr2 user/pwd query="select * from transactions where id between $i and $((i+999999))" file=trans_$i.csv & done wait # 合并文件 cat trans_*.csv > full_export.csv

5. 常见问题排查

5.1 中文乱码问题

现象：导出的CSV用Excel打开中文显示为乱码解决方案：

• sqluldr2添加参数：charset=ZHS16GBK
• 存储过程在开头添加：

EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_LANG=''SIMPLIFIED CHINESE_CHINA.ZHS16GBK''';

5.2 大字段截断

现象：CLOB字段内容被截断处理方案：

• 对于sqluldr2，添加loblen=999999参数
• 对于存储过程，修改L_COLUMNVALUE VARCHAR2(4000)为更大的值

5.3 空间不足

预防措施：

• 提前估算数据量（每百万行约50-100MB）
• 使用df -h监控磁盘空间
• 考虑压缩导出：

./sqluldr2 ... file=/data/bak/data.csv.gz gzip=yes

附录：完整存储过程代码

CREATE OR REPLACE PROCEDURE export_to_csv( p_query IN VARCHAR2, p_dir IN VARCHAR2, p_filename IN VARCHAR2 ) IS l_file UTL_FILE.FILE_TYPE; l_cursor INTEGER DEFAULT DBMS_SQL.OPEN_CURSOR; l_column_value VARCHAR2(32767); l_status INTEGER; l_colcnt NUMBER := 0; l_separator VARCHAR2(1) := ''; l_desc_tbl DBMS_SQL.DESC_TAB; BEGIN -- 打开文件 l_file := UTL_FILE.FOPEN(p_dir, p_filename, 'w', 32767); -- 设置日期格式 EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_DATE_FORMAT=''YYYY-MM-DD HH24:MI:SS'''; -- 解析SQL DBMS_SQL.PARSE(l_cursor, p_query, DBMS_SQL.NATIVE); DBMS_SQL.DESCRIBE_COLUMNS(l_cursor, l_colcnt, l_desc_tbl); -- 写入列头 FOR i IN 1..l_colcnt LOOP UTL_FILE.PUT(l_file, l_separator || '"' || l_desc_tbl(i).col_name || '"'); DBMS_SQL.DEFINE_COLUMN(l_cursor, i, l_column_value, 32767); l_separator := ','; END LOOP; UTL_FILE.NEW_LINE(l_file); -- 执行查询 l_status := DBMS_SQL.EXECUTE(l_cursor); -- 写入数据 WHILE (DBMS_SQL.FETCH_ROWS(l_cursor) > 0) LOOP l_separator := ''; FOR i IN 1..l_colcnt LOOP DBMS_SQL.COLUMN_VALUE(l_cursor, i, l_column_value); UTL_FILE.PUT(l_file, l_separator || '"' || REPLACE(TRIM(l_column_value), '"', '""') || '"'); l_separator := ','; END LOOP; UTL_FILE.NEW_LINE(l_file); END LOOP; -- 清理资源 DBMS_SQL.CLOSE_CURSOR(l_cursor); UTL_FILE.FCLOSE(l_file); EXCEPTION WHEN OTHERS THEN IF DBMS_SQL.IS_OPEN(l_cursor) THEN DBMS_SQL.CLOSE_CURSOR(l_cursor); END IF; IF UTL_FILE.IS_OPEN(l_file) THEN UTL_FILE.FCLOSE(l_file); END IF; RAISE; END; /