db迁移的相关记录

生产上面离线备份数据库，并压缩后，传到UAT环境
db2 backup db dbname to /fs

使用db2 instance用户登录UAT环境后直接开始数据库的恢复
db2 restore db dbname from /fs taken at TIMESTAMP to /somefs redirect without rolling forward

db2 "set tablespace containers for 0 using (path '/easydata/catalog_wbhis')"
db2 "set tablespace containers for 1 using (file '/easydata/catalog_wbhis.dat' 20000)"
...
 
// file对应tablespace原来的DMS类型, path对应原来tablespace的SMS类型
// 可以使用 LIST TABLESPACES SHOW DETAIL 命令来获取关于源数据库中所有表空间的信息；这将帮助您确保已经为目标数据库中的所有表空间设置了容器。

db2 restore db orsdb continue
PS: 所有上述的命令必须在同一个session内完成，否则就得重新来过

这里如果更改完所有的tablespace containers后仍然无法继续恢复数据库的话，则需要看看db2diag.log日志，有可能
是给出的file类型的tablespace的size不够大，可以继续用同样的命令更改完所有设置。

恢复完db后，在做
db2 activate db dbname

之前，设置下面的参数
db2set DB2_OVERRIDE_BPF=1000

然后再去连数据库，并alter bufferpool将所有bufferpool改到合理的范围

这样库就完全恢复出来了，然后
db2look -d dbname -a -e -m -x -o dbname.ddl
db2move dbname export -sn SCHEMA_NAME

再连接新的数据库
首先删除掉现在用户的所有对象，然后拿生产环境的DDL重建整个库，这里涉及到更改tablespace名字，和schema等
db2 -tvf dbname.ddl
这里会有很多错，基本上是function和procedure的错误，这里
直接打开两个数据库然后，手动的编译这些function和procedure

nohup db2move dbname load &

对于部分报错没有load进去的表，可以再通过
db2 export to filename.ixf of ixf select * from tablename
然后再
db2 load from filename.ixf of ixf replace into tablename nonrecoverable

等所有数据都导入成功后
需要做一致性检查因为这里有很多外键关联，
db2 set integrity for DIM_CONTROL_COMPLEXITY immediate checked

到这里后，数据库基本完成迁移，但是还需要对数据库的某些表进行update操作，对于涉及到schema的地方，做相应的update
对于config schema下面的表，则是选择需要迁移的表进行迁移，都是通过db2 export和db2 load来完成，同样做相应的替换schema的动作


至此，完成数据库方面的迁移工作！

可以参考下面文章:
http://www.ibm.com/developerworks/cn/data/library/techarticles/0211melnyk/0211melnyk.html