使用db2 load from時(shí)導(dǎo)致DB的tablespace置成backup pending狀態(tài)
使用db2 load from時(shí)導(dǎo)致DB的tablespace置成backup pending狀態(tài) 我在往表里面更新或者插入新的數(shù)據(jù)有報(bào)錯(cuò)，有報(bào)SQL0290N這個(gè)錯(cuò)誤，Table space access is not allowed. SQLSTATE=55039 但是這個(gè)時(shí)候可以往里面load數(shù)據(jù)，我的命令是這樣寫的 $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是怎么回事！便找到下面這個(gè)，
2. 受支持的表空間狀態(tài) 狀態(tài) 十六進(jìn)制狀態(tài)值 描述 示例 Backup Pending 0x20 在執(zhí)行指定時(shí)間點(diǎn)的（point-in-time）表空間前滾操作之后，或者在執(zhí)行指定了 COPY NO 選項(xiàng)的 LOAD 操作（針對(duì)可恢復(fù)的數(shù)據(jù)庫(kù)）之后，表空間處于這種狀態(tài)。在使用該表空間之前，必須備份該表空間（或者是整個(gè)數(shù)據(jù)庫(kù)）。如果沒有備份這個(gè)表空間，那么只能對(duì)其中包含的表進(jìn)行查詢，而無(wú)法更新它們。注意：在啟用數(shù)據(jù)庫(kù)進(jìn)行前滾恢復(fù)之后，還必須立即對(duì)該數(shù)據(jù)庫(kù)進(jìn)行備份。如果 logretain數(shù)據(jù)庫(kù)配置參數(shù)被設(shè)為 RECOVERY，或者 userexit數(shù)據(jù)庫(kù)配置參數(shù)被設(shè)為 YES，那么該數(shù)據(jù)庫(kù)是可恢復(fù)的。直到對(duì)這樣的數(shù)據(jù)庫(kù)進(jìn)行了備份，您才可以連接它。備份后， backup_pending數(shù)據(jù)庫(kù)配置參數(shù)會(huì)被設(shè)為 NO。
1. 已知載入的輸入文件 staff_data.del 具有以下內(nèi)容： 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; 上面提到“在使用該表空間之前，必須備份該表空間（或者是整個(gè)數(shù)據(jù)庫(kù)）” 于是我先把整個(gè)數(shù)據(jù)庫(kù)備份了一下，再查看tablespace狀態(tài)時(shí)，都是Normal的，再次更新或者往表里面插入數(shù)據(jù)時(shí)一切正常。 這個(gè)時(shí)候我想起我下的db2 load的命令，以往都是在最后面加了NONRECOVERABLE這個(gè)參數(shù)，這次沒有，問題肯定在這里。
便又順藤摸瓜看到了下面的解釋， 如果要對(duì)可恢復(fù)數(shù)據(jù)庫(kù)執(zhí)行一系列裝入操作，那么與每次調(diào)用裝入操作時(shí)都指定 COPY YES 選項(xiàng)相比，指定每個(gè)裝入操作都不可恢復(fù)并在裝入序列結(jié)束時(shí)進(jìn)行備份的速度更快。可以使用 NONRECOVERABLE 選項(xiàng)來(lái)指定將裝入事務(wù)標(biāo)記為不可恢復(fù)，這樣，以后不可能通過前滾操作恢復(fù)該事務(wù)。
Rollforward 實(shí)用程序?qū)⑻^該事務(wù)，并將把裝入數(shù)據(jù)的表標(biāo)記為“無(wú)效”。
該實(shí)用程序還將忽略該對(duì)表執(zhí)行的任何后續(xù)事務(wù)。在前滾操作完成后，只能刪除這樣的表（請(qǐng)參閱圖 2）。如果指定了此選項(xiàng)，在裝入操作完成后就不會(huì)將表空間置于備份暫掛狀態(tài)，并且在裝入操作執(zhí)行期間不必創(chuàng)建所裝入數(shù)據(jù)的副本。
本文來(lái)自[Svn中文網(wǎng)]轉(zhuǎn)發(fā)請(qǐng)保留本站地址：http://www.svn8.com/sql/Db2/2009111212779.html