编目节点：

catalog tcpip node nodename remote ip server 50000

编目数据库： catalog db dbname at node nodename

显示节点： list node directory

显示数据库： list db directory

连接数据库 connect to dbname user username using password

db2归档

db2 update db cfg using LOGARCHMETH1 DISK:d:archlog

DISK:后面不要空格

如果db2处在backup pending状态，如果不备份整个库，

解决方法 db2dart /chst /WHAT DBBP off

数据库导出

db2move dbname export -u username -p password

出现警告错误如sql3107,怎么解决

一般是字符集问题，

可以首先查看数据库服务器参数codepage

db2 connect to dbname user username using password

db2 get db cfg

在windows下的大多设置为1386

那么在linux下很可能出现问题

db2 connect to dbname user username using password

db2set db2codepage=1386

db2 terminate

之后，再

db2move dbname export -u username -p password

[@more@]以下节选自http://myfriend2010.itpub.net/post/29012/404769 myfriend2010的博客 DB2归档模式及与DB2复制相关问题 该文简单介绍了DB2归档模式，并说明了如何设置归档模式及其与DB2复制相关的问题。 1. DB2日志简介 1.1. 日志类型 1.1.1. 活动日志（ACTIVE LOG）功能类似于ORACLE的online redo log, 该日志包含尚未提交或回滚的事务单元的相关信息，以及已提交但尚未写入数据库文件的事务的信息。 具体又分两种 l 主日志 数量由参数LOGPRIMARY决定，预先分配 l 从日志 当主日志不够时，临时分配最多LOGSECOND数目个从日志 1.1.2. 存档日志(ARCHIVED LOG) 存在于归档模式。 1.1.2.1. 联机存档日志(ONLINE ARCHIVED LOG) 它们是驻留在数据库活动日志目录（“online”）中、普通数据库活动不再需要的日志文件。 1.1.2.2. 脱机存档日志(OFFLINE ARCHIVED LOG) 它们是已经从数据库日志目录移到脱机存储位置（如备份服务器）、普通数据库活动不需要的日志文件 这两者的不同仅在于联机归档日志存在于活动日志目录下，而脱机的不是 1.2. 日志模式 1.2.1. 循环日志模式 如图所示，预先分配好的若干个主日志循环利用，当不够的时候，临时申请若干个从日志 1.2.2. 归档日志模式当开启归档模式后，日志将不会被覆盖，而是不停新产生。如果不设LOGARCHMETH1参数的话，归档日志将仍然待原目录，就成为联机归档日志。如下图： 而如果，设置LOGARCHMETH1参数到另外一个目录的话，归档后的日志将被自动移动到新目录下，即被称为脱机归档日志，如下图： 2. DB2归档模式设定 1． 修改参数LOGRETAIN为recovery (缺省为N) Db2 update db cfg for TEST using logretain recovery 2． 将数据库做一次全备 Db2 BACKUP DATABASE TEST TO "C:test" 3． 修改USER_EXIT参数 a) 可以通过图形界面；控制中心－》数据库》DBNAME》右键》配置数据库记录向导 b) 通过命令行 Db2 UPDATE DB CFG FOR TEST USING logarchmeth1 "DISK:C:testMYLOG" 这样日志就被自动归档到C:testMYLOG目录下了。 3. DB2日志跟ORACLE日志的比较有两个比较大的不同点： 1． DB2要求活动日志被覆盖或者归档之前必须保证里面的事务已经commit或者rollback了，也就是说，如果一个事务太大，超过了主日志加从日志的和的话，将会报日志满错误。而ORACLE没这个要求，只可能在归档模式时，空间满了才会报日志满错误。 2． 对于归档模式而言，DB2的活动日志总是新分配的，不象oracle，在线日志总是重用的 4. 与复制相关的问题 1． 如果DB2启用复制并且作为数据源后，必须使用归档日志模式，DB2复制是从日志或者归档日志里捕获需要的表的修改信息的。 2． 如果复制进程中途断掉，经过一段时间再启用时，这时可能相应的表修改信息已经被归档了，这时db2将从归档日志（可能联机归档日志，也可能是脱机归档日志）里面将信息去找。 3． 这就涉及到一个问题，归档日志不会无限期的放到归档目录下，如何设定归档日志存放时间呢？如果时间过短，复制的capture进程可能会发生找不到相应日志，从而失败的问题。存放时间太长的话，需要的归档空间又太多。这就需要根据实际情况，两方面均衡的考虑了。 4． 如果真的发生了找不到日志的情况，可以有两种方法 a) 将日志从别处拷回 b) 将复制完全刷新 对单向复制而言，复制完全刷新这个选项就已经够了。但对双向复制而言，完全刷新的话，意味着从节点自上次刷新之后的修改就完全丢失了，所以最好将日志拷回来。