使用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