DB2 9.7 数据库迁移方案（重定向恢复）

太过爱你忘了你带给我的痛 2022-05-27 02:25 451阅读 0赞

DB2数据库使用率越来越低了，从一开始的大面积使用到现在只剩一部分电信，政府，企业在坚持使用，网上能看到的资料也越来越少，而且能搜索到的资料都是很多版本之前的，已经失去了参考价值。而比较常用的数据库迁移，归档日志设置等，已经是错误的方法，下面主要介绍一下DB2数据库重定向恢复方法。主要用于将DB2数据库从一台主机迁移到另外一台主机，同时修改数据库的安装路径，表空间路径，表空间容器路径，默认缓冲池大小，归档日志路径，Active的归档日志路径。

首先，如果要做全库的备份，一般使用db2 backup命令，其余的还有db2 export命令和db2move命令都不是全库导出，只有数据被导出，而触发器，函数等等都没有导出，所以如果做全库迁移首选db2 backup

但是db2 backup命令有个难点，就是迁移后的主机要与原机器目录结构相似，尤其是表空间，表空间容器的目录或者设备，磁盘要一模一样，数据库安装的位置默认在restore的时候也是原有位置，表空间和缓冲池的设置也是原数据库的设置，这样就会非常的不灵活，因为新的服务器往往会缺少原库的一些磁盘，目录。有时候我们也故意的想把表空间换一换位置，所以db2 restore往往会伴随着重定向恢复，这样我们可以重新指定表空间和表空间容器的位置，迁移起来就灵活多了。

第一步：停止应用，备份数据库

这里有两种备份方式，一种是停机备份，也就是将数据库外部应用停止，这种方式最为稳妥，因为可以保证数据是最新的。另一种是在线备份，可以不停止现有的业务，但是需要给数据库开启归档日志和在线备份的功能。

首先介绍离线备份

1、停止外部服务，如中间件tomcat，数据库客户端，终止db2 connect命令等

终止完成后可以用netstat -an | grep 50000 ；来看是否还有连接在数据库上，50000是我的数据库的监听端口

2、如果外部的连接无法彻底断开，那么就可以使用如下语句强行断开

db2 connect to 数据库名
    db2 quiesce db immediate force connections
    db2 terminate

网上有的资料说需要使用

db2stop force

db2start

这样做也可以，但是没有必要，不需要通过重启数据库来断开连接，反而这样重启之后外部系统还会自动重连回来，不如上面的方法干净彻底。

3、导出数据库到特定路径

为了防止此次导出的数据库与原来的备份混淆，我们最好是建立一个新的路径来存放导出的文件

mkdir /home/db2inst1-m/export
    db2 backup db 数据库名 to /home/db2inst1-m/export/

然后等待一会（视数据量大小而确定），就可以在上面的路径下看到我们备份出的数据库导出文件，同时还会给一个时间戳，把这个时间戳记录下来

ls /home/db2inst1-m/export/
    数据库名.0.db2inst1.NODE0000.CATN0000.20180409173115.001

然后把这个数据库备份文件传输到新机器上备用

scp /home/db2inst1-m/export/* db2inst1@192.168.1.2:/home/db2inst1/import/

下面再介绍一下在线备份

首先需要开启在线备份和归档日志的功能（已经开启的数据库可以跳过这一步）

db2 update db cfg for 数据库名 using userexit on 启用用户出口 
    db2 update db cfg for 数据库名 using logretain on 启用归档日志 
    db2 update db cfg for 数据库名 using trackmod on 启用增量备份功能

开启开关之后需要重启一下数据库，然后再做一次冷备，就可以看到有归档日志产生了

然后执行导出语句

db2 "backup db 数据库名 online to /home/db2inst1-m/export" include logs

这样导出就不需要断开数据库全部的连接，可以在不停止业务的情况下进行导出，一般用于生产数据往测试库上导出的场景。

导出之后就和上面离线备份的方法一样，将备份文件传输到，另一台机器上。

然后我们到另一台服务器上准备恢复数据库，使用db2 restore命令，并且要有redirect关键字，注意，在执行db2 restore命令之前不需要新建这个库，而是有实例即可。

db2 RESTORE DATABASE 原数据库名 FROM '/home/db2inst1/import' TAKEN AT 时间戳 ON '/db2data/wf/' INTO 新数据库名 REDIRECT

这一步执行完毕之后我们就需要配置表空间容器的位置了，由于我原来的数据库用的全都是DB2的系统默认表空间，所以都是自动的，无需设置，而如果你原数据库使用了自定义表空间，就需要再执行其他语句重新定义表空间容器的位置了。

如下，首先登录原数据库查看各个表空间的位置，查看方法如下

1、先连接数据库

db2 connect to 数据库名

2、执行

db2pd -tablespaces -db 数据库名

3、查看表空间和表空间容器的分布状况和ID

Tablespace Configuration:
    Address            Id    Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC NumCntrs MaxStripe  LastConsecPg Name
    0x00007FAA321FA720 0     DMS  Regular 4096   4        Yes  4        1     1         Off 1        0          3            SYSCATSPACE
    0x00007FAA321FBE80 1     SMS  SysTmp  4096   32       Yes  32       1     1         On  1        0          31           TEMPSPACE1
    0x00007FAA322020A0 2     DMS  Large   4096   32       Yes  32       1     1         Off 1        0          31           USERSPACE1
    0x00007FAA32203560 3     DMS  Large   4096   4        Yes  4        1     1         Off 1        0          3            SYSTOOLSPACE
    0x00007FAA32204A20 4     SMS  UsrTmp  4096   4        Yes  4        1     1         On  1        0          3            SYSTOOLSTMPSPACE

Containers:
    Address            TspId ContainNum Type    TotalPgs   UseablePgs PathID     StripeSet  Container 
    0x00007FAA321FBC40 0     0          File    24576      24572      0          0          /home/db2inst1-m/db2inst1/NODE0000/WF/T0000000/C0000000.CAT
    0x00007FAA321FD340 1     0          Path    1          1          0          0          /home/db2inst1-m/db2inst1/NODE0000/WF/T0000001/C0000000.TMP
    0x00007FAA321FF600 2     0          File    16384      16352      0          0          /home/db2inst1-m/db2inst1/NODE0000/WF/T0000002/C0000000.LRG
    0x00007FAA321FF8A0 3     0          File    8192       8188       0          0          /home/db2inst1-m/db2inst1/NODE0000/WF/T0000003/C0000000.LRG
    0x00007FAA321FFAE0 4     0          Path    1          1          0          0          /home/db2inst1-m/db2inst1/NODE0000/WF/T0000004/C0000000.UTM

当我们有了表空间的ID之后，就可以根据ID规划新服务器上的表空间路径了，命令如下

db2 'set tablespace containers for 0 using (file "/db2data/mydb/0000.CAT")'
    db2 'set tablespace containers for 1 using (path "/db2data/mydb/0001/")'
    db2 'set tablespace containers for 2 using (file "/db2data/mydb/0002.LRG")'
    db2 'set tablespace containers for 3 using (file "/db2data/mydb/0003.LRG")'
    db2 'set tablespace containers for 4 using (path "/db2data/mydb/0004/")'

注：使用PATH后面应该跟已经建好的目录，使用FILE后面跟一个不存在的文件，但是文件所在目录要存在。

至于使用file还是path可以根据原数据库的配置配置，但是注意系统默认的五个表空间，就是上面所列的那几个，都是系统自动分配的，无法通过set tablespace containers来修改，只有自定义表空间可以修改。系统默认表空间的位置靠restore命令的ON字段后面的路径来控制，如果不加ON关键字，那么就按照原数据库的路径来配置。

在处理好重定向问题之后，就可以让数据库从恢复状态变成挂起状态了，否则无法修改数据库的相关设置，命令如下

db2 'RESTORE DATABASE 原数据库名 continue'

变成挂起状态后还是不能连接数据库的，因为此时数据库不可用。但是好处是我们可以再挂起状态下修改数据库的相关配置，数据库启动后再修改反而就不方便了，尤其是归档日志相关的配置。

使用命令查看一下数据库当前的归档日志配置，由于是刚恢复完，所以现在的配置应该是原数据库的，由于原数据库放置归档日志的目录在新服务器上不一定有相应的目录，所以一般是要修改的

db2 get db cfg for 新数据库名 | grep -i log

Log retain for recovery status                          = RECOVERY
     User exit for logging status                            = YES
     Catalog cache size (4KB)              (CATALOGCACHE_SZ) = 300
     Log buffer size (4KB)                        (LOGBUFSZ) = 256
     Log file size (4KB)                         (LOGFILSIZ) = 1024
     Number of primary log files                (LOGPRIMARY) = 13
     Number of secondary log files               (LOGSECOND) = 4
     Changed path to log files                  (NEWLOGPATH) = 
     Path to log files                                       = /home/db2inst1-m/db2inst1/NODE0000/SQL00002/SQLOGDIR/
     Overflow log path                     (OVERFLOWLOGPATH) = 
     Mirror log path                         (MIRRORLOGPATH) = 
     First active log file                                   = S0000615.LOG
     Block log on disk full                (BLK_LOG_DSK_FUL) = NO
     Block non logged operations            (BLOCKNONLOGGED) = NO
     Percent max primary log space by transaction  (MAX_LOG) = 0
     Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
     Percent log file reclaimed before soft chckpt (SOFTMAX) = 520
     Log retain for recovery enabled             (LOGRETAIN) = RECOVERY
     User exit for logging enabled                (USEREXIT) = OFF
     HADR log write synchronization mode     (HADR_SYNCMODE) = NEARSYNC
     First log archive method                 (LOGARCHMETH1) = DISK:/home/db2inst1-m/wflog/
     Options for logarchmeth1                  (LOGARCHOPT1) = 
     Second log archive method                (LOGARCHMETH2) = OFF
     Options for logarchmeth2                  (LOGARCHOPT2) = 
     Failover log archive path                (FAILARCHPATH) = 
     Number of log archive retries on error   (NUMARCHRETRY) = 5
     Log archive retry Delay (secs)         (ARCHRETRYDELAY) = 20
     Log pages during index build            (LOGINDEXBUILD) = OFF

可以看到，这份配置还是沿用老数据库的配置，因为新服务器没有/home/db2inst1-m/这个目录了

在这里还能看到，控制归档日志的路径有两个，一个是Path to log files，这里是激活的归档日志的存放目录，里面归档日志文件大小固定，为4K \* LOGFILSIZ，是当前已经激活并没有归档的日志文件，这些文件会随时变更，内容和修改时间不停地变化；

Path to log files由于后面没有给出设置参数，所以无法直接修改，但是可以通过修改NEWLOGPATH这个参数，并在下次启动数据库的时候生效，然后系统自动用NEWLOGPATH重置Path to log files参数，并清除NEWLOGPATH的配置

另一个就是LOGARCHMETH1，这个是已经归档好的归档日志文件目录，这里面的文件一旦生成之后就不会在变更了，可以写入到磁带库等设备上。

还有一个就是MIRRORLOGPATH，是LOGARCHMETH1的镜像目录，默认留空，如果你给这个字段一个赋值一个目录路径，那么它将会和LOGARCHMETH1里面的内容保持同步，相当于做了一次备份，可以用作多磁盘或磁盘+带库的冗余备份方案。一般数据要求不是特别高的话就可以不用配置了。

同时可以进行修改的还有LOGFILSIZ和LOGPRIMARY，这是每个激活的归档日志的大小和数量，决定了正在激活中的归档日志的总空间大小，可以一句业务情况进行设置。

db2 update db cfg for 新数据库名 using LOGPRIMARY 10 LOGSECOND 5 LOGFILSIZ 65535 设置归档日志的数量和大小，大小为这里设置的数值*数据库的Pagesize（4K）
    db2 update db cfg for 新数据库名 using LOGARCHMETH1 DISK:/backup/mydb/archlog/   更换已归档日志的位置
    db2 update db cfg for 新数据库名 using NEWLOGPATH /backup/mydb/archlog/running   更换正在激活归档日志的位置

在数据库配置都已经完成的情况下，再仔细检查一下，就可以开启数据库并连接查阅数据了，方法如下

db2 rollforward db 新数据库名 to end of logs and complete

这一步经常会因为归档日志的缺失导致出错，下文会有详细的讲解

至此，我们的数据库迁移就已经全部完成，现在就可以使用

db2 connect to 新数据库名

来连接数据库了

如果还需要修改系统默认缓冲池大小，并做一次冷备来保留当前刚恢复完的数据，可以进行如下后续工作

db2 'select BPNAME,NPAGES,PAGESIZE from syscat.bufferpools'
    db2 'ALTER BUFFERPOOL IBMDEFAULTBP IMMEDIATE SIZE 131072'

做一次离线备份（刚开启数据库没有连接的情况下进行）

db2 backup db 数据库名 to /backup/wf/full_backup/

常见报错：由于缺少相应的归档日志文件导致自动回滚报错，如下

[db2inst2@localhost ~]$ db2 rollforward db testdb to end of logs and complete
    SQL4970N  Roll-forward recovery on database "TESTDB" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0000642.LOG".

或者出现

[db2inst1@localhost ~]$ db2 rollforward db ms to end of logs and complete
    SQL1265N  The archive log file "S0000645.LOG" is not associated with the 
    current log sequence for database "MS" on node "0".

与此同时，由于回滚操作未完成，是不能连接数据库的，报错如下

db2 connect to testdb
    SQL1117N  A connection to or activation of database "TESTDB" cannot be made 
    because of ROLL-FORWARD PENDING.  SQLSTATE=57019

这意思是说在回滚的时候，找不到最后一个日志S0000642.LOG，所以我们需要到原服务器上拿出这个文件，然后放到新服务器上去。那么它在原服务器的哪里呢？可以通过

db2 get db cfg for 原数据库名 | grep -i log

命令获得，也就是在我们前面设置过的LOGARCHMETH1参数指向的目录里

First log archive method                 (LOGARCHMETH1) = DISK:/backup/xx/archlog/

第二种方法，我们可以使用操作系统的搜索功能来搜索这个文件，使用root用户

[root@msdb ~]# updatedb
    [root@msdb ~]# locate S0000642.LOG
    /backup/testdb/archlog/db2inst1/WF/NODE0000/C0000001/S0000642.LOG

但是我们在转移到新服务器上的时候，就不是放到新数据库LOGARCHMETH1参数所指向的目录下面了，而是应该放到Path to log files所指向的目录下面，而且经常一个归档日志文件还不够，需要拷贝两个归档日志文件到这个文件夹下面。而且有的时候，光放到已归档的日志目录下还不够，还需要放到重做日志目录下面，如下面这个目录

Path to log files                                       = /backup/testdb/archlog/running/NODE0000/

但是这样有一个问题，如果我们导出的数据库是做灾备用的，那么我们在恢复这个数据库的时候不仅需要这个数据库导出文件，还需要一个或两个归档日志，那么如果原来的服务器彻底瘫痪或者数据被破坏，那么即使有备份文件若是丢失归档日志也要完蛋，所以我们第一在备份的时候一定要加上incluede logs参数，如下

db2 "backup db 原数据库名 online to /home/db2inst1/backup" include logs

第二，即使我们备份包含了最后一两个归档日志但还是会报上面的错误是怎么回事呢？

这个主要是因为在restore的时候会自动把备份文件里的归档日志恢复到归档日志路径下，若是新服务器没有这个路径那么归档日志就恢复不成功，也就会出现roll-forward时候找不到归档日志的错误了。所以我们在恢复之前，先使用

db2 get db cfg for 原数据库名 | grep -i log

查看一下LOGARCHMETH1参数所对应的数据库归档日志的放置路径，然后务必在新服务器上通过mkdir -p建立这个路径，并赋予数据库用户db2inst1权限

First log archive method                 (LOGARCHMETH1) = DISK:/backup/xx/archlog/

mkdir -p /backup/xx/archlog/

这样数据库在通过restore恢复的过程中就会在这个路径下放置相关的归档日志文件，如下

[db2inst1@localhost ~]$ ls -l /backup/wf/archlog/db2inst1/MS/NODE0000/C0000001/
    总用量 12152
    -rw-r----- 1 db2inst1 db2grp 12443648 4月  28 14:49 S0000645.LOG

那么为什么有时候需要拷贝一个归档日志.log文件，有时候需要两个呢？其实几个都有可能，这个取决于上次全备和本次全备所间隔的时间，比如下面这个例子：一个数据库每周全备一次，但是每天都会有个增备。我们知道每次全备或者增备都会关闭当前的归档日志文件，另起一个新的。所以每天在全备或者增备的时间点都会切割一下日志文件，形成一个新的。由于每天插入的数据量不大，所以归档日志文件也不是很大，如下图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70][]

上图中，每周六进行一次全备，其余时间都是增备，我获取到一个周六的备份文件，时间戳是20201003231502，即在10约3日晚上11：15进行的全备，先执行restore命令，获取log信息，发现第一个log为S0002505.LOG，是上周三的。如下

$ db2 get db cfg for alex2020 | grep log
     User exit for logging status                            = YES
     Catalog cache size (4KB)              (CATALOGCACHE_SZ) = 300
     Number of primary log files                (LOGPRIMARY) = 10
     Number of secondary log files               (LOGSECOND) = 5
     Changed path to log files                  (NEWLOGPATH) = 
     Path to log files                                       = /backup/alex/archlog/running/NODE0000/
     Overflow log path                     (OVERFLOWLOGPATH) = 
     Mirror log path                         (MIRRORLOGPATH) = 
     First active log file                                   = S0002505.LOG
     Block log on disk full                (BLK_LOG_DSK_FUL) = NO
     Block non logged operations            (BLOCKNONLOGGED) = NO
     Percent max primary log space by transaction  (MAX_LOG) = 0
     Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
     Percent log file reclaimed before soft chckpt (SOFTMAX) = 520
     User exit for logging enabled                (USEREXIT) = OFF
     HADR log write synchronization mode     (HADR_SYNCMODE) = NEARSYNC
     First log archive method                 (LOGARCHMETH1) = DISK:/db2data/alex2020/archlog/
     Options for logarchmeth1                  (LOGARCHOPT1) = 
     Second log archive method                (LOGARCHMETH2) = OFF
     Options for logarchmeth2                  (LOGARCHOPT2) = 
     Failover log archive path                (FAILARCHPATH) = 
     Number of log archive retries on error   (NUMARCHRETRY) = 5

此时，我们要么从restore出的日志文件目录获取，或者到源数据库所在服务器拷贝过来，要拷贝的数量就是上面截图中从First active log file到恢复备份文件的时间戳的那些文件，就是标黄的那些。证据就是我通过一个文件一个文件的拷贝，然后执行命令，结果如下：

$ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002505.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002506.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002507.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002508.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002509.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002510.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    SQL4970N  Roll-forward recovery on database "alex2020" cannot reach the 
    specified stop point (end-of-log or point-in-time) on database partition(s) 
    "0". Roll-forward recovery processing has halted on log file "S0002511.LOG".
    $ db2 rollforward db alex2020 to end of logs and complete
    
                                     Rollforward Status
    
     Input database alias                   = alex2020
     Number of nodes have returned status   = 1
    
     Node number                            = 0
     Rollforward status                     = not pending
     Next log file to be read               =
     Log files processed                    = S0002505.LOG - S0002512.LOG
     Last committed transaction             = 2020-10-03-15.15.22.000000 UTC
    
    DB20000I  The ROLLFORWARD command completed successfully.
    $ db2 connect to alex2020
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.0
     SQL authorization ID   = DB2INST1
     Local database alias   = alex2020

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70]: /images/20220527/9e88102d27f94c20ab4ad400842d51da.png