某個資料檔案損壞完全恢復(三)
三、環境:某個資料檔案損壞,有rman備份,具體恢復過程如下:
在這種恢復方式中,資料庫處於OPEN狀態,適合除了system和undo以外的普通資料檔案的恢復。
[oracle@dbserv ~]$ export ORACLE_SID=test
[oracle@dbserv ~]$ sqlplus / as sysdba
SQL> select count(*) from tt;
COUNT(*)
----------
56
SQL> insert into tt select * from dba_users;
8 rows created.
SQL> /
8 rows created.
SQL> commit;
Commit complete.
[@more@]SQL> shutdown abort;
ORACLE instance shut down.
SQL> host rm -f /opt/oracle/oradata/test/users01.dbf
SQL> startup
ORACLE instance started.
Total System Global Area 2147483648 bytes
Fixed Size 1220432 bytes
Variable Size 486539440 bytes
Database Buffers 1644167168 bytes
Redo Buffers 15556608 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/opt/oracle/oradata/test/users01.dbf'
--為了提高資料庫中其他資料的可用性,可以把損壞的資料檔案的狀態改為offline,這樣資料庫可以開啟:
SQL> alter database datafile '/opt/oracle/oradata/test/users01.dbf' offline;
Database altered.
SQL> alter database open;
Database altered.
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_
---------- ------- -------
ERROR CHANGE#
----------------------------------------------------------------- ----------
TIME
------------
4 OFFLINE OFFLINE
FILE NOT FOUND 0
SQL> exit
[oracle@dbserv ~]$ rman target /
Recovery Manager: Release 10.2.0.1.0 - Production on Thu Jun 21 12:05:44 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: TEST (DBID=2083742440)
RMAN> restore datafile '/opt/oracle/oradata/test/users01.dbf';
Starting restore at 21-JUN-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=139 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00004 to /opt/oracle/oradata/test/users01.dbf
channel ORA_DISK_1: reading from backup piece /opt/backup/full/testfull_TEST_20120610_11
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/backup/full/testfull_TEST_20120610_11 tag=TESTDB
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 21-JUN-12
RMAN> recover tablespace users;
Starting recover at 21-JUN-12
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 22 is already on disk as file /opt/backup/1_22_785596008.dbf
archive log thread 1 sequence 23 is already on disk as file /opt/backup/1_23_785596008.dbf
archive log thread 1 sequence 24 is already on disk as file /opt/backup/1_24_785596008.dbf
archive log thread 1 sequence 25 is already on disk as file /opt/backup/1_25_785596008.dbf
archive log thread 1 sequence 26 is already on disk as file /opt/backup/1_26_785596008.dbf
archive log thread 1 sequence 1 is already on disk as file /opt/backup/1_1_786046849.dbf
archive log thread 1 sequence 2 is already on disk as file /opt/backup/1_2_786046849.dbf
archive log thread 1 sequence 1 is already on disk as file /opt/backup/1_1_786052580.dbf
archive log thread 1 sequence 2 is already on disk as file /opt/backup/1_2_786052580.dbf
archive log thread 1 sequence 3 is already on disk as file /opt/backup/1_3_786052580.dbf
archive log thread 1 sequence 4 is already on disk as file /opt/backup/1_4_786052580.dbf
archive log thread 1 sequence 5 is already on disk as file /opt/backup/1_5_786052580.dbf
archive log thread 1 sequence 6 is already on disk as file /opt/backup/1_6_786052580.dbf
archive log thread 1 sequence 7 is already on disk as file /opt/backup/1_7_786052580.dbf
archive log thread 1 sequence 8 is already on disk as file /opt/backup/1_8_786052580.dbf
archive log thread 1 sequence 9 is already on disk as file /opt/backup/1_9_786052580.dbf
archive log thread 1 sequence 10 is already on disk as file /opt/backup/1_10_786052580.dbf
archive log thread 1 sequence 1 is already on disk as file /opt/backup/1_1_786419885.dbf
archive log thread 1 sequence 2 is already on disk as file /opt/backup/1_2_786419885.dbf
archive log thread 1 sequence 3 is already on disk as file /opt/backup/1_3_786419885.dbf
archive log thread 1 sequence 4 is already on disk as file /opt/backup/1_4_786419885.dbf
archive log thread 1 sequence 5 is already on disk as file /opt/backup/1_5_786419885.dbf
archive log thread 1 sequence 6 is already on disk as file /opt/backup/1_6_786419885.dbf
archive log filename=/opt/backup/1_22_785596008.dbf thread=1 sequence=22
archive log filename=/opt/backup/1_23_785596008.dbf thread=1 sequence=23
archive log filename=/opt/backup/1_24_785596008.dbf thread=1 sequence=24
archive log filename=/opt/backup/1_25_785596008.dbf thread=1 sequence=25
archive log filename=/opt/backup/1_26_785596008.dbf thread=1 sequence=26
archive log filename=/opt/backup/1_1_786046849.dbf thread=1 sequence=1
archive log filename=/opt/backup/1_2_786046849.dbf thread=1 sequence=2
archive log filename=/opt/backup/1_1_786052580.dbf thread=1 sequence=1
archive log filename=/opt/backup/1_2_786052580.dbf thread=1 sequence=2
archive log filename=/opt/backup/1_3_786052580.dbf thread=1 sequence=3
archive log filename=/opt/backup/1_4_786052580.dbf thread=1 sequence=4
archive log filename=/opt/backup/1_5_786052580.dbf thread=1 sequence=5
archive log filename=/opt/backup/1_6_786052580.dbf thread=1 sequence=6
archive log filename=/opt/backup/1_7_786052580.dbf thread=1 sequence=7
archive log filename=/opt/backup/1_8_786052580.dbf thread=1 sequence=8
archive log filename=/opt/backup/1_9_786052580.dbf thread=1 sequence=9
archive log filename=/opt/backup/1_10_786052580.dbf thread=1 sequence=10
archive log filename=/opt/backup/1_1_786419885.dbf thread=1 sequence=1
archive log filename=/opt/backup/1_2_786419885.dbf thread=1 sequence=2
archive log filename=/opt/backup/1_3_786419885.dbf thread=1 sequence=3
archive log filename=/opt/backup/1_4_786419885.dbf thread=1 sequence=4
media recovery complete, elapsed time: 00:00:03
Finished recover at 21-JUN-12
RMAN> exit
Recovery Manager complete.
[oracle@dbserv ~]$ sqlplus / as sysdba
SQL> select count(*) from tt;
select count(*) from tt
*
ERROR at line 1:
ORA-00376: file 4 cannot be read at this time
ORA-01110: data file 4: '/opt/oracle/oradata/test/users01.dbf'
SQL> alter database datafile '/opt/oracle/oradata/test/users01.dbf' online;
Database altered.
SQL> select count(*) from tt;
COUNT(*)
----------
72
SQL>
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/18841027/viewspace-1058610/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- oracle控制檔案的損壞或完全丟失的恢復辦法Oracle
- PostgreSQL DBA(30) - Backup&Recovery#3(資料檔案損壞恢復)SQL
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- system資料檔案頭損壞修復
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 資料底層損壞的恢復方法—拼碎片恢復資料
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- InterBase資料庫檔案損壞的修復方法資料庫
- 【北亞資料恢復】伺服器raid陣列癱瘓導致ZFS檔案系統元檔案損壞的資料恢復資料恢復伺服器AI陣列
- Oracle單個資料檔案損壞,在Rman命令裡設定表空間、資料檔案offline方式來恢復最方便Oracle
- SQL Anywhere db檔案損壞修復 DB檔案修復 DB資料庫修復SQL資料庫
- 隨身碟顆粒損壞資料恢復資料恢復
- 資料庫資料恢復—NTFS分割槽損壞如何恢復SqlServer資料庫資料資料庫資料恢復SQLServer
- 從備份片中恢復某個指定得歸檔或者資料檔案
- 【RMAN】如果控制檔案損壞那麼如何恢復?恢復控制檔案的方式有哪幾種?
- 資料庫資料恢復-SQL SERVER資料庫MDF (NDF)或LDF損壞如何恢復資料?資料庫資料恢復SQLServer
- 【伺服器資料恢復】raid5崩潰導致lvm資訊和VXFS檔案系統損壞的資料恢復案例伺服器資料恢復AILVM
- ibdata1檔案損壞時恢復InnoDB單表測試
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 學習這篇Oracle資料庫檔案壞塊損壞的恢復方法,擴充你的知識面Oracle資料庫
- MongoDB 資料檔案損壞修復救命repair與致命危險MongoDBAI
- 資料恢復工具Recoverit使用教程:如何修復損壞的影片資料恢復
- RMAN備份恢復典型案例——資料檔案存在壞快
- 電腦進水導致硬碟損壞資料恢復硬碟資料恢復
- 伺服器資料恢復-IBM X6伺服器linux環境下VMwave ESX檔案系統損壞的資料恢復伺服器資料恢復IBMLinux
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫
- 織夢資料庫配置檔案資料庫損壞:嘗試修復資料庫資料庫
- 【vSAN資料恢復案例】異常斷電導致vSAN底層資料損壞的資料恢復資料恢復
- linux檔案系統損壞如何修復Linux
- 資料恢復記錄:硬碟分割槽損壞修復SqlServer資料庫過程資料恢復硬碟SQLServer資料庫
- Oracle資料庫不同損壞級別的恢復詳解Oracle資料庫
- 2.7.10 恢復丟失或損壞的伺服器引數檔案(SPFILE)伺服器
- Vsan分散式檔案系統邏輯架構損壞恢復過程分散式架構
- 【北亞資料恢復】誤操作分割槽損壞導致SqlServer資料庫資料丟失的資料恢復資料恢復SQLServer資料庫