【正文】 ,fix_count=。,39。4．將塊標(biāo)志為損壞的：(39。,corrupt_count=:cc)。,39。例：(39。2．、索引、分區(qū)中的塊損壞。temp_data39。REPAIR_TABLE39。其中TABLE_TYPE為：REPAIR_TABLE（表），ORPHAN_TABLE（索引）；ACTION為：CREATE_ACTION（創(chuàng)建表），PURGE_ACTION（刪除無(wú)關(guān)數(shù)據(jù)），DROP_ACTION（刪除表）。（二）使用DBMS_REPAIR包。當(dāng)塊改變時(shí)，DB_BLOCK_CHECKING對(duì)塊進(jìn)行邏輯校驗(yàn)。6． 必須刪除該對(duì)象以釋放回滾塊。4． 查看TRACE文件，應(yīng)有error recovery tx(,) object .TX(,)，指出事務(wù)信息，其中object 。二、回滾段需要恢復(fù)如果回滾段處于NEED RECOVERY狀態(tài)，需要執(zhí)行以下步驟進(jìn)行恢復(fù)：1． 查看所有聯(lián)機(jī)的表空間與數(shù)據(jù)文件2． = 10015 trace name context forever,level 10，這將生成一個(gè)追蹤文件，其中含有事務(wù)與回滾的信息。文件名39。9． RECOVER DATAFILE 文件名。新路徑文件名39。老路徑文件名39。6． STARTUP MOUNT。 OFFLINE；4． 試著將數(shù)據(jù)文件拷貝到別的磁盤。3． 如果數(shù)據(jù)庫(kù)處于ARCHIVELOG模式，仍應(yīng)關(guān)閉數(shù)據(jù)庫(kù)，如果不能關(guān)閉數(shù)據(jù)庫(kù)，則將相應(yīng)的數(shù)據(jù)文件脫機(jī)：ALTER DATABASE DATAFILE 39。其中，文件號(hào)與塊號(hào)是ORA1115中指出的，如果該查詢持續(xù)指向某表或索引，則重建它們即可。2） 如果指向相同磁盤的不同文件，則是磁盤的問(wèn)題，轉(zhuǎn)到第二步。在此介紹三種使用Oracle8i修復(fù)損壞數(shù)據(jù)塊的方法。轉(zhuǎn)載一份8i的壞塊處理方法 用ORACLE8i修復(fù)數(shù)據(jù)庫(kù)壞塊的三種方法 收藏在進(jìn)行SUN CLUSTER雙機(jī)切換、意外斷電或其它情況下，有時(shí)會(huì)發(fā)生共享盤MOUNT不上的情況，需要使用FSCK對(duì)共享盤進(jìn)行修復(fù)。這次只有7個(gè)錯(cuò)誤，數(shù)據(jù)庫(kù)記錄也只有10萬(wàn)多點(diǎn)，我們兩個(gè)人差不多忙了一周。 然后把那條記錄刪掉，再作exp，整個(gè)重來(lái)一遍。就沒再做下去。發(fā)現(xiàn)是讀到一條壞記錄，oracle不報(bào)錯(cuò)，只是狂寫udump和alert，udump寫了個(gè)6G的文件，alert的大小也10G了。我用了這個(gè)方法了，效率很低，每條差不多要一秒鐘，總時(shí)間估算在40小時(shí)以上。end loop。mit。exceptionwhen others thenrollback。end if。insert into gz_test_pic values (v_picid,empty_blob())returning pic_pic into d_pic。beginselect pic_pic into r_pic from gz_data_pic where pic_id=v_picid。loopfetch c_pic into v_picid。cursor c_pic is select pic_id from gz_data_pic where pic_id=fid and pic_id=tid order by pic_id。r_pic blob。)。,39。你能找到 blob 對(duì)應(yīng)的 rowid 嗎？如果能找到就應(yīng)該有可能找到對(duì)應(yīng)的 row 的 rowid 目前不清楚oracle是否有包來(lái)解決這個(gè)問(wèn)題但是通過(guò) dump block 是有可能發(fā)現(xiàn)的 DUL 工具也應(yīng)該可能取出完好部分?jǐn)?shù)據(jù)execute (39。我發(fā)現(xiàn)表的數(shù)據(jù)的rowid和blob字段的rowid是不同的，但又不知道BLOB字段的ROWID和表數(shù)據(jù)的關(guān)系。用dbverify查到4個(gè)datafile共有5個(gè)壞快。10231 trace name context forever,level 1039。共有10萬(wàn)多條記錄 17G多數(shù)據(jù)空間，試過(guò)dbms_repair,但是dbms_repair找不到錯(cuò)誤的記錄。要遷移的目標(biāo)系統(tǒng)是sun v480 dual 900M, 4G mem, scsi3 diskarray 4X73G raid5, solaris 9, oracle ,rose ha　　這些壞快猜測(cè)至少在300記錄左右。select * from corrupt_lobs。 end loop。 mit。 mit。 mit。))。 begin for cursor_lob in (select rowid r, PLATEPICT from ep_table ) loop begin n:=(,hextoraw(39。 pragma exception_init(error_22922,22922)。 pragma exception_init(error_1578,1578)。error_1555 exception。 關(guān)閉會(huì)話期間的數(shù)據(jù)塊檢查。COUNT(*)8036完成數(shù)據(jù)恢復(fù).損失的行數(shù)可以從2個(gè)行數(shù)相減計(jì)算：8192 8036 = 156 行數(shù)據(jù)，做以下操作：1. 如果你在初始化參數(shù)中設(shè)置的注釋之2. 如果在命令行設(shè)置的alter session set events 39。E:\imp system/admin file= tables=t. 正在將system的對(duì)象導(dǎo)入到 system. . 正在導(dǎo)入表 T 8036行被導(dǎo)入成功終止導(dǎo)入，但出現(xiàn)警告。SQL drop table t。然后我們可以導(dǎo)出未損壞的數(shù)據(jù)E:\ exp system/admin file= tables=t即將導(dǎo)出指定的表通過(guò)常規(guī)路徑 .... . 正在導(dǎo)出表 T 8036 行被導(dǎo)出在沒有警告的情況下成功終止導(dǎo)出。10231 trace name context forever,level 1039。首先你需要檢查損壞的對(duì)象，使用以下SQL：/* Formatted on 20091217 14:00:42 (QP5 ) */SELECT tablespace_name, segment_type, owner, segment_nameFROM dba_extentsWHERE file_id = 4 AND 35 BETWEEN block_id AND block_id + blocks 1。導(dǎo)出成功終止，但出現(xiàn)警告。八． 設(shè)置內(nèi)部事件使exp跳過(guò)壞塊我們可以用設(shè)置event的方法來(lái)處理壞塊：先模擬出壞塊，然后用dbv檢查，此時(shí)，不用dbms_repair，而用下面的方法：. 先exp該表試驗(yàn)一下在這種情況下，如果有備份，需要從備份中恢復(fù)，如果沒有備份，那么壞塊部分的數(shù)據(jù)肯定要丟失了在這個(gè)時(shí)候?qū)С鍪遣辉试S的:E:\exp system/admin file= tables=t報(bào)錯(cuò)如下：即將導(dǎo)出指定的表通過(guò)常規(guī)路徑 .... . 正在導(dǎo)出表 TEXP00056: 遇到 ORACLE 錯(cuò)誤 1578ORA01578: ORACLE 數(shù)據(jù)塊損壞（文件號(hào)4，塊號(hào)35）ORA01110: 數(shù)據(jù)文件 4: 39。DMM39。SYS39。通過(guò)以下命令可以知道丟失行的信息：SQL SELECT * FROM ORPHAN_TABLE。, key_count = CC)。, orphan_table_name = 39。, object_type = 2, repair_table_name = 39。, object_name = 39。BEGIN (schema_name = 39。COUNT(*) 12850丟失了12896－12850＝46行數(shù)據(jù)。,flags = 1)。,object_name = 39。 這里需要用skip_corrupt_blocks來(lái)跳過(guò)壞塊：/* Formatted on 20091217 13:30:17 (QP5 ) */exec (schema_name = 39。D: \39。：我們前面雖然定位了壞塊，但是，如果我們?cè)L問(wèn)table：SQL select count(*) from 。 (a = TO_CHAR (cc))。DMM39。SYS39。 /* Formatted on 20091217 13:29:01 (QP5 ) */DECLARE cc NUMBER。所以可以直接進(jìn)行第四步了。
注意：在8i下，check_object只會(huì)檢查壞塊，MARKED_CORRUPT為false，故需要執(zhí)行第三步： 定位壞塊，fix_corrupt_blocks定位 ，修改MARKED_CORRUPT為true，同時(shí)更新CHECK_TIMESTAMP。END。, corrupt_count = cc)。, 注意此處是用戶名 object_name = 39。BEGIN (schema_name = 39。PL/SQL procedure successfully pletedSQL DESC ORPHAN_TABLE Name Null? Type SCHEMA_NAME NOT NULL VARCHAR2(30) INDEX_NAME NOT NULL VARCHAR2(30) IPART_NAME VARCHAR2(30) INDEX_ID NOT NULL NUMBER TABLE_NAME NOT NULL VARCHAR2(30) PART_NAME VARCHAR2(30) TABLE_ID NOT NULL NUMBER KEYROWID NOT NULL ROWID KEY NOT NULL ROWID DUMP_TIMESTAMP NOT NULL DATE：/* Formatted on 20091216 23:41:32 (QP5 ) */Set serveroutput on。USERS39。ORPHAN_TABLE39。)。,1,1,39。SQL exec (39。COUNT(*)12896：SQL conn sys/admin as sysdba。CREATE INDEX indx_dmm on DMM(TABLE_NAME)。create table DMM tablespace block as select * from all_tables。/u01/39。dbms_repair是從oracle8i開始提供的。)=13and (rowid)=162。,39。. 根據(jù)壞塊的file_id,owner,segment_name,block_id,如果是數(shù)據(jù)表的話，用下面的查詢來(lái)得到對(duì)應(yīng)壞塊的rowid假設(shè)owner : DAVE segment_name: BL file_id : 13 block_id : 162運(yùn)行下面的查詢來(lái)獲得該塊所含的rowid(如果沒有索引，可能就不能用下面的方式了):select /*+ index(DAVE, i_test) */ rowidfrom where (rowid,39。. 首先肯定知道那個(gè)數(shù)據(jù)文件壞了，查出該文件的file_id,relative_fno,tablespace_name利用dba_data_files可以查詢file_id(整個(gè)數(shù)據(jù)庫(kù)唯一序號(hào)),RELATIVE_FNO(相對(duì)一個(gè)表空間內(nèi)的序號(hào)). 找到壞塊的ID（可以運(yùn)行dbverify實(shí)現(xiàn)），假設(shè)找到的壞塊ID為1234。塊中的每一行在行目錄中都有一個(gè)位置。列值在緊