DPF备份恢复实践
企业对数据处理资源越来越多地依赖于关系型数据管理系统 (RDBMS)，以满足日益增长的数据存储和处理需求。当数据库和数据仓库变得越来越大时，管理不断增长的存储数据的成为影响 RDBMS 性能的一个关键因素。要应对数据库的增长，数据库系统必须具有可扩展性能，以便能够应用额外计算资源。DB2 DPF提供的数据分区功能支持将单个数据库扩展到多个服务器上。有了分区以后，就可以实现跨分区分布数据。
使用 DPF 之后，数据库将变得可伸缩，因为可以根据数据增长添加新机器或者节点，并将数据库扩展到它们上面。这意味着每个附加机器可为数据库提供更多的 CPU、更多的内存、更多的磁盘。对于管理数据仓储、数据挖掘和在线分析处理 (OLAP) 工作负载而言 DPF 是一个完美的选择。它可以与在线事物处理 (OLTP) 工作负载和睦相处。
对于任何数据库管理系统而言，备份和恢复都是确保数据可恢复性的关键功能。DB2 中的备份操作可以是在线操作，也可以是离线操作。您不可能知道系统何时会出现灾难或故障而导致停机，因此，最好就是随时做好准备，不仅仅要保护数据不受外部因素干扰，也要考虑来自内部的因素，例如，某一个内部用户可能不小心使用非正确信息而导致数据库损坏。鉴于这些原因，理解备份和恢复功能如何用于您的数据库管理系统是至关重要的，您应该有一个计划周密的备份策略。
DPF备份区别于普通单分区数据库备份的一个点是，DPF在每次做备份时必须先对0节点（协调节点）进行备份，之后才可以对其他节点进行串行或者并行的备份。同理DPF数据库进行恢复时也是同样的道理，必须先对0节点（协调节点）进行恢复，才可以对其他节点进行恢复。
在 DPF 中，您可以在一个数据库分区服务器上逐个运行命令，也可以并行运行。您可以使用 db2_all 在所有指定的数据库分区服务器上运行命令。您可以使用 <<-xxx< 和 <<+xxx< 前缀序列限制数据库分区服务器的个数。您可以使用 <<-xxx< 前缀向 DPF 中的所有分区发出命令，除了 xxx 指定的节点外。类似地，您可以使用 '<<+xxx<' 前缀仅向 xxx 指定的分区发出命令。db2_all 可前置下列任务到您的命令中。
export DB2NODE=xxx（Korn shell 语法）
在此任务中，xxx 是数据库分区号，可以从 db2nodes.cfg 文件中获取，因此，该命令被路由到一个特定数据库分区服务器上。在进行操作时，默认会连接到当前指定的节点进行操作。
我们对以下场景进行了测试，用以验证在生产环境中是否可用。
测试场景：
多分区数据库全备 |
多分区数据库全库恢复 |
多分区数据库表空间备份 |
多分区数据库前滚恢复 |
多分区数据库copy yes 前滚 |
测试软件：
操作系统 | AIX 6.1 |
备份软件 | NBU 7 |
数据库版本 | DB2 9.7.5 |
数据库 | TEST 9分区数据库 |
1 多分区数据库全备测试
要备份分区数据库，必须要首先在编目分区上调用备份实用程序，然后在其他数据库分区上调用备份实用程序。
离线备份命令范例：
对协调节点进行备份： db2_all "<<+0< db2 BACKUP DB TEST to /data/BACKUPS" 对其他节点进行并行备份（数据库自动进行并行备份操作） db2_all "|<<-0< db2 BACKUP DB TEST to /data/BACKUPS" |
在线备份命令范例：
对协调节点进行备份： db2_all "<<+0< db2 BACKUP DB TEST ONLINE to /data/BACKUPS" 对其他节点进行并行备份（数据库自动进行并行备份操作）
db2_all "|<<-0< db2 BACKUP DB TEST ONLINE to /data/BACKUPS" |
备份完成之后对文件验证可以看到类似如下的文件：
TEST.0.db2inst1.NODE0000.CATN0000.20120531103515.001 TEST.0.db2inst1.NODE0007.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0003.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0002.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0001.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0008.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0006.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0005.CATN0000.20120531103528.001 TEST.0.db2inst1.NODE0004.CATN0000.20120531103528.001 |
其中信息如下：
· TEST：代表的数据库名
· 0：备份操作类型，0 代表完全离线数据库级备份
· inst_test：实例名
· NODE0000：分区号
· CATN0000：目录节点 (syscatspace) 驻留的数据库分区号
· 20120531103528：时间戳
· 001：序列号
2 使用备份进行全库恢复
当发生数据损坏或者数据丢失，数据库的副本将被用于恢复数据库，至少可以恢复到执行备份操作时数据库的状态。恢复也是数据库升级或者迁移的一部分。在 DPF 中，恢复是一个较为麻烦的操作。如果您正在使用 DPF，那您首先需要恢复目录节点，然后继续恢复其余节点。在示例中，分区 0 是目录节点。
2.1使用备份本机进行恢复
查询各节点上备份及备份时间戳: /usr/openv/netbackup/bin/bplist -C TESTDB00 -S SBNBUsvc -t 18 -R /|grep TEST. /usr/openv/netbackup/bin/bplist -C TESTDB01 -S SBNBUsvc -t 18 -R /|grep TEST. /usr/openv/netbackup/bin/bplist -C TESTDB02 -S SBNBUsvc -t 18 -R /|grep TEST.
生成恢复脚本: db2_all "<<+0< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170003 redirect generate script /db2home/db2TEST/nbu/r.scr.node0"
db2_all "<<+1< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node1" db2_all "<<+2< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node2" db2_all "<<+3< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node3" db2_all "<<+4< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node4" db2_all "<<+5< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node5" db2_all "<<+6< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node6" db2_all "<<+7< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node7" db2_all "<<+8< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node8" 修改脚本,1-8节点需要加上without prompting,否则会确认是否overwrite db.
要解决这个不一致性问题，需要前滚数据库到日志终点，使其达到一致。对于离线备份恢复，如果您在恢复命令中指定 WITHOUT ROLLING FORWARD 选项，那么数据库在成功恢复以后不会置于前滚悬挂状态。对于在线备份恢复，前滚是强制性的。
执行数据库恢复: 对0分区进行恢复之后才能对其他分区进行并行恢复。 nohup db2_all "<<+0< db2 -tvf /db2home/db2TEST/nbu/r.scr.node0" &
nohup db2_all "<<+1< db2 -tvf /db2home/db2TEST/nbu/r.scr.node1" & nohup db2_all "<<+2< db2 -tvf /db2home/db2TEST/nbu/r.scr.node2" & nohup db2_all "<<+3< db2 -tvf /db2home/db2TEST/nbu/r.scr.node3" & nohup db2_all "<<+4< db2 -tvf /db2home/db2TEST/nbu/r.scr.node4" & nohup db2_all "<<+5< db2 -tvf /db2home/db2TEST/nbu/r.scr.node5" & nohup db2_all "<<+6< db2 -tvf /db2home/db2TEST/nbu/r.scr.node6" & nohup db2_all "<<+7< db2 -tvf /db2home/db2TEST/nbu/r.scr.node7" & nohup db2_all "<<+8< db2 -tvf /db2home/db2TEST/nbu/r.scr.node8" &
查询数据库是否处于rollforward pending状态: db2 rollforward db TEST query status
Rollforward Status
Input database alias = TEST Number of nodes have returned status = 9
Node number Rollforward Next log Log files processed Last committed transaction status to be read ----------- -------------------------- ------------------- ------------------------- -------------------------- 0 DB pending S0008054.LOG - 2012-02-19-09.06.00.000000 UTC 1 DB pending S0004320.LOG - 2012-02-19-09.09.27.000000 UTC 2 DB pending S0004268.LOG - 2012-02-19-09.10.08.000000 UTC 3 DB pending S0004685.LOG - 2012-02-19-09.10.13.000000 UTC 4 DB pending S0004247.LOG - 2012-02-19-09.10.19.000000 UTC 5 DB pending S0004195.LOG - 2012-02-19-09.10.12.000000 UTC 6 DB pending S0006033.LOG - 2012-02-19-09.09.51.000000 UTC 7 DB pending S0004492.LOG - 2012-02-19-09.09.44.000000 UTC 8 DB pending S0004382.LOG - 2012-02-19-09.09.47.000000 UTC
TESTDB00: db2 rollforward db ... completed ok
前滚数据库:
db2 "rollforward db TEST to end of logs and complete overflow log path (/db2/db2TEST/db2arc0/logtarget, /db2/db2TEST/db2arc1/logtarget on dbpartitionnum 1, /db2/db2TEST/db2arc2/logtarget on dbpartitionnum 2, /db2/db2TEST/db2arc3/logtarget on dbpartitionnum 3, /db2/db2TEST/db2arc4/logtarget on dbpartitionnum 4, /db2/db2TEST/db2arc5/logtarget on dbpartitionnum 5, /db2/db2TEST/db2arc6/logtarget on dbpartitionnum 6, /db2/db2TEST/db2arc7/logtarget on dbpartitionnum 7, /db2/db2TEST/db2arc8/logtarget on dbpartitionnum 8 )" |
2.2使用备份异机进行恢复（即重定向恢复）
恢复前准备： 根据原实例信息创建用户和实例，其中实例用户必须和原用户ID保持一致。 创建用户组及用户： mkgroup -'A' id='1001' db2iadm1 mkuser id=1001 pgrp=db2iadm1 home=/db2home/db2TEST db2TEST （实例用户） 配置RSH到用户db2TEST $ vi ~/.rhosts CASHMAPP2 db2TEST 创建实例： ./db2icrt -p db2c_db2TEST -s ese -u db2TEST db2TEST 修改/etc/services和db2nodes.cfg文件。 创建数据存储路径保持和原库一致。
开始恢复： 查询各节点上备份及备份时间戳: /usr/openv/netbackup/bin/bplist -C TESTDB00 -S SBNBUsvc -t 18 -R /|grep TEST. /usr/openv/netbackup/bin/bplist -C TESTDB01 -S SBNBUsvc -t 18 -R /|grep TEST. /usr/openv/netbackup/bin/bplist -C TESTDB02 -S SBNBUsvc -t 18 -R /|grep TEST. 修改master server的bp.conf,添加异机恢复配置: FORCE_RESTORE_MEDIA_SERVER=TESTDB00 SBNBUsvc FORCE_RESTORE_MEDIA_SERVER=TESTDB01 SBNBUsvc FORCE_RESTORE_MEDIA_SERVER=TESTDB02 SBNBUsvc 生成恢复脚本: 修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB00, db2_all "<<+0< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170003 redirect generate script /db2home/db2TEST/nbu/r.scr.node0" 修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB01, db2_all "<<+1< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node1" db2_all "<<+2< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node2" db2_all "<<+3< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node3" db2_all "<<+4< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node4" 修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB02, db2_all "<<+5< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170617 redirect generate script /db2home/db2TEST/nbu/r.scr.node5" db2_all "<<+6< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node6" db2_all "<<+7< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node7" db2_all "<<+8< db2 restore db TEST load /usr/openv/netbackup/bin/nbdb2.sl64 taken at 20120219170618 redirect generate script /db2home/db2TEST/nbu/r.scr.node8" 修改脚本,1-8节点需要加上without prompting,否则会确认是否overwrite db.
执行数据库恢复:
修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB00, nohup db2_all "<<+0< db2 -tvf /db2home/db2TEST/nbu/r.scr.node0" & 修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB01, nohup db2_all "<<+1< db2 -tvf /db2home/db2TEST/nbu/r.scr.node1" & nohup db2_all "<<+2< db2 -tvf /db2home/db2TEST/nbu/r.scr.node2" & nohup db2_all "<<+3< db2 -tvf /db2home/db2TEST/nbu/r.scr.node3" & nohup db2_all "<<+4< db2 -tvf /db2home/db2TEST/nbu/r.scr.node4" & 修改db2TEST实例目录下的bp.conf中CLIENT_NAME参数为TESTDB02, nohup db2_all "<<+5< db2 -tvf /db2home/db2TEST/nbu/r.scr.node5" & nohup db2_all "<<+6< db2 -tvf /db2home/db2TEST/nbu/r.scr.node6" & nohup db2_all "<<+7< db2 -tvf /db2home/db2TEST/nbu/r.scr.node7" & nohup db2_all "<<+8< db2 -tvf /db2home/db2TEST/nbu/r.scr.node8" &
查询数据库是否处于rollforward pending状态: db2 rollforward db TEST query status
Rollforward Status
Input database alias = TEST Number of nodes have returned status = 9
Node number Rollforward Next log Log files processed Last committed transaction status to be read ----------- -------------------------- ------------------- ------------------------- -------------------------- 0 DB pending S0008054.LOG - 2012-02-19-09.06.00.000000 UTC 1 DB pending S0004320.LOG - 2012-02-19-09.09.27.000000 UTC 2 DB pending S0004268.LOG - 2012-02-19-09.10.08.000000 UTC 3 DB pending S0004685.LOG - 2012-02-19-09.10.13.000000 UTC 4 DB pending S0004247.LOG - 2012-02-19-09.10.19.000000 UTC 5 DB pending S0004195.LOG - 2012-02-19-09.10.12.000000 UTC 6 DB pending S0006033.LOG - 2012-02-19-09.09.51.000000 UTC 7 DB pending S0004492.LOG - 2012-02-19-09.09.44.000000 UTC 8 DB pending S0004382.LOG - 2012-02-19-09.09.47.000000 UTC
TESTDB00: db2 rollforward db ... completed ok
前滚数据库:
db2 "rollforward db TEST to end of logs and complete overflow log path (/db2/db2TEST/db2arc0/logtarget, /db2/db2TEST/db2arc1/logtarget on dbpartitionnum 1, /db2/db2TEST/db2arc2/logtarget on dbpartitionnum 2, /db2/db2TEST/db2arc3/logtarget on dbpartitionnum 3, /db2/db2TEST/db2arc4/logtarget on dbpartitionnum 4, /db2/db2TEST/db2arc5/logtarget on dbpartitionnum 5, /db2/db2TEST/db2arc6/logtarget on dbpartitionnum 6, /db2/db2TEST/db2arc7/logtarget on dbpartitionnum 7, /db2/db2TEST/db2arc8/logtarget on dbpartitionnum 8 )" |
3 load copy yes 和 copy yes方式的前滚方法
因为load操作不记录日志，在多分区环境下如果不采用load copy yes方式，在数据库异常之后进行恢复操作，在前滚时有load操作的表将不可用，为了保证数据的安全。我们在多分区环境下也采用load copy yes的方式导入数据。
Load copy yes操作
在多分区环境下load copy yes使用的存储路径必须保证每个节点可见，目前TEST采用的是GPFS文件系统，三台服务器可见（/db2/db2TEST/copy_yes）。
Load copy yes 操作举例如下：
load from /db2/db2TEST/backup/temp1.del of del replace into TEST.temp1 copy yes to /db2/db2TEST/copy_yes |
在导入数据完成之后在目录下会生成类似如下的文件，在数据库恢复前滚时会使用这些备份进行前滚恢复。
TEST.4.db2inst1.NODE0008.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0007.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0006.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0005.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0004.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0003.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0002.CATN0000.20120507165714.001 TEST.4.db2inst1.NODE0001.CATN0000.20120507165714.001 |
Copy yes 方式前滚方法
多分区数据库在恢复数据库完成之后，不能立即的前滚，我们需要从数据库历史记录中查看是否有load 操作在备份时间戳之后。
查看是否有load的命令为：
db2 LIST HISTORY LOAD SINCE 20120507135212 FOR TEST |
找到时间戳之后的表之后，在copy yes存储路径找到具体的备份文件。
设置全局load recovery 配置文件：
db2_all "db2set DB2LOADREC=/db2/db2TEST/load/loadrec" |
修改配置文件，配置内容具体如下：
TIM 20120229095908 --->时间戳 DBP 0 --->连接分区号 SCH DB2TEST --->tabschema TAB TEMP1 --->tabname DAT TEST --->database DB2 db2TEST --->instance BUF NULL SES NULL TYP L --->使用备份介质的连接方式 LOC 8 --->表所设计的分区数，如下是指定每个分区的归档文件路径 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0008.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0007.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0006.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0005.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0004.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0003.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0002.CATN0000.20120229095908.001 ENT /db2/db2TEST/load/TEST.4.db2TEST.NODE0001.CATN0000.20120229095908.001 |
查看当前数据库是否处于pending状态：
db2 rollforward db TEST query status
Rollforward Status
Input database alias = TEST Number of nodes have returned status = 9
Node number Rollforward Next log Log files processed Last committed transaction status to be read ----------- -------------------------- ------------------- ------------------------- -------------------------- 0 DB pending S0000001.LOG - 2012-02-29-01.57.31.000000 UTC 1 DB pending S0000005.LOG - 2012-02-29-01.57.39.000000 UTC 2 DB pending S0000005.LOG - 2012-02-29-01.57.42.000000 UTC 3 DB pending S0000005.LOG - 2012-02-29-01.57.45.000000 UTC 4 DB pending S0000005.LOG - 2012-02-29-01.57.48.000000 UTC 5 DB pending S0000005.LOG - 2012-02-29-01.57.51.000000 UTC 6 DB pending S0000005.LOG - 2012-02-29-01.57.54.000000 UTC 7 DB pending S0000005.LOG - 2012-02-29-01.57.57.000000 UTC 8 DB pending S0000005.LOG - 2012-02-29-01.58.00.000000 UTC |
对数据库进行前滚恢复：
db2 "rollforward db TEST to end of logs and complete " Rollforward Status
Input database alias = TEST Number of nodes have returned status = 9
Node number Rollforward Next log Log files processed Last committed transaction status to be read ----------- -------------------------- ------------------- ------------------------- -------------------------- 0 not pending S0000001.LOG-S0000003.LOG 2012-02-29-01.59.11.000000 UTC 1 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 2 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 3 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 4 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 5 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 6 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 7 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC 8 not pending S0000005.LOG-S0000007.LOG 2012-02-29-01.59.11.000000 UTC
|
本文节选自《数据库与信息治理》，作者：民生银行 王健、翟红波、袁春光
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞1作者其他文章
评论 1 · 赞 1
评论 0 · 赞 0
评论 1 · 赞 0
评论 0 · 赞 1
评论 5 · 赞 3
添加新评论0 条评论