一次SQL1036C错误的处理！

核心提示：因工作需要，需导入历史库以查询历史数据，一次SQL1036C错误的处理！，因几次数据库清理所以导出的历史库文件分了好几部分，费千辛万苦找全了文件后，报SQL1137W就更应该知道去清理！而且以上错误在db2diag.log里均有提示，如果早注意就不会费那么多事儿了，开始导数：1、load第一个文件（50多万行）用：lo

因工作需要，需导入历史库以查询历史数据，因几次数据库清理所以导出的历史库文件分了好几部分，费千辛万苦找全了文件后，开始导数：

1、load第一个文件（50多万行）用：load from ... of ixf replace into .. nonrecoverable (测试环境空间较小，不要日志了！)
很久后，报：

SQL0289N　Unable to allocate new pages in table space "USERSPACE1".　
SQLSTATE=57011

查db2diag.log，报：

Tablespace 2(USERSPACE1) is full
..
DIA9999E An internal error occurred. Report the following error code :
"0xFFFFD121".

表空间满了，一开始没想到，删掉几个没用的大表后，先load....terminate....，消除load pending状态，重新导入，成功。

2、load第二个文件，报：

SQL3125W　The character data in row "F0-1" and column "3" was truncated 
because the data is longer than the target database column.

＾C 强行中断！
select 查询表内容，报：

SQL0290N　Table space access is not allowed.　SQLSTATE=55039

查表空间状态，为load pending，执行load...terminate....却失败，报：

SQL3508N　Error in accessing a file or path of type "RESTART/TERMINATE INFO" 
during load or load query.　Reason code: "1".　Path: "".

再查表空间状态，为0x000c　Quiesced: EXCLUSIVE load pending，
再次执行load...terminate....，很长时间没动静，按捺不住，又＾C强行中断！报：

SQL3501W　The table space(s) in which the table resides will not be placed in 
backup pending state since forward recovery is disabled for the database.

SQL3110N　The utility has completed processing.　"0" rows were read from the 
input file.

^C
DB21017E　The Command Line Processor encountered a system error with the 
frontend process output queue. Reason code = -2498.


一不做二不休，做一个force application all ,再list applications还有？！
看一下表空间状态，0x0004　Quiesced: EXCLUSIVE
再load...terminate....，报：

SQL3508N　Error in accessing a file or path of type "TEMP_FILE" during load or 
load query.　Reason code: "1".　Path: 
"/db2catalog/db2inst/NODE0000/SQL00001/lo".

这几个提示连看都没仔细看，就db2stop，不成功！
开始着急，干脆把库drop掉重建，于是drop db ，不成功,报：

SQL1137W　The database manager was unable to remove the database path or some 
of the containers when dropping database "TEST".　Cleanup is required.

看都没看，做uncatalog
做redirect恢复时，报：

SQL1036C　An I/O error occurred while accessing the database.　SQLSTATE=58030

查几个container所在的lv的属组属主均正确，查编目表空间（SMS）、临时表空间（SMS）的目录属组属主权限均正常！
试做db2untag，成功！但再redirect恢复，仍报SQL1036C！
不解！
回过头再看前面SQL3508N错时，看到Path: "/db2catalog/db2inst/NODE0000/SQL00001/lo"
进入编目目录，看到db2catalog/db2inst/NODE0000/SQL00001/load/DB200002.PID/DB200916.OID/load.msg文件，应该是在做LOAD时留下的MSG，db2inst目录属组属主均同实例用户，将db2catalog下的所有文件目录清空，再redirect恢复，成功！


3、恢复完库再LOAD完第一个文件后，查看LOAD第二个文件报的错，查db2diag.log，发现报"0xFFFF8138".即“Invalid state transition”，查表结构，才发现表结构比导入文件多一个字段，重建表结构，导入，成功！

教训：1、一定要仔细查看理解语句所报的错误，如果仔细点，报SQL3125时，就应该知道是表结构不对，报SQL3508N时就应该去清理catalog目录，报SQL1137W就更应该知道去清理！而且以上错误在db2diag.log里均有提示，如果早注意就不会费那么多事儿了，浪费了mymm一天的时间！
2、在建库以前一定要将各SMS管理的目录清理干净！SQL1036C错误无非都是些权限错误！

一点教训，拿出共勉！
忘记说环境了：AIX 4.3.3
　　　　　　　DB2 7.2、实例db2inst、数据库test
　　　　　　　SYSCATSPACE－SMS
　　　　　　　TEMPSPACE1－SMS
　　　　　　　USERSPACE1－DMS