DB2 数据库恢复测试

更新May 24,

今天在删除mydb1数据库之后想restore一下database mydb1,可以不知道是什么原因出现错误SQL2043N错误,开始怀疑是内存问题,但是我的SHMMAX和SHMALL参数都有设置的足够大,根据官方建议看是不是Address Space Layout Randomization ( ASLR )的问题,修改了之后还是解决不了问题,会不会是因为我之前drop database mydb1时的操作问题呢? 反正不管了,先把数据库restore回来再说。 于是我思考,是不是可以重新用命令db2 create database mydb1新建一个mydb1数据库,然后再利用之前备份的image restore回来。开始实施:

MYDB1.0.db2inst1.DBPART000.20130524043112.001

  1. db2 create database mydb1
  2. db2 restore db mydb1 taken at 20130524043112
  3. db2 rollforward db mydb1 stop
因为我们新库没有东西可用,所以我们不用rollforward,直接stop解除rollforward pending就好了。

成功,没有任何问题。只是最近出现过几次内存问题,不知为何?


========================================================================================


 今天又重新做了DB2的恢复测试,研究在哪些情况下可以恢复成功。测试数据库名TEST。

1. 数据库换目录,也就是在相同实例下通过数据库备份介质进行恢复。

     我们有一份备份介质:TEST.0.db2inst1.DBPART000.20130428103816.001

    这个问题涉及到路径的变换,如果说表空间全部都是system managed tablespace,那么很好办,因为存储路径全部都在 <$$>db2inst1/NODE0000/下面,该路径下面有如下3个文件夹:SQL00001、sqldbdir、TEST。在这种情况下直接可以用命令:
                  db2 restore db test from <backup_image_path> taken at <backup_image_tiemstamp> on <target_path>。

     如果我们的数据库中有表空间是managed by database,那么就涉及到该表空间存储路径的问题。我们可以使用原来的路径,如果路径不存在,将会新建,也可以切换路径。建议使用命令生成脚本:

                  db2 restore db test from <backup_image_path> taken at <backup_image_tiemstamp> on <target_path> redirect generate script <script_path&name>.

     接着可以分析script,并按照需求作出修改。


2. 数据库目录拷贝进行恢复。

     这个测试中我们仅有TEST数据库目录的一份拷贝,原数据已经被drop掉了。然后我们希望能够利用这个备份恢复数据库。

     step 1:我们将备份的目录移到原来数据库TEST的路径下。目的是跟原本数据库拥有相同的路径。

     step 2:我们进行数据库本地编目检查:db2 list db directory on <previous_db_path eg: home/db2inst1/disk>. 检查发现本地编目正确。

     step 3:将我们的备份目录的数据库TEST编目到系统数据库编目:db2 catalog db test on <previous_db_path>.

     step 4 :  我们将数据重启,刷新directory cache。查看系统数据编目信息:db2 list db directory. 发现能看到我们的TEST数据库了。

     step 5 :  尝试连接数据库db2 connect to test,提示tablespace access is not allowed。我们有表空间为DMS表空间,数据没有得到备份,drop的时候被删除了。

     step 6 :  这时我们数据库启动不了,我们需要用此命令:db2 "restart db test with drop pending tablespaces (<tablespace_name>)". 将无效的表空间设到drop pending状态。 此时数据库就可以连接上了。


实验2补充说明:今天重新做了第2个实验,利用数据库目录的拷贝进行恢复。发现直接catalog完db test后,刷新directory cache就能够连上数据库test了。ts2处于offline状态。

                               我们谈论过数据库的崩溃恢复,在使用归档日志的时候,在崩溃恢复期间如果个别表空间发生错误,那个会让该表空间脱机,崩溃恢复将继续进行,该表空间直到修复后才能对其进行访问,在崩溃恢复完成时,该数据库中的其他空间将是可以访问的。




转载于:https://www.cnblogs.com/jackhub/archive/2013/04/29/3147189.html

你可能感兴趣的:(DB2 数据库恢复测试)