更新May 24，
今天在删除mydb1数据库之后想restore一下database mydb1，可以不知道是什么原因出现错误SQL2043N错误，开始怀疑是内存问题
MYDB1.0.db2inst1.DBPART000.20130524043112.001
- db2 create database mydb1
- db2 restore db mydb1 taken at 20130524043112
- db2 rollforward db mydb1 stop
========================================================================================
今天又重新做了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状态。
我们谈论过数据库的崩溃恢复，在使用归档日志的时候，在崩溃恢复期间如果个别表空间发生错误，那个会让该表空间脱机，崩溃恢复将继续进行，该表空间直到修复后才能对其进行访问，在崩溃恢复完成时，该数据库中的其他空间将是可以访问的。