DB2 数据库恢复测试

更新May 24，

今天在删除mydb1数据库之后想restore一下database mydb1，可以不知道是什么原因出现错误SQL2043N错误，开始怀疑是内存问题<SQL2043N  Unable to start a child process or thread>，但是我的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