大数据量数据导入总结（Informix）

大数据量环境，是性能测试的基础，但是我们构造大数据的时候，总是被一些“犄角旮旯”的事情给搞的焦头烂额。这里通过一次大数据量导入的经历，把所有的问题都体会了一把，不敢说有什么心得，就把一些问题罗列一下，希望对大家有所启发。

一、    脚本的选择
以前做过大数据量导入，有一些自己的脚本。但是看到别人写的脚本比较新颖，就想拿过来试试。结果因为不是自己写的脚本读起来比较费力，用不好，出现问题也不好定位，费时又费力，最后还是放弃了。回头想想，大数据量生成脚本，无非就是生成.unl文件（该文件一行对应一条数据库记录，以'|'分隔不同列），不管方法是简单还是笨拙，最终的unl变不了的。所以这里建议，大数据量unl文件生成脚本，不用玩出什么花来，简单易懂最好。

二、    数据空间分配
性能测试会根据要求，规划好数据量，我们可以根据数据量，估算磁盘空间需求。一般情况，例如一条t_corpdetail（接近100个字段，且部分字段比较大）数据占1K空间，一条t_userdetail表（100多个字段，且部分字段能达到char(64)的规模）数据占2K，其它表比较小，数据量不大的话，可以忽略不计。在估算完数据要占用的磁盘空间后，就要分配数据空间了（如果数据空间不够，会导致脚本数据导入失败，这也是常见问题之一）。这里又有另外一个问题了，就是如果数据库所在盘下，空间不足，我们要在其它盘符下分配数据空间。方法：创建好workdbs文件后，要将其属主修改为Informix:informix，权限660，然后将该文件分配成workdbs，格式：onspaces -a workdbs -p <workdbs的绝对路径> -o 40 -s 6000000（6G=6000M=6000000K，不需要用1024去换算）。

三、    磁盘空间的考虑
因为大数据量导入的本质，就是先生成unl文件，再load进数据库。大数据量情况下，生成的unl文件是很大的。对此，我们有两种解决方案：第一种，就是分多次导入。每次生成少量unl的数据（这里的少量是针对总量的，其实还是蛮多的），执行导入脚本，然后删除该unl文件，再执行下一批数据。我们可以将这些批次写入到一个shell文件中。第二种，就是将脚本文件放到其它比较空的盘下执行。

四、    数据库物理日志空间的分配
这次导入phone表数据，总是导到50万左右，就出现疑似内存泄漏的问题，然后就停止导入了。后来经分析，是因为数据库的物理日志空间不够导致的。追加物理日志空间后，该问题就不存在了：onspaces -a phylogdbs -p /home/opt/dbs/informix/dbs/phylogdbs1 -o 40 -s 1000000 （此处类似数据空间分配）。这个问题的定位最费时间，它总是在执行了半个小时或者更长的时间后，才体现出来。因此，大家一定要注意前期预防。另一方面，当导入失败，在脚本目录下生成core文件时，就要考虑是否需要多分配点物理日志空间了。

五、    表页大小的重新设定
使用dbschema –d 数据库名 –t 表名 –ss ，会显示目标表的详细表设计，其中会显示extent size 16 next size 16 lock mode row; 两个16，前者表示分页大小，后者表示追加大小。如果数据量很大，需要进行调整，否则数据无法导入。t_corpdetail一般改为extent size 128000 next size 32000 lock mode row; 即可，而t_userdetail表要改为extent size 512000 next size 128000 lock mode row; 该数据量，大概能保证1600W的phone表数据量。如果需要更多，则需要将数据可以按数据段分批放置到不同的数据库trunk下（分片方法(userid >=10000000000 and userid <= 10009999999 ) in datadbs1）。修改该数据的方法，是导出表结构，手动修改后，将原表结构drop掉，再创建。因此，必须在数据导入前，规划好该数值，否则后果很严重。

另外提一下：当大家使用以前的脚本，却发现总是提示找不到命令时，可以先在环境下手动创建一个脚本，将原脚本内容拷进去试试。因为在windows环境下保存的sh文件，再传到Linux环境下，可能已经损坏了，就算传输类型为ASCII，也不能还原的（这个问题的定位，也很费时间，不如直接在Linux下再创建一次文件方便）。

六、    如何提高数据导入效率
在性能测试前期准备过程中，大数据量导入占用了80%以上的时间。如何提高数据导入效率，成员提高性能测试效率的一个重要关注点。下面为大家介绍删除索引导入数据，缩短导入时间的方法。
导入大表千万级数据量时（如t_userdetail表），会消耗很长的时间，严重影响性能测试进度。
提高导入速率的方法，就是先将索引删除，导入数据后，再创建索引。

首先通过指令，dbschema –d DBname –t tablename –ss XX.sql ，将即将操作的表的表结构导出，打开XX.sql文件，将其中的创建索引的语句删除（create index 等语句），然后通过drop table 表名，将该表删除，再通过dbaccess DBname XX.sql将不含索引的表结构重新导入。（当然，也可以通过drop index命令实现索引删除操作，但是考虑到大数据量导入，还需要修改表的extent size值，所以还是采用了上边删表的方法）

这样，我们再导入数据，就会快很多。数据导入完成后，通过create index的命令（我们导出的XX.sql所删除的那几个创建索引的sql），创建索引，这样大数据量的准备工作就完成了。

也许这样说起来感觉不到速度能提高多少，下面以导入t_userdetail表4000W数据为例，给大家比较一下（真实场景数据）。
如果表的索引都在，这些数据的导入，耗时111个小时，高优耗时24小时，共计135小时。而将索引删除，导入数据用时33小时，创建索引用时大约24小时，共计57小时（新建索引，无需高优），节省了一大半的时间！

当然，删除索引导入数据也有一些需要小心的地方。

如果某字段需要创建唯一索引，如t_userdetail.userid，则一定要保证脚本导入的数据，一定要保证唯一索引字段导入的值唯一，否则数据导入后发现创建不了唯一索引，就得不偿失，又要浪费时间了。

后续为大家介绍数据库大数据量的shell脚本编写。