使用db2 load from时导致DB的tablespace置成backup pending状态
使用db2 load from时导致DB的tablespace置成backup pending状态 我在往表里面更新或者插入新的数据有报错，有报SQL0290N这个错误，Table space access is not allowed. SQLSTATE=55039 但是这个时候可以往里面load数据，我的命令是这样写的 $db2 load from /worktmp/temp.del of del replace into SCHEMA.TABLENAME 于是搜了很多东西，有人告诉我使用下面命令看看State的值是什么 $db2 list tablespaces show detail Tablespace ID = 4 Name = TBS4K Type = Database managed space Contents = Any data State = 0x0020 Detailed explanation: Backup pending Total pages = 8388608 Useable pages = 8388096 Used pages = 340864 Free pages = 8047232 High water mark (pages) = 340864 Page size (bytes) = 4096 Extent size (pages) = 128 Prefetch size (pages) = 384 Number of containers = 4 Minimum recovery time = 2008-10-14-05.51.17.000000 Tablespace ID = 5 Name = TBS4KM Type = Database managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 8388608 Useable pages = 8388096 Used pages = 4224 Free pages = 8383872 High water mark (pages) = 4224 Page size (bytes) = 4096 Extent size (pages) = 128 Prefetch size (pages) = 384 Number of containers = 4 Minimum recovery time = 2008-10-23-07.30.01.000000 于是再搜，看看tablespace backup pending是怎么回事！便找到下面这个，
2. 受支持的表空间状态 状态 十六进制状态值 描述 示例 Backup Pending 0x20 在执行指定时间点的（point-in-time）表空间前滚操作之后，或者在执行指定了 COPY NO 选项的 LOAD 操作（针对可恢复的数据库）之后，表空间处于这种状态。在使用该表空间之前，必须备份该表空间（或者是整个数据库）。如果没有备份这个表空间，那么只能对其中包含的表进行查询，而无法更新它们。注意：在启用数据库进行前滚恢复之后，还必须立即对该数据库进行备份。如果 logretain数据库配置参数被设为 RECOVERY，或者 userexit数据库配置参数被设为 YES，那么该数据库是可恢复的。直到对这样的数据库进行了备份，您才可以连接它。备份后， backup_pending数据库配置参数会被设为 NO。
1. 已知载入的输入文件 staff_data.del 具有以下内容： 11,"Melnyk",20,"Sales",10,70000,15000: update db cfg for sample using logretain recovery; backup db sample; connect to sample; load from staff_data.del of del messages load.msg insert into staff copy no; update staff set salary = 69000 where id = 11;
2.update db cfg for sample using logretain recovery; connect to sample; 上面提到“在使用该表空间之前，必须备份该表空间（或者是整个数据库）” 于是我先把整个数据库备份了一下，再查看tablespace状态时，都是Normal的，再次更新或者往表里面插入数据时一切正常。 这个时候我想起我下的db2 load的命令，以往都是在最后面加了NONRECOVERABLE这个参数，这次没有，问题肯定在这里。
便又顺藤摸瓜看到了下面的解释， 如果要对可恢复数据库执行一系列装入操作，那么与每次调用装入操作时都指定 COPY YES 选项相比，指定每个装入操作都不可恢复并在装入序列结束时进行备份的速度更快。可以使用 NONRECOVERABLE 选项来指定将装入事务标记为不可恢复，这样，以后不可能通过前滚操作恢复该事务。
Rollforward 实用程序将跳过该事务，并将把装入数据的表标记为“无效”。
该实用程序还将忽略该对表执行的任何后续事务。在前滚操作完成后，只能删除这样的表（请参阅图 2）。如果指定了此选项，在装入操作完成后就不会将表空间置于备份暂挂状态，并且在装入操作执行期间不必创建所装入数据的副本。
本文来自[Svn中文网]转发请保留本站地址：http://www.svn8.com/sql/Db2/2009111212779.html