[20171115]恢復資料檔案塊頭4補充.txt
[20171115]恢復資料檔案塊頭4補充.txt
--// 昨天做了恢復資料檔案塊頭,透過備份檔案直接取出檔案塊頭,覆蓋原來的資料塊,然後修復.
--//補充幾點:
--1.檔案頭損壞,無法使用rman的塊恢復功能.
--2.檔案頭損壞,dbv檢查發現都是壞塊.我感覺主要檔案塊頭損壞,dbv無法定位其它剩下的塊.
1.環境:
SCOTT@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2.建立測試環境:
CREATE TABLESPACE TEA DATAFILE
'/mnt/ramdisk/book/tea01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table t1 tablespace tea as select rownum id ,lpad('A',32,'A') name from dual connect by level<=1e5;
--//建立rman備份:
backup database filesperset=1 format '/home/oracle/backup/20171114_%U';
--//注:這是我個人主張的備份方式設定filesperset=1,可惜我們團隊一直不建議使用.這樣備份檔案顯得太多了.實際上這樣做與我後面的恢復有關.
create table t2 tablespace tea as select rownum id ,lpad('B',32,'B') name from dual connect by level<=1e5;
--//建立大小5M的表。注:說明一點,我是先做資料庫備份,再建立t2表.
--//破壞資料檔案頭,注:資料檔案頭在資料檔案的第2塊.第1塊OS頭.
update t2 set name=lpad('C',32,'C') where id <=5;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
rollback ;
update t2 set name=lpad('D',32,'D') where id between 5 and 9;
commit ;
alter database datafile 6 offline ;
$ dd if=/dev/zero of=/mnt/ramdisk/book/tea01.dbf count=1 bs=8192 conv=notrunc seek=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 3.8338e-05 seconds, 214 MB/s
2. 昨天測試發現檔案頭是最後備份的.
RMAN> list backupset 206;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
206 Full 5.69M DISK 00:00:00 2017-11-14 15:09:38
BP Key: 207 Status: AVAILABLE Compressed: NO Tag: TAG20171114T150933
Piece Name: /home/oracle/backup/20171114_fcsji7ti_1_1
List of Datafiles in backup set 206
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
6 Full 13278016603 2017-11-14 15:09:38 /mnt/ramdisk/book/tea01.dbf
--//確定備份片檔案是/home/oracle/backup/20171114_fcsji7ti_1_1.
--//我的資料庫名=BOOK.
$ strings -t d /home/oracle/backup/20171114_fcsji7ti_1_1 | grep BOOK
8223 OBOOK
5955615 OBOOK
--//8223/8192=1.0037841796875
--//5955615/8192=727.0037841796875
--//可以確定包含BOOK在備份檔案集的第1塊,第727塊.
BBED> set filename '/home/oracle/backup/20171114_fcsji7ti_1_1'
FILENAME /home/oracle/backup/20171114_fcsji7ti_1_1
BBED> set block 1
BLOCK# 1
BBED> map /v
File: /home/oracle/backup/20171114_fcsji7ti_1_1 (100)
Block: 1 Dba:0x19000001
------------------------------------------------------------
BBED-00400: invalid blocktype (19)
BBED> map
File: /home/oracle/backup/20171114_fcsji7ti_1_1 (100)
Block: 727 Dba:0x190002d7
------------------------------------------------------------
Data File Header
struct kcvfh, 860 bytes @0
ub4 tailchk @8188
--//可以確定檔案頭備份在727塊中.從這裡還可以看出檔案頭實際上最後寫入備份檔案集中的.
$ ls -l /home/oracle/backup/20171114_fcsji7ti_1_1
-rw-r----- 1 oracle oinstall 5971968 2017-11-14 15:09:38 /home/oracle/backup/20171114_fcsji7ti_1_1
--// 備份檔案佔 5971968/8192=729塊(從0開始記數,最大728).基本上倒數第2塊就是檔案頭的備份.(注:對於filesperset=1的備份集)
3.換一句話講如果restore恢復,是否是最後寫入檔案頭(對於備份集合,估計copy的方式不是這樣).
--//還是做測試驗證我這個判斷是否正確.
SYS@book> startup mount ;
ORACLE instance started.
Total System Global Area 634732544 bytes
Fixed Size 2255792 bytes
Variable Size 197133392 bytes
Database Buffers 427819008 bytes
Redo Buffers 7524352 bytes
Database mounted.
--//選擇恢復資料檔案2,主要tea01.dbf太小了.估計測不出來.
$ mv sysaux01.dbf sysaux01.dbf_x
--//建立指令碼如下:
$ cat dump_head.sh
#! /bin/bash
for i in $(seq 1000)
do
# echo $i
xxd -c16 -g 2 -s 8192 -l 16 /mnt/ramdisk/book/sysaux01.dbf >> /tmp/sysaux_head.txt 2>/dev/null
sleep 0.1
done
--//首先啟動dump_tea_head.sh指令碼,session 1:
$ . dump_tea_head.sh &
--//啟動恢復,session 2:
RMAN> restore datafile 2;
Starting restore at 2017-11-15 11:38:52
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=300 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=14 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /mnt/ramdisk/book/sysaux01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/20171114_f8sji7te_1_1
channel ORA_DISK_1: piece handle=/home/oracle/backup/20171114_f8sji7te_1_1 tag=TAG20171114T150933
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2017-11-15 11:38:54
--//1秒完成恢復. 資料檔案2的備份集是/home/oracle/backup/20171114_f8sji7te_1_1
$ fg
. dump_head.sh
^C
$ head -10 /tmp/sysaux_head.txt
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105 ................
~~~~ ~~~~
0002000: 0ba2 0000 0100 8000 0000 0000 0000 0104 ................
0002000: 0ba2 0000 0100 8000 0000 0000 0000 0104 ................
....
--//注意看下劃線部分.
--//完成後透過bbed觀察
BBED> p dba 2,1 kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes @0
ub1 type_kcbh @0 0x0b
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x00800001
ub4 bas_kcbh @8 0x00000000
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x04 (KCBHFCKV)
ub2 chkval_kcbh @16 0xbac4
ub2 spare3_kcbh @18 0x0000
--//檢查備份集的備份的檔案頭:
BBED> dump /v FILENAME '/home/oracle/backup/20171114_f9sji7te_1_1' block 82951 count 16 offset 0
File: /home/oracle/backup/20171114_f9sji7te_1_1 (202)
Block: 82951 Offsets: 0 to 15 Dba:0x32814407
-----------------------------------------------------------------------------------------------------------
0ba20000 87004000 00000000 00000104 l ......@.........
<32 bytes per line>
BBED> dump /v dba 2,1 count 16 offset 0
File: /mnt/ramdisk/book/sysaux01.dbf (2)
Block: 1 Offsets: 0 to 15 Dba:0x00800001
-----------------------------------------------------------------------------------------------------------
0ba20000 01008000 00000000 00000104 l ................
<32 bytes per line>
--//很明顯我的判斷還是正確的,我覺得前面應該是"構造"出來的,寫錯檔案頭的開頭部分kcvfhbfh.type_kcbh=00.最後在寫入
--//正確的檔案頭.
--//我的第一感覺oracle這樣設計有它一定道理.因為沒有正確寫入檔案頭,dbv檢查報壞塊.這個資料檔案是"無用".
--//另外一個原因就是假設restore時發生中斷,而這個時候檔案頭已經前期正常寫入,很可能可以online該資料檔案.
--//當然這些都是我個人的猜測,也許不對...^_^.
--// 修改為00看看.
BBED> assign dba 2,1 kcvfh.kcvfhbfh.type_kcbh=0x00
BBED-00217: unable to assign: (0) is out of range (1, 74)
BBED> set dba 2,1
DBA 0x00800001 (8388609 2,1)
BBED> help assign
ASSIGN[/x|d|u|o] <target spec>=<source spec>
<target spec> : [ DBA | FILE | FILENAME | BLOCK | OFFSET | symbol | *symbol ]
<source spec> : [ value | <target spec options> ]
BBED> assign kcvfh.kcvfhbfh.type_kcbh=0x00
BBED-00217: unable to assign: (0) is out of range (1, 74)
--//無法這樣修改
BBED> assign dba 2,1 kcvfh.kcvfhbfh.type_kcbh=0x0b
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 type_kcbh @0 0x0b
--//說明assign語法沒有問題.
BBED> modify /x 00 dba 2,1
File: /mnt/ramdisk/book/sysaux01.dbf (2)
Block: 1 Offsets: 0 to 15 Dba:0x00800001
------------------------------------------------------------------------------------------------------------------------------------------------
00a20000 01008000 00000000 00000104
<64 bytes per line>
BBED> sum apply dba 2,1;
Check value for File 2, Block 1:
current = 0xbacf, required = 0xbacf
$ dbv file=/mnt/ramdisk/book/sysaux01.dbf
DBVERIFY: Release 11.2.0.4.0 - Production on Wed Nov 15 15:12:39 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /mnt/ramdisk/book/sysaux01.dbf
Page 1 is influx - most likely media corrupt
Corrupt block relative dba: 0x00800001 (file 2, block 1)
Fractured block found during dbv:
Data in bad block:
type: 0 format: 2 rdba: 0x00800001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000b01
check value in block header: 0xbacf
computed block checksum: 0x0
--//收尾
RMAN> recover datafile 2,6;
Starting recover at 2017-11-15 15:15:10
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
starting media recovery
archived log for thread 1 with sequence 917 is already on disk as file /u01/app/oracle/archivelog/book/1_917_896605872.dbf
archived log for thread 1 with sequence 918 is already on disk as file /u01/app/oracle/archivelog/book/1_918_896605872.dbf
archived log for thread 1 with sequence 919 is already on disk as file /u01/app/oracle/archivelog/book/1_919_896605872.dbf
archived log for thread 1 with sequence 920 is already on disk as file /u01/app/oracle/archivelog/book/1_920_896605872.dbf
archived log for thread 1 with sequence 921 is already on disk as file /u01/app/oracle/archivelog/book/1_921_896605872.dbf
archived log file name=/u01/app/oracle/archivelog/book/1_917_896605872.dbf thread=1 sequence=917
archived log file name=/u01/app/oracle/archivelog/book/1_918_896605872.dbf thread=1 sequence=918
archived log file name=/u01/app/oracle/archivelog/book/1_919_896605872.dbf thread=1 sequence=919
media recovery complete, elapsed time: 00:00:01
Finished recover at 2017-11-15 15:15:11
RMAN> sql 'alter database open ';
sql statement: alter database open
--//補充修改kcvfh.kcvfh.kcvfhbfh=0x5的情況:
SYS@book> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
BBED> set dba 2,1
DBA 0x00800001 (8388609 2,1)
BBED> assign kcvfh.kcvfhbfh.flg_kcbh=0x05
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 flg_kcbh @15 0x05 (KCBHFNEW, KCBHFCKV)
BBED> assign kcvfh.kcvfhbfh
BBED-00216: unable to assign: type mismatch between (kcvfhbfh, flg_kcbh)
BBED> p kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes @0
ub1 type_kcbh @0 0x0b
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x00800001
ub4 bas_kcbh @8 0x00000000
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x05 (KCBHFNEW, KCBHFCKV)
~~~~~~~~
ub2 chkval_kcbh @16 0xcd44
ub2 spare3_kcbh @18 0x0000
BBED> assign kcvfh.kcvfhbfh.flg_kcbh=0x04
ub1 flg_kcbh @15 0x04 (KCBHFCKV)
BBED> p kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes @0
ub1 type_kcbh @0 0x0b
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x00800001
ub4 bas_kcbh @8 0x00000000
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x04 (KCBHFCKV)
ub2 chkval_kcbh @16 0xcd44
ub2 spare3_kcbh @18 0x0000
--//感覺KCBHFNEW 表示新塊.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2147297/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20171115]恢復資料檔案塊頭3補充.txt
- [20171122]恢復資料檔案塊頭5.txt
- [20171114]恢復資料檔案塊頭2.txt
- rman恢復資料檔案-----塊折斷
- [20160407]bbed修改檔案頭2(補充).txt
- 恢復資料,資料塊恢復
- 【BBED】 SYSTEM檔案頭損壞的恢復(4)
- 資料檔案壞塊的製造和恢復
- bbed 與檔案頭恢復
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 資料恢復-電腦管家檔案恢復工具資料恢復
- rman恢復資料檔案 恢復表空間
- 恢復之重建資料檔案
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- RMAN恢復案例:無恢復目錄，丟失全部資料檔案、控制檔案、日誌檔案恢復
- rman 恢復資料塊
- rman恢復資料塊
- RMAN恢復案例:丟失全部資料檔案恢復
- 使用blockrecover 對有壞塊的資料檔案進行恢復BloC
- 【伺服器資料恢復】Ext4檔案系統執行fsck後檔案掛載報錯的資料恢復伺服器資料恢復
- 資料檔案誤刪--但有資料檔案的copy恢復
- 恢復之還原資料檔案
- 資料檔案丟失的恢復
- [ORACLE ASM] AMDU 恢復資料檔案OracleASM
- 新增資料檔案與恢復cf
- Bak檔案恢復到資料庫資料庫
- 資料檔案丟失如何恢復
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- rman備份恢復-rman恢復資料檔案測試
- rman恢復時跳過資料檔案，進行恢復
- [20171225]沒有備份資料檔案的恢復.txt
- oracle實驗記錄 (恢復,備份-含壞塊資料檔案)Oracle
- 資料塊恢復例項
- 備份與恢復--重建控制檔案後資料檔案損壞的恢復
- 【伺服器資料恢復】ZFS檔案系統下RAIDZ多塊硬碟離線的資料恢復案例伺服器資料恢復AI硬碟
- 資料恢復新姿勢——通過ibd和frm檔案恢復資料資料恢復
- 恢復案例：歸檔模式下丟失全部資料檔案的恢復模式
- system資料檔案頭損壞修復