【正文】 靠列長度字節(jié)后面存儲。注：對于非尾隨的NULL 列，列長度需要占用一個字節(jié)。行的結構行數據作為長度可變的記錄存儲在數據庫塊中。即使Oracle8 通過使用與表空間相關的文件編號擺脫了這種限制，但受限ROWID 仍用在非分區(qū)表上的非分區(qū)索引之類的對象中，其中所有索引條目指的是同一段中的行。因此，較早的發(fā)行版不允許數據文件數超過1,022 個。受限的ROWID 在內部僅使用六個字節(jié)，不包含數據對象編號。共有64 個字符，如下例所示：SQL SELECT department_id, rowid FROM 。擴展的ROWID 使用以64 為基數的編碼方案來顯示，該方案將六個位置用于數據對象編號、三個位置用于相關文件編號、六個位置用于塊編號、三個位置用于行編號。BBED具體的使用，參考blog：五．如何查找壞塊所含的數據表名稱和數據的rowidrowid的結構ROWID 格式擴展的ROWID 在磁盤上需要10 個字節(jié)的存儲空間，并使用18 個字符來顯示。BBED在windows 8i中在$ORACLE_HOME/bin下可以找到，9i中似乎未隨軟件發(fā)布，故在windows沒有這個工具，linux下需要編譯，然后把$ORACLE_HOME/rdbms/lib加到環(huán)境變量的PATH里面，就可以直接在命令中bbed了。該命令執(zhí)行后即可恢復壞塊，并且不會造成數據丟失，但是要求數據庫必須要運行在歸檔模式下，否則RMAN無法發(fā)揮作用，而且通過RMAN做過最新的數據庫備份 使用bbed恢復使用bbed恢復時必須有數據文件的拷貝。檢查4號數據文件是否存在壞塊執(zhí)行查詢：select * from v$database_block_corruption where file=4。、使用DBMS_REPAIR恢復用DBMS_REPAIR當然也會丟失數據。10231 trace name context forever,level 1039。如果被損壞的塊是索引，通?？梢酝ㄟ^索引重建來解決，如果損壞的是數據（segment_type為table），那么通過設置如下內部事件使得Exp操作跳過壞塊。關于DBV 命令的具體使用，請參考blog： 沒有備份的情況下：、使用exp/imp恢復在這種情況下肯定會造成數據的丟失，在這種情況下應采取將數據導出然后重建表再進行導入的方法，來盡量恢復損壞數據塊中的數據，但是在有壞塊的情況下是不允許導出的，如下命令：Exp test/test file= tables=t。后臺進程,如DBWR，LGWR出現(xiàn)長時間異常等待，如“LGWR wait for redo copy”。Trace文件中出現(xiàn)Corrupt block dba: 0x160c5958 . found。報告Ora1110錯誤。同時，避免在數據庫主機運行其他用戶進程，避免異常停機，也會減少壞塊發(fā)生的幾率。但要注意的是，在線使用Recovery Manager掃描壞塊和備份時，需要數據庫運行在歸檔模式（archive log），否則只能在數據庫未打開的情況下進行。 利用exp工具導出整個數據庫可以檢測壞塊對以下情況的壞塊是檢測不出來的：HWM以上的壞塊是不會發(fā)現(xiàn)的索引中存在的壞塊是不會發(fā)現(xiàn)的數據字典中的壞塊是不會發(fā)現(xiàn)的結合數據庫性能綜合考慮db_block_checksum和db_blockchecking參數。 Dbv工具檢查注：因為dbv要求file后面跟的必須是一個文件擴展名，所以如果用裸設備存儲的，就必須使用ln鏈接裸設備到一個文件，然后再用dbv對這個鏈接文件進行檢查。在Recovery Manager界面中，使用：RMAN BACKUP CHECK LOGICAL VALIDATE DATAFILE n 。在文檔中，Oracle會提供相應的補丁或應對措施。 ，Oracle定期發(fā)布基于特定軟件版本的“已知問題(known issues)說明”。但當故障發(fā)生在生產系統(tǒng)上，我們?yōu)榱藴p少停機時間，會盡快實施應急權變措施以保證系統(tǒng)的可用性，這樣就破壞了故障現(xiàn)場，對根本原因的分析因而也更加困難了。注：這也是為什么突然斷電會導致數據庫無法啟動由上可見，壞塊的形成原因復雜。 非Oracle進程擾亂Oracle共享內存區(qū)域如上文所述，在當數據塊的內容被讀入主機的物理內存時，如果其他非Oracle進程，對Oracle使用的共享內存區(qū)域形成了擾亂，最終導致寫回磁盤的數據塊內容混亂。 操作系統(tǒng)BUG由于Oracle進程對數據塊的讀寫，都是以操作系統(tǒng)內核調用（system call）的方式完成的，如果操作系統(tǒng)在內核調用存在問題，必然導致Oracle進程寫入非法的內容。一．壞塊的產生原因壞塊產生的原因大致有以下幾種： 硬件問題Oracle進程在處理一個數據塊時，首先將其讀入物理內存空間，在處理完成后，再由特定進程將其寫回磁盤；如果在這個過程中，出現(xiàn)內存故障，CPU計算失誤，都會導致內存數據塊的內容混亂，最后反映到寫回磁盤的數據塊內容有誤。下面系統(tǒng)的總結一下壞塊故障的處理：數據庫出現(xiàn)壞塊現(xiàn)象是指：在Oracle數據庫的一個或多個數據塊內出現(xiàn)內容混亂的現(xiàn)象。5）使用至少已生成一周的備份來還原和恢復前一個備份操作發(fā)現(xiàn)受損的所有數據塊： RMAN blockrecover corruption list until time sysdate 7。3）從指定備份集中還原數據塊 RMAN blockrecover datafile 7 block 5 from backupset 1039?；謴蛪K的時候，必須指定具體的塊號，如：RMAN blockrecoverdatafile 6 block 3；具體請見 塊媒體恢復 Block Media Recovery （BMR）1）指示RMAN從文件的最新備份集或映像副本中還原與恢復一個指定的數據塊： RMAN blockrecover datafile 7 block 5。E：\39。RMAN通過 Block Media Recovery（簡稱 BMR）來執(zhí)行塊級恢復操作。 RMAN set maxcorrupt for datafile 1 to 10。奇怪了，只能猜硬盤壞的太厲害，產生了物理壞道。10231 trace name context forever,level 1039。特別注意：試過dbms_repair,但是dbms_repair找不到錯誤的記錄。找到壞塊所在記錄的時間段后exp時跳過。導出成功終止，但出現(xiàn)警告。即將導出指定的表通過常規(guī)路徑 .... . 正在導出表 EP_TABLEEXP00056: ORACLE 錯誤 1115 出現(xiàn)ORA01115: 從文件 8 讀取塊時出現(xiàn) IO 錯誤 (塊 1200338)ORA27070: skgfdisp: 異步讀取/寫入失敗OSD04016: 查詢非同步 I/O 請求發(fā)生錯誤.O/SError: (OS 23) 數據錯誤 (循環(huán)冗余檢查)。yyyymmdd HH24:MI:SS39。20091001 00:00:0039。yyyymmdd HH24:MI:SS39。20091026 20:48:5739?；謴屯陻祿旌笾貍鬟@段時間的記錄就行了！備份時只需把期間的數據備份出來就可以。)沒有報錯結論：1461833塊為 20091026 20:47:57到 20091026 20:48:57 之間。,39。) AND PTIME TO_DATE(39。,39。驗證了這個時間段區(qū)間內的數據有壞塊！Select count(*) from EP_PECC t where PTIME TO_DATE(39。E:\ORADATA\DZJC\39。2009112739。YYYYMMDD39。2009112539。YYYYMMDD39。而從obj,rfile,block,row計算得到理論上的rowid可能不存在。end。ROW_NUMBER: 39。||to_char(v_BLOCK_NUMBERE_FNO))。(39。RELATIVE_FNO: 39。||to_char(v_OBJECT_NUMBER))。(39。ROWID_TYPE: 39。,rowid_type = v_rowid_type,object_number = v_OBJECT_NUMBER,relative_fno = v_RELATIVE_FNO,block_number = v_BLOCK_NUMBERE_FNO,row_number = v_ROW_NUMBER)。begin(rowid_in = 39。v_BLOCK_NUMBERE_FNO number。v_OBJECT_NUMBER number。 AND (rowid) BETWEEN 1 AND 113。)=39。,39。 SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO1 SYS_LOB0000052738C00016$$ 0 7 113 65536 8 72 SYS_LOB0000052738C00016$$ 1 7 273 65536 8 73 SYS_LOB0000052738C00016$$ 2 7 281 65536 8 74 SYS_LOB0000052738C00016$$ 3 7 289 65536 8 75 SYS_LOB0000052738C00016$$ 4 7 297 65536 8 76 SYS_LOB0000052738C00016$$ 5 7 305 65536 8 77 SYS_LOB0000052738C00016$$ 6 7 313 65536 8 78 SYS_LOB0000052738C00016$$ 7 7 321 65536 8 79 SYS_LOB0000052738C00016$$ 8 7 329 65536 8 710 SYS_LOB0000052738C00016$$ 9 7 337 65536 8 711 SYS_LOB0000052738C00016$$ 10 7 345 65536 8 712 SYS_LOB0000052738C00016$$ 11 7 353 65536 8 713 SYS_LOB0000052738C00016$$ 12 7 361 65536 8 714 SYS_LOB0000052738C00016$$ 13 7 369 65536 8 715 SYS_LOB0000052738C00016$$ 14 7 377 65536 8 716 SYS_LOB0000052738C00016$$ 15 7 385 65536 8 717 SYS_LOB0000052738C00016$$ 16 6 9 1048576 128 618 SYS_LOB0000052738C00016$$ 17 7 393 1048576 128 719 SYS_LOB0000052738C00016$$ 18 6 137 1048576 128 620 SYS_LOB0000052738C00016$$ 19 7 521 1048576 128 721 SYS_LOB0000052738C00016$$ 20 6 265 1048576 128 622 SYS_LOB0000052738C00016$$ 21 7 649 1048576 128 723 SYS_LOB0000052738C00016$$ 22 6 393 1048576 128 624 SYS_LOB0000052738C00016$$ 23 7 777 1048576 128 725 SYS_LOB0000052738C00016$$ 24 6 521 1048576 128 6根據上一步查出來的BLOCK_ID一陣狂找，終于找到了select rowid, (rowid) obj_id, (rowid) df, (rowid) blknum, (rowid) rowno ,from ep_table T where (rowid,39。SYS_LOB0000052738C00016$$39。TEST39。 AND =顯示10MB檢查表建在那個數據文件那個塊上SELECT DISTINCT (rowid) AS File, (rowid) AS Block FROM ep_table。 AND =39。 and =1 T_LOG RZ SYS_LOB0000052726C00002$$ LOBSEGMENT 7 172 EP_TABLE PLATEPICT SYS_LOB0000052738C00016$$ LOBSEGMENT 7 1133 EP_TABLE PANORAMAPICT SYS_LOB0000052738C00017$$ LOBSEGMENT 7 1294 EP_TABLE THIRDPICT SYS_LOB0000052738C00018$$ LOBSEGMENT 7 1455 EP_PECC PLATEPICT SYS_LOB0000052746C00016$$ LOBSEGMENT 7 1776 EP_PECC PANORAMAPICT SYS_LOB0000052746C00017$$ LOBSEGMENT 7 1937 EP_PECC THIRDPICT SYS_LOB0000052746C00018$$ LOBSEGM