【写在疑问之前的描述】
做为一个优秀的工程师，我们孜孜不倦的追求着系统的处理效率和代码的完美……
本文主要是针对6000主机上与as400主机上做数据迁移的一些描述，其中有问题，也有一些可以吸取的经验和总结，同时，也汇总了一些网上找到的系统调优的资料，请各位看后，能够帮忙解决问题的给点指点，或者帮忙UP一下，让这里的高手都能够看到
前段时间，我初步接触400系统，有些问题版主以及各位也给了我不小的帮助，在此道声谢谢！希望能够看到有过类似经验的朋友给点指点，多谢！
【解决目的】
在不同的数据库之间进行数据迁移。
本次的数据迁移为：从RS 6000的DB2上的数据，产生AS400上对应的数据文件，导入到AS400的DB2数据表中
注：本次数据迁移的数据文件，在6000上主机上已经组织成了400上使用CPYTOIMPF命令产生的文件格式。
【解决方法】
在查阅了DB2 400的相关资料后，发现有几种方法可以做相关数据迁移，从6000的db2到400的db2：
（1）使用DB2自身的export和import，测试中发现，从6000远程import到400，效率太低（我的测试大概是400笔/s），若是需要转换将近500万的数据，所需要时间大概几个小时，无法承受该处理效率。在CU上查询到的关于import的优化处理，我已经尝试过了，好像效果并不明显，附网上的资料关于import的优化处理：
1、如果是在分区数据库的环境下，可以利用Buffered Insert来提高IMPORT的性能:
在执行IMPORT命令前，要先用INSERT BUF参数重新绑定IMPORT命令对应的绑定文件db2uimpm.bnd 。例如：
db2 connect to 数据库名
db2 bind db2uimpm.bnd blocking all insert buf
db2uimpm.bnd在..sqllib\bnd目录下。
2、执行IMPORT命令时使用COMPOUND参数:
例如：
db2 connect to 数据库名
db2 import from 数据文件名 of ixf modified by compound=100 insert into 表名
上面的命令中IMPORT会在每100条记录而不是每条记录插入后等待返回的SQL执行结果。
3、如果表中已有数据，将表的属性修改为APPEND MODE也可以加快IMPORT的性能。
（2）自己在6000上通过DB2 CLI编程自己写相关处理，导入的数据可以使用多进程并发处理，测试发现，大概最高可以到700笔/秒，该效率还是无法达到要求
（3）使用db2自带的load命令，结果，AS400的DB2版本不支持，以下为系统的报错显示：
EASYDB=>load from coremap.ffhz.ixf of ixf insert into easysjgd.ffhz
SQL1325N The remote database environment does not support the command or one
of the command options.
对于400版本而言，应该是没有支持load类似的命令了，这个也是我在网上查找了大量资料后得出的结论
（4）将数据文件传输到400的/目录下（IFS文件系统），自己写代码读取数据然后做insert，但是发现，对于"/fhdata"的文件，采用400上的ILE C编程，使用open(),read(...)读出来的都是写乱码
（此处感谢CU的轻舟，让偶知道原来400上还存在一个IFS文件系统，嘿嘿，偶是新人啊……）
（5）查找了DB2 UDB 400的相关资料，发现两个命令可以尝试使用：CPYTOIMPF和CPYFRMIMPF，于是进行测试，这里给大家一段相关介绍资料：
DB2 UDB for iSeries Database Programming V5R1
Loading and unloading data from non-iSeries systems
You can use the Copy From Import File (CPYFRMIMPF) and Copy To Import File (CPYTOIMPF) commands to import (load) or export (unload) data from and to the iSeries.
其中具体的详细描述我就不在此写了，只是希望又用过这两个命令的同道高手指点一二。
我的处理流程是这样的，我在6000主机上准备好了数据文本文件（按照CPYTOIMPF格式），用ftp命令传输到AS400的IFS文件系统上(放在/目录），使用CPYFRMIMPF进行导入处理，命令如下：
CPYFRMIMPF FROMSTMF('/affhz') TOFILE(EASYMAP/FFHZ) RCDDLM(*LF) FLDDLM('|')
在数据量较少的情况下，是很快可以处理的，但是我发现，当大数据量时，我测试的是100万数据，系统效率非常低，用了将近1个小时，还没有正式做import，查看日志情况如下：
Job . . : QPADEV000X User . . : EASYMAP Number . . . : 702486
5>> CPYFRMIMPF FROMSTMF('/affhz') TOFILE(EASYMAP/FFHZ) RCDDLM(*LF) FLDDLM('|')
File QACP702486 created in library QRECOVERY.
Member QACP702486 added to file QACP702486 in QRECOVERY.
File QACP702486 in library QRECOVERY was created.
Display Open Files
Job . . : QPADEV000X User . . : EASYMAP Number . . . : 702486
Number of open data paths . . . . . . . . . . : 2
Member/
File Library Device Scope Activation Group
QDUIGRAP QSYS QPADEV000X *ACTGRPDFN 0000000002 *DFTACTGRP
QACP702486 QRECOVERY QACP702486 *ACTGRPDFN 0000000002 *DFTACTGRP
查阅了相关资料后，发现，原来系统首先做了一步操作，就是在QRECOVERY的lib里面创建临时的PF，用于转换，而这个时间总计加起来远远超过了真正的导入时间，我用5万笔数据做了简单测试，系统在做临时PF的处理时间大概是118秒，而真正import到目的表的时间确只有53秒。
CPYFRMIMPF FROMSTMF('/aafh') TOFILE(EASYMAP/FFHZ) RCDDLM(*LF) FLDDLM('|')
File QACP702489 created in library QRECOVERY.
Member QACP702489 added to file QACP702489 in QRECOVERY.
File QACP702489 in library QRECOVERY was created.
Stream file copied to object.
50000 records copied from member QACP702489.
Object QACP702489 in QRECOVERY type *FILE deleted.
注意上面的log描述，其中File QACP702489 in library QRECOVERY was created.时间太久，导致对100万数据量的情况下，1个多小时的时间还没有执行20万记录导入到临时表中。
【问题待解】
（1）对于db2的import命令，是否可以采用不记日志的处理方法？若是可以，估计应该会提升很高的效率；
（2）若是在400主机上，使用ILE C需要读取IFS文件系统里面的文本文件的话，除了正常的open(),read()操作外，是否还需要其他处理？
注：我使用wrklnk命令进入目录后，使用5－Display文件内容是可以正常查看的
（3）查阅了大量的资料，看到有些对于CPYFRMIMPF命令的优化处理，以下列示给大家看看：
优化一说，原文如下：
Tips to improve the performance of the CPYFRMIMPF command
Follow these steps to inprove the performance of the CPYFRMIMPFcommand:
Delete any logical keyed files based on the TOFILE.
Remove all constraints and triggers of the TOFILE.
Ensure the FROMFILE records will be copied correctly by attempting to copy a few of the records. Copy a few of the records using the FROMRCD and number of records option.
Use the ERRLVL(*NOMAX) parameter after you know you can copy the data correctly.
When the ERRLVL(*NOMAX) parameter is used, record blocking increases performance. If an error in writing a record occurs during record blocking, the number of records listed as being copied in the completion message, CPC2955, may not be accurate.
根据以上指引，我做了相关尝试，结果似乎并没有任何的提升：
我尝试过在100万的那个文件里面，直接取前1万条记录数据往数据表PF中导入，结果发现，转入QRECOVERY库中临时文件的时间还是非常的长，按照我的分析好像系统还是将文件全部进行转换成临时的PF，然后才做的处理，所以，若是转换不解决，整个效率还是无法提升（自我分析）
优化二说，原文如下：
An important aspect of this command is its ability to copy the data in parallel. By using the Change Query Attributes (CHGQRYA) command, the number of tasks used to perform the copy is determined by the DEGREE parameter of the CHGQRYA command. The system feature DB2 Symmetric Multiprocessing for OS/400 must be installed for using multiple tasks. See the CHGQRYA command and the example section.
这个chgqrya的权限偶目前还没有，且对400的机制还不是非常深入的了解，但是就我自己上面的估计分析，效率会有所提升，但是好像若是临时转换不解决效率，估计很难提升
优化三说，原文如下：
FROMSTMF
Specifies the path name of the stream file from which data is copied. Either this parameter or the FROMFILE parameter is required. See path names for more information on specifying path names.
from-file-path-name: Specify the path name of the input stream file. Note: If the stream file is not in the QSYS.LIB file system, a temporary physical file will be created to contain the data of the stream file. This temporary file will be created in QRECOVERY and named QACPXXXXXX, where XXXXXX is a named generated by the system. The data will then be copied from the temporary file to the TOFILE. After the copy completes, the temporary file will be deleted.
按照上面的说法，我将文件放到了/qsys.lib/目录下，可是系统居然还是照样进行临时文件的转换，郁闷，日志如下：
CPYFRMIMPF FROMSTMF('/qsys.lib/scdzb.file') TOFILE(EASYSJGD/SCDZB) RCDDLM(
*LF) FLDDLM('|')
Open of member SCDZB was changed to SEQONLY(*NO).
File QACP590404 created in library QRECOVERY.
Member QACP590404 added to file QACP590404 in QRECOVERY.
File QACP590404 in library QRECOVERY was created.
Object not found. Object is /qsys.lib/scdzb.file.
Open of member SCDZB was changed to SEQONLY(*NO).
0 records copied from member QACP590404.
Object QACP590404 in QRECOVERY type *FILE deleted.
似乎不知是我操作问题还是怎么，居然都没有拷贝的，而且也没有报错？！
从上面的日志中，可以看出，系统仍旧是进行了临时PF的转换，而不是像其redbook中所言：
Note: If the stream file is not in the QSYS.LIB file system, a temporary physical file will be created to contain the data of the stream file.
不知是我理解有问题还是系统”欺骗“了我，呵呵，有过类似案例处理经验的朋友请指点一二，多谢！
摘自：chinaunix.net