使用blockrecover 對有壞塊的資料檔案進行恢復
1.建立測試表
SQL> create tablespace tb1 datafile 'E:\oracle\product\10.2.0\oradata\orcl\tb101.dbf' size 5m;
表空間已建立。
SQL> create table tb1 tablespace tb1 as select * from t_t1;
表已建立。
SQL> select count(*)from tb1;
COUNT(*)
----------
40741
2.rman全庫備份
RMAN> backup as compressed backupset database format 'C:\oracle\%U';
啟動 backup 於 13-12月-14
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 啟動壓縮的全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
輸入資料檔案 fno=00001 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
輸入資料檔案 fno=00003 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
輸入資料檔案 fno=00004 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
輸入資料檔案 fno=00005 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST01.DBF
輸入資料檔案 fno=00002 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
輸入資料檔案 fno=00007 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST_UNIFORM01.DBF
輸入資料檔案 fno=00008 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS02.DBF
輸入資料檔案 fno=00009 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB01.DBF
輸入資料檔案 fno=00011 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF
輸入資料檔案 fno=00010 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\MY_UNDO01.DBF
通道 ORA_DISK_1: 正在啟動段 1 於 13-12月-14
通道 ORA_DISK_1: 已完成段 1 於 13-12月-14
段控制程式碼=C:\ORACLE\06PQ2J9L_1_1 標記=TAG20141213T133756 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:55
通道 ORA_DISK_1: 啟動壓縮的全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
備份集中包括當前控制檔案
在備份集中包含當前的 SPFILE
通道 ORA_DISK_1: 正在啟動段 1 於 13-12月-14
通道 ORA_DISK_1: 已完成段 1 於 13-12月-14
段控制程式碼=C:\ORACLE\07PQ2JBC_1_1 標記=TAG20141213T133756 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:01
完成 backup 於 13-12月-14
3.關閉資料庫，模擬資料塊損壞
SQL> shutdown immediate;
資料庫已經關閉。
已經解除安裝資料庫。
ORACLE 例程已經關閉。
用flexhex損壞資料檔案
4.開啟資料庫
SQL> startup
ORACLE 例程已經啟動。
Total System Global Area 167772160 bytes
Fixed Size 1247900 bytes
Variable Size 104858980 bytes
Database Buffers 58720256 bytes
Redo Buffers 2945024 bytes
資料庫裝載完畢。
資料庫已經開啟。
資料庫正常能開啟,查詢時出現塊損壞
SQL> select count(*)from tb1;
select count(*)from tb1
*
第 1 行出現錯誤:
ORA-01578: ORACLE 資料塊損壞 (檔案號 11, 塊號 71)
ORA-01110: 資料檔案 11: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF'
5.使用dbv對資料檔案做檢測
E:\oracle\product\10.2.0\oradata\orcl>dbv file=tb101.dbf blocksize=8192
DBVERIFY: Release 10.2.0.1.0 - Production on 星期六 12月 13 14:12:41 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - 開始驗證: FILE = tb101.dbf
頁 71 標記為損壞
Corrupt block relative dba: 0x02c00047 (file 11, block 71)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x02c00047
last change scn: 0x0000.00178a9c seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x8a9c0601
check value in block header: 0x921
computed block checksum: 0x59
DBVERIFY - 驗證完成
檢查的頁總數: 640
處理的頁總數 (資料): 62
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 15
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 562
標記為損壞的總頁數: 1
流入的頁總數: 0
最高塊 SCN : 1542814 (0.1542814)
有1個塊損壞,71
6.對資料庫中的壞塊進行驗證
SQL> select * from v$database_block_corruption;
未選定行
RMAN> backup validate database;
啟動 backup 於 13-12月-14
使用目標資料庫控制檔案替代恢復目錄
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=142 devtype=DISK
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
輸入資料檔案 fno=00001 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
輸入資料檔案 fno=00003 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
輸入資料檔案 fno=00004 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
輸入資料檔案 fno=00005 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST01.DBF
輸入資料檔案 fno=00002 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
輸入資料檔案 fno=00007 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST_UNIFORM01.DBF
輸入資料檔案 fno=00008 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS02.DBF
輸入資料檔案 fno=00009 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB01.DBF
輸入資料檔案 fno=00011 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF
輸入資料檔案 fno=00010 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\MY_UNDO01.DBF
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:35
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
備份集中包括當前控制檔案
在備份集中包含當前的 SPFILE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:02
完成 backup 於 13-12月-14
剛才那些壞塊都被列入到了檢視V$DATABASE_BLOCK_CORRUPTION中。
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
11 71 1 0 CHECKSUM
7.使用blockrecover恢復
RMAN> blockrecover datafile 11 block 71;
啟動 blockrecover 於 13-12月-14
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在恢復塊
通道 ORA_DISK_1: 正在指定要從備份集恢復的塊
正在恢復資料檔案 00011 的塊
通道 ORA_DISK_1: 正在讀取備份段 C:\ORACLE\06PQ2J9L_1_1
通道 ORA_DISK_1: 已從備份段 1 恢復塊
段控制程式碼 = C:\ORACLE\06PQ2J9L_1_1 標記 = TAG20141213T133756
通道 ORA_DISK_1: 塊恢復完成, 用時: 00:00:04
正在開始介質的恢復
介質恢復完成, 用時: 00:00:07
完成 blockrecover 於 13-12月-14
還可以透過RMAN> blockrecover corruption list進行塊的恢復，這是在大量塊損壞時或全部塊損壞時使用，
前提是先執行RMAN>backup validate database,在V$DATABASE_BLOCK_CORRUPTION裡有對應的壞塊的列表。
8.恢復完成後，進行驗證
E:\oracle\product\10.2.0\oradata\orcl>dbv file=tb101.dbf blocksize=8192
DBVERIFY: Release 10.2.0.1.0 - Production on 星期六 12月 13 14:23:05 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - 開始驗證: FILE = tb101.dbf
DBVERIFY - 驗證完成
檢查的頁總數: 640
處理的頁總數 (資料): 63
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 15
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 562
標記為損壞的總頁數: 0
流入的頁總數: 0
最高塊 SCN : 1542814 (0.1542814)
沒有顯示壞塊
SQL> select count(*)from tb1;
COUNT(*)
----------
40741
恢復成功
壞介質恢復優點：
?Lowers the Mean Time to Recovery (MTTR) because only blocks needing recovery are restored and only necessary corrupt blocks undergo recovery. Block media recovery minimizes redo application time and avoids I/O overhead during recovery.
?Allows affected datafiles to remain online during recovery of the blocks. Without block-level recovery, if even a single block is corrupt, then you must restore a backup of the entire datafile and apply all redo generated for that file after the backup was created.
壞介質恢復要求：
?You can only perform block media recovery with RMAN. No SQL*Plus recovery interface is available.
?You can only perform complete recovery of individual blocks. In other words, you cannot stop recovery before all redo has been applied to the block.
?You can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file were marked corrupt since the most recent BACKUP or BACKUP ... VALIDATE command was run against the file.
?You must have a full RMAN backup. Incremental backups are not used by block media recovery. Proxy backups are also not used by block media recovery. Only full backups and archived log files are used.
?Block media recovery is able to restore blocks from parent incarnation backups and recover the corrupted blocks through a RESETLOGS.
?Blocks that are marked media corrupt are not accessible to users until recovery is complete. Any attempt to use a block undergoing media recovery results in an error message indicating that the block is media corrupt.
SQL> create tablespace tb1 datafile 'E:\oracle\product\10.2.0\oradata\orcl\tb101.dbf' size 5m;
表空間已建立。
SQL> create table tb1 tablespace tb1 as select * from t_t1;
表已建立。
SQL> select count(*)from tb1;
COUNT(*)
----------
40741
2.rman全庫備份
RMAN> backup as compressed backupset database format 'C:\oracle\%U';
啟動 backup 於 13-12月-14
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 啟動壓縮的全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
輸入資料檔案 fno=00001 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
輸入資料檔案 fno=00003 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
輸入資料檔案 fno=00004 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
輸入資料檔案 fno=00005 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST01.DBF
輸入資料檔案 fno=00002 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
輸入資料檔案 fno=00007 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST_UNIFORM01.DBF
輸入資料檔案 fno=00008 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS02.DBF
輸入資料檔案 fno=00009 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB01.DBF
輸入資料檔案 fno=00011 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF
輸入資料檔案 fno=00010 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\MY_UNDO01.DBF
通道 ORA_DISK_1: 正在啟動段 1 於 13-12月-14
通道 ORA_DISK_1: 已完成段 1 於 13-12月-14
段控制程式碼=C:\ORACLE\06PQ2J9L_1_1 標記=TAG20141213T133756 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:55
通道 ORA_DISK_1: 啟動壓縮的全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
備份集中包括當前控制檔案
在備份集中包含當前的 SPFILE
通道 ORA_DISK_1: 正在啟動段 1 於 13-12月-14
通道 ORA_DISK_1: 已完成段 1 於 13-12月-14
段控制程式碼=C:\ORACLE\07PQ2JBC_1_1 標記=TAG20141213T133756 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:01
完成 backup 於 13-12月-14
3.關閉資料庫，模擬資料塊損壞
SQL> shutdown immediate;
資料庫已經關閉。
已經解除安裝資料庫。
ORACLE 例程已經關閉。
用flexhex損壞資料檔案
4.開啟資料庫
SQL> startup
ORACLE 例程已經啟動。
Total System Global Area 167772160 bytes
Fixed Size 1247900 bytes
Variable Size 104858980 bytes
Database Buffers 58720256 bytes
Redo Buffers 2945024 bytes
資料庫裝載完畢。
資料庫已經開啟。
資料庫正常能開啟,查詢時出現塊損壞
SQL> select count(*)from tb1;
select count(*)from tb1
*
第 1 行出現錯誤:
ORA-01578: ORACLE 資料塊損壞 (檔案號 11, 塊號 71)
ORA-01110: 資料檔案 11: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF'
5.使用dbv對資料檔案做檢測
E:\oracle\product\10.2.0\oradata\orcl>dbv file=tb101.dbf blocksize=8192
DBVERIFY: Release 10.2.0.1.0 - Production on 星期六 12月 13 14:12:41 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - 開始驗證: FILE = tb101.dbf
頁 71 標記為損壞
Corrupt block relative dba: 0x02c00047 (file 11, block 71)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x02c00047
last change scn: 0x0000.00178a9c seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x8a9c0601
check value in block header: 0x921
computed block checksum: 0x59
DBVERIFY - 驗證完成
檢查的頁總數: 640
處理的頁總數 (資料): 62
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 15
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 562
標記為損壞的總頁數: 1
流入的頁總數: 0
最高塊 SCN : 1542814 (0.1542814)
有1個塊損壞,71
6.對資料庫中的壞塊進行驗證
SQL> select * from v$database_block_corruption;
未選定行
RMAN> backup validate database;
啟動 backup 於 13-12月-14
使用目標資料庫控制檔案替代恢復目錄
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=142 devtype=DISK
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
輸入資料檔案 fno=00001 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
輸入資料檔案 fno=00003 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
輸入資料檔案 fno=00004 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
輸入資料檔案 fno=00005 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST01.DBF
輸入資料檔案 fno=00002 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
輸入資料檔案 fno=00007 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST_UNIFORM01.DBF
輸入資料檔案 fno=00008 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS02.DBF
輸入資料檔案 fno=00009 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB01.DBF
輸入資料檔案 fno=00011 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TB101.DBF
輸入資料檔案 fno=00010 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\MY_UNDO01.DBF
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:35
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
備份集中包括當前控制檔案
在備份集中包含當前的 SPFILE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:02
完成 backup 於 13-12月-14
剛才那些壞塊都被列入到了檢視V$DATABASE_BLOCK_CORRUPTION中。
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
11 71 1 0 CHECKSUM
7.使用blockrecover恢復
RMAN> blockrecover datafile 11 block 71;
啟動 blockrecover 於 13-12月-14
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在恢復塊
通道 ORA_DISK_1: 正在指定要從備份集恢復的塊
正在恢復資料檔案 00011 的塊
通道 ORA_DISK_1: 正在讀取備份段 C:\ORACLE\06PQ2J9L_1_1
通道 ORA_DISK_1: 已從備份段 1 恢復塊
段控制程式碼 = C:\ORACLE\06PQ2J9L_1_1 標記 = TAG20141213T133756
通道 ORA_DISK_1: 塊恢復完成, 用時: 00:00:04
正在開始介質的恢復
介質恢復完成, 用時: 00:00:07
完成 blockrecover 於 13-12月-14
還可以透過RMAN> blockrecover corruption list進行塊的恢復，這是在大量塊損壞時或全部塊損壞時使用，
前提是先執行RMAN>backup validate database,在V$DATABASE_BLOCK_CORRUPTION裡有對應的壞塊的列表。
8.恢復完成後，進行驗證
E:\oracle\product\10.2.0\oradata\orcl>dbv file=tb101.dbf blocksize=8192
DBVERIFY: Release 10.2.0.1.0 - Production on 星期六 12月 13 14:23:05 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - 開始驗證: FILE = tb101.dbf
DBVERIFY - 驗證完成
檢查的頁總數: 640
處理的頁總數 (資料): 63
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 15
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 562
標記為損壞的總頁數: 0
流入的頁總數: 0
最高塊 SCN : 1542814 (0.1542814)
沒有顯示壞塊
SQL> select count(*)from tb1;
COUNT(*)
----------
40741
恢復成功
壞介質恢復優點：
?Lowers the Mean Time to Recovery (MTTR) because only blocks needing recovery are restored and only necessary corrupt blocks undergo recovery. Block media recovery minimizes redo application time and avoids I/O overhead during recovery.
?Allows affected datafiles to remain online during recovery of the blocks. Without block-level recovery, if even a single block is corrupt, then you must restore a backup of the entire datafile and apply all redo generated for that file after the backup was created.
壞介質恢復要求：
?You can only perform block media recovery with RMAN. No SQL*Plus recovery interface is available.
?You can only perform complete recovery of individual blocks. In other words, you cannot stop recovery before all redo has been applied to the block.
?You can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file were marked corrupt since the most recent BACKUP or BACKUP ... VALIDATE command was run against the file.
?You must have a full RMAN backup. Incremental backups are not used by block media recovery. Proxy backups are also not used by block media recovery. Only full backups and archived log files are used.
?Block media recovery is able to restore blocks from parent incarnation backups and recover the corrupted blocks through a RESETLOGS.
?Blocks that are marked media corrupt are not accessible to users until recovery is complete. Any attempt to use a block undergoing media recovery results in an error message indicating that the block is media corrupt.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28841119/viewspace-1629895/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- DM7使用DMRAMN對多次故障恢復後使用不同資料庫的歸檔進行恢復資料庫
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- 學習這篇Oracle資料庫檔案壞塊損壞的恢復方法,擴充你的知識面Oracle資料庫
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料
- 【RMAN】如果控制檔案損壞那麼如何恢復？恢復控制檔案的方式有哪幾種？
- RMAN備份恢復典型案例——資料檔案存在壞快
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- Oracle 之利用BBED修改資料塊SCN----沒有備份資料檔案的資料恢復Oracle資料恢復
- PostgreSQL 恢復大法 - 恢復部分資料庫、跳過壞塊、修復無法啟動的資料庫SQL資料庫
- PostgreSQL DBA(30) - Backup&Recovery#3(資料檔案損壞恢復)SQL
- 【北亞資料恢復】伺服器raid陣列癱瘓導致ZFS檔案系統元檔案損壞的資料恢復資料恢復伺服器AI陣列
- 歸檔路徑更改後，如何對資料庫進行恢復(轉)資料庫
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 因壞道問題導致的硬碟故障如何進行資料恢復？硬碟資料恢復
- 資料底層損壞的恢復方法—拼碎片恢復資料
- 【伺服器資料恢復】ZFS檔案系統下RAIDZ多塊硬碟離線的資料恢復案例伺服器資料恢復AI硬碟
- 資料恢復工具Recoverit使用教程:如何修復損壞的影片資料恢復
- 【北亞資料恢復】硬碟壞道故障如何恢復資料？資料恢復硬碟
- system資料檔案頭損壞修復
- 【伺服器資料恢復】Ext4檔案系統執行fsck後檔案掛載報錯的資料恢復伺服器資料恢復
- InterBase資料庫檔案損壞的修復方法資料庫
- 電腦進水導致硬碟損壞資料恢復硬碟資料恢復
- oracle 普通表空間資料檔案壞塊Oracle
- 資料恢復新姿勢——通過ibd和frm檔案恢復資料資料恢復
- 【伺服器資料恢復】StorNext檔案系統資料恢復案例伺服器資料恢復
- 【資料庫資料恢復】Sql Server資料庫檔案丟失的資料恢復過程資料庫資料恢復SQLServer
- 【伺服器資料恢復】raid5崩潰導致lvm資訊和VXFS檔案系統損壞的資料恢復案例伺服器資料恢復AILVM
- 與控制檔案有關的恢復
- 【伺服器資料恢復】SAN LUN對映出錯導致檔案系統資料丟失的資料恢復案例伺服器資料恢復
- Mysql 誤刪資料進行恢復MySql
- 【北亞資料恢復】MongoDB資料遷移檔案丟失的MongoDB資料恢復案例資料恢復MongoDB
- 【資料庫資料恢復】mdb_catalog.wt檔案丟失的MongoDB資料恢復案例資料庫資料恢復MongoDB
- 【伺服器資料恢復】xfs檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 資料庫資料恢復-SQL SERVER資料庫檔案大小變為“0”的資料恢復方案資料庫資料恢復SQLServer