接到一个任务，要把160G的数据导入到oracle服务器上。最开始以为就是导数据这么简单的任务，虽然没以前没用过oracle没导过数据，但是在网上搜一下方法不久行了？我信心满满地接了下来，没想到这么简单的任务也有如此多的坑，下面把导数据过程中的踩坑和弯路记录下来，共勉。

首先当然是选择用啥工具导入数据库，常用的navicat或pl/sql感觉速度上都不太行，在网上看到导入大量数据一般用sqlloader这个oracle自带的工具。sqlloader就是sqlldr，在oracle官网上可以下载客户端。下载地址：https://www.oracle.com/cn/database/technologies/instant-client/winx64-64-downloads.html。

踩坑1：找不到对应版本的sqlloader。公司服务器的oracle版本是11g，然而11g的版本在官网上并没有sqlloader。网上好多博客说精简版客户端没有sqlloader，但是在哪找非精简版的客户端呢？还好在参考了这篇博客的内容，高版本的sqlloader同样支持11g的oracle服务器版。于是下载了12.2.0.1.0版本的sqlloader，下载地址：https://www.oracle.com/cn/database/technologies/instant-client/winx64-64-downloads.html#license-lightbox。

踩坑2：下载后解压，把解压后的路径加到环境变量中，即可在cmd命令行中测试sqlldr是否正常工作。但是我在cmd命令行中测试sqlldr总是报这样的错误：无法定位程序输入点域动态连接库上。这个错误是sqlldr和原有的oracle client版本不一致造成的。我电脑之前安装的是instantclient-basic-windows.x64-11.2.0.4.0。于是卸载之前版本的basic客户端，安装instantclient-basic-windows.x64-12.2.0.1.0。终于，sqlldr的环境搞定了！测试页面如下：

踩坑3：sqlldr的环境搞定后，下一步就是连接数据库了。由于oracle数据库安装在服务器上，所以连接的语法是，在命令行输入：

sqlldr username/password@host:port/service_name

注意sqlldr后面跟的是主机字符串，而主机字符串最后一项得是service_name而不是SID。我总觉得用SID也是可以连接的，但是没找到相应的连接语句。

踩坑4：如果能正常连接，下一步需要指定控制文件，也就是control文件。当然也可以和上一步命令一起输入。control文件是sqlldr最为重要的一个文件，它指定了加载选项，加载数据的内容，加载方式等。control文件写的好，后面就一点坑都不用踩！！新建一个后缀为.ctl的文件作为控制文件，例：data.ctl，内容如下

弯路1: 如果一开始就按照上述的格式编写控制文件，就不会有任何问题。但是我自作聪明把Optionally enclosed by '"'这句话删掉了。原始数据是csv格式的，其中每个文件的大小在15G左右，因此我先用pandas导出了前1000行保存到了data1000.csv中，看看数据长啥样。每一行的格式都是和数据库中的一样，看样子没啥问题。于是在命令行中输入

sqlldr username/password@host:port/service_name control=data.ctl

其中控制文件中指定了从data1000.csv文件加载数据。不出意外的报错了，原因是pandas导出数据时，自动加上了一列行索引，于是sqlldr加载数据时字段没对应上。这种情况对应着csv文件中的列数多余数据库表中的列数，需要在多余的列对应位置加上 FILLER关键字进行跳过，如下：

跳过索引列之后，从pandas导出的这1000行数据就能正常上传了！！

于是在控制文件中指定加载源文件，在命令行执行后又又又报错了！查看日志，报如下错误：

记录 1: 被拒绝 - 表 DATA 的列 ID 出现错误。

ORA-01722: 无效数字

这个报错的原因是从csv文件中读出来的字段都是字符串，而ID这个字段的类型是Number，所以类型不匹配造成的。那为啥用pandas导出的前1000行数据就可以正常加载呢？原因是pandas在导出数据是自动做了转换，把数字构成的字符串保存成了字符串格式。那我在控制文件中指定一下字段类型是不是也一样的效果哈哈哈，我试了以下格式的控制文件：

然后还是报错，结果如下：

SQL*Loader-350: Syntax error at line 9. Expecting “,” or “)”, found “NUMBER”. ID NUMBER(16),

为什么字段后面能写DATE类型的格式，不能写Number呢，这是因为DATE是sqlldr中的一个转换函数，而Number不是。有许多博客建议在该字段后面加上整数的关键字：

我试了上面的两种写法，还是报ORA-01722的错。在百思不得其解的情况下我突然萌生了一个笨办法，既然用pandas导出的前1000行记录能插入，索性我就把所有的源数据都用pandas转换一下，不就可以导入了吗？说干就干，立马写了一个python脚本，丢在电脑上执行了一晚上。

弯路2: 好不容易用pandas把所有数据都转换完成了，这个时候又出现了新的问题！某些源数据中字段是中文，编码格式得用GB2312；有些字段中还有换行符，pandas导出时会出现把一行数据导出为2行的情况。我这个弯路越走越弯了啊。于是我又写了一个转换判断字段中是否存在换行符的脚本，把含有换行符的几个源文件再转换一遍。

踩坑5: 对于不含中文且字段中没有换行符的文件，经过pandas转换后已经可以上传到服务器了！赶紧执行上传命令

sqlldr username/password@host:port/service_name control=data.ctl

这个转换后的数据文件有32G，我就眼睁睁看着它以大概250万条/小时的速度导入，这导到猴年马月。

最终解决办法: 在踩过了前面的坑和弯路后，我忽然发现控制文件中Optionally enclosed by '"'似乎有奇妙的作用，加上这句话之后，那些被双引号括起来的数字就可以被当作数字接收而不是被当作字符串拒绝了！这么说我用pandas转换文件完全是多次一举？？并且以打开直接路径加载的方式要上面的加载方式快的多！所以最终控制文件的内容如下：

这种直接路径加载的方式也可选择并行，需要把TRUNCATE改为APPEND。不过我没有用并行的方式，一个多小时就插入完了所有数据。一张表有1.78亿条记录，这个速度已经很可以了。