【寫在疑問之前的描述】
做為一個優秀的工程師，我們孜孜不倦的追求著系統的處理效率和代碼的完美……
本文主要是針對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
