ORACLE 只讀資料檔案備份與恢復
第一章 只讀資料檔案備份與恢復
BLOG文件結果圖：
只讀資料檔案是隻讀表空間的資料檔案，其資料塊包括檔案頭在內不允許更改（少數管理性命令除外）。
將表空間設定為只讀狀態的命令：
SQL> alter tablespace TBS_READ read only;
Tablespace altered.
將表空間重新設定為常規的讀/寫狀態的命令：
SQL> alter tablespace TBS_READ read write;
Tablespace altered.
獲得只讀表空間及其資料檔案的sql語句：
SQL> set line 9999
SQL> col file_name format a50
SQL> select t.TABLESPACE_NAME, d.FILE_ID, d.FILE_NAME
2 from dba_tablespaces t, dba_data_files d
3 WHERE t.TABLESPACE_NAME = d.TABLESPACE_NAME
4 and t.STATUS = 'READ ONLY' ;
TABLESPACE_NAME FILE_ID FILE_NAME
----------------------- ---------- --------------------------------------------------
TBS_READ 5 /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
SQL>
1 只讀表空間的特性
使用只讀表空間避免對靜態資料的頻繁備份
當使用alter tablespace tbs read only時,資料檔案會執行檢查點程式(將所有髒緩衝區的內容寫至磁碟)，當前的SCN號會被標註,同時儲存了SCN的資料檔案頭部被凍結.控制檔案內也會記錄該資料檔案的凍結資訊。
可以清除只讀表空間的物件
2 只讀檔案損壞的後果
當一個表空間從讀/寫狀態更改為只讀狀態時，其資料檔案中的髒資料塊必須由DBWn程式悉數寫回磁碟，完成一次不完整的完全檢查點，該表空間內資料檔案即稱為只讀資料檔案，其資料塊及檔案頭資訊包括檢查點在內從此均不再更新，每次開啟資料庫例項也不會在乎只讀檔案頭的檢查點SCN是否和其他資料檔案的活線上日誌同步，但各種錯誤（ORA-01116，ORA-01110，ORA-01578，ORA-01157等等錯誤）仍然會發生。以下圖片為從電子書上擷取過來的：
不像其他型別的資料檔案，在只讀檔案頭損壞後，在發生檢查點時，所有程式視其為無物，例項不會崩潰（關鍵資料檔案頭損壞的後果），檔案也不會自動下線（普通資料檔案頭損壞的後果），總體上只讀檔案安然無恙，只是當執行需要訪問頭部的操作時才在告警日誌和追蹤檔案中留下痕跡而已，比如：
SQL> select checkpoint_change# from v$datafile where file#=5;
CHECKPOINT_CHANGE#
------------------
1865187
但告警日誌報錯：
ORA-19563: datafile header validation failed for file /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
ORA-01251: Unknown File Header Version read for file number 5
ORA-01578: ORACLE data block corrupted (file # 5, block # 130)
ORA-01110: data file 5: '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf'
此刻其內部的所有隊形還是可以查詢的（只要對應的資料塊沒有損壞），但是 alter tablspace ... read write 和 alter tablespace ... offline 之後的online回報ora-01210資料檔案頭損壞錯誤。
3 只讀表空間的備份
由於只讀資料檔案內沒有一個資料塊能夠被修改，所以，一般情況下，只讀表空間只需要進行一次備份，尤其是當只讀資料檔案佔用很大空間的時候，這樣做可以節省備份資料庫的時間。即當表空間狀態發生改變時應立即進行備份。可以使用OS系統cp命令來備份或RMAN進行備份只讀表空間。備份其他型別資料檔案的方式均適用於只讀資料檔案，比如：
v backup as backupset tablespace TBS_READ;
v backup as copy tablespace TBS_READ;
v backup as backupset datafile 5;
使用RMAN時建議啟用備份優化選項，具體保留幾份備份由備份保留策略決定：使用冗餘度時保留數量為冗餘度加1，使用恢復視窗時保留數量為1.
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
以下例子演示備份優化功能，初始狀態下是沒有任何備份的：
首先啟用備份優化：
[oracle@rhel6_lhr dbs]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Feb 3 10:02:05 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: lilove (DBID=888888)
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
using target database control file instead of recovery catalog
new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored
設定備份保留策略，使用恢復視窗3天：
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
new RMAN configuration parameters are successfully stored
RMAN> show retention policy;
RMAN configuration parameters for database with db_unique_name LILOVE are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
使用backup database 命令備份資料庫內所有的資料檔案，注意有tbs_read01.dbf檔案：
RMAN> backup database;
Starting backup at 2015-02-03 10:03:31
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=264 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/utf8test/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/utf8test/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/utf8test/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/utf8test/users01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/utf8test/tbs_read01.dbf
channel ORA_DISK_1: starting piece 1 at 2015-02-03 10:03:32
channel ORA_DISK_1: finished piece 1 at 2015-02-03 10:05:18
piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1opuba7k_1_1 tag=TAG20150203T100332 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:46
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 2015-02-03 10:05:20
channel ORA_DISK_1: finished piece 1 at 2015-02-03 10:05:21
piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1ppubaau_1_1 tag=TAG20150203T100332 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2015-02-03 10:05:21
RMAN>
當第二次執行backup database命令時，輸出中是找不到tbs_read01.dbf檔案的，rman認為沒有必要反覆備份只讀檔案：
RMAN> backup database;
Starting backup at 2015-02-03 10:08:48
using channel ORA_DISK_1
skipping datafile 5; already backed up 1 time(s)
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/utf8test/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/utf8test/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/utf8test/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/utf8test/users01.dbf
channel ORA_DISK_1: starting piece 1 at 2015-02-03 10:08:48
channel ORA_DISK_1: finished piece 1 at 2015-02-03 10:10:13
piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1qpubahg_1_1 tag=TAG20150203T100848 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:26
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 2015-02-03 10:10:15
channel ORA_DISK_1: finished piece 1 at 2015-02-03 10:10:16
piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1rpubak6_1_1 tag=TAG20150203T100848 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2015-02-03 10:10:16
若保留策略是冗餘度3，則需要等到第5次執行backup database 時才會不帶tbs_read01.dbf 檔案。另外，如果備份時使用backup tablespace 或 backup datafile命令顯式備份只讀資料檔案，那麼RMAN將忽略優化策略。
備份只讀資料檔案除了可以使用以上備份其他資料檔案的方法之外，還可以無需任何準備工作直接使用作業系統的cp複製命令備份，比如：
[oracle@rhel6_lhr dbs]$ cp /u01/app/oracle/oradata/utf8test/tbs_read01.dbf /tmp/tbs_read01.bak
另外：只讀表空間不支援熱備
SQL> alter tablespace tbs_read begin backup;
alter tablespace tbs_read begin backup
*
ERROR at line 1:
ORA-01642: begin backup not needed for read-only tablespace 'TBS_READ'
SQL>
需要特別注意的是，當一個表空間從只讀（READ ONLY）狀態改變為讀/寫（READ WRITE）狀態後，應該立即備份其資料檔案及當時（成為READ WRITE狀態後）的控制檔案，否則將來若控制檔案連同原來的只讀資料檔案同時損壞，在恢復流程中可能出現“ORA-01152：資料檔案不夠舊”的錯誤。
4 只讀表空間的還原與恢復
其他型別的資料檔案恢復過程均包括2個必要步驟：還原（restore）和恢復（recover），對於不可能有更改操作的只讀檔案來說，重做日誌是沒有意義的，當然也就沒有恢復的必要的，因此，所謂的恢復實際上只有一個步驟：還原。
在mount狀態下低可用性恢復策略的步驟如下：
① startup mount
② rman的restore 或switch命令還原資料檔案
③ alter database open
在open狀態下高可用性恢復策略的步驟如下：
① alter database datafile xx offline
② rman的restore force 或switch命令還原資料檔案。
③ alter database datafile xx online
4.1 還原前的準備
只讀資料檔案的恢復可以採用低可用性恢復策略和高可用性策略，前者是在資料庫mount狀態下進行，或者是在資料庫open狀態下進行。低可用性恢復策略要求引數檔案和控制檔案必須就位，高可用性策略額外要求資料檔案必須就位，若不滿足條件必須先進行相應的恢復。
4.2 控制檔案無損情況下的恢復
控制檔案無損情況下的恢復指：只讀資料檔案損壞時控制檔案沒有損壞
場景1：只讀資料檔案tbs_read01.dbf 丟失，資料庫無法正常啟動，停留在mount狀態，錯誤號“ORA-01157：cannot identify/locak data file 5 -see DBWR trace file.”
遇到以上情況只要使用rman執行restore（合適備份集）或switch（合適映象複製）命令還原資料檔案，然後開啟資料庫即可：
RMAN> restore datafile 5;
Starting restore at 2015-02-03 11:19:45
using channel ORA_DISK_1
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 00005 to /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/product/11.2.0/dbhome_1/dbs/1tpubeef_1_1
channel ORA_DISK_1: piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1tpubeef_1_1 tag=TAG20150203T111527
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2015-02-03 11:19:46
RMAN> alter database open;
Database altered.
場景2：只讀資料檔案tbs_read01.dbf 在例項執行時丟失，導致資料無法訪問，錯誤如下：
SQL> select * from aabbcc;
select * from aabbcc
*
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
該情況可以將資料檔案下線後通過restore 或switch命令還原，然後上線：
run{
sql 'alter database datafile 5 offline';
restore datafile 5;
sql 'alter database datafile 5 online';
}
場景3：執行時只讀資料檔案tbs_read01.dbf內部資料塊損壞，導致資料無法訪問，但是檔案依然存在，錯誤：
SQL> select * from tst;
select * from tst
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 131)
ORA-01110: data file 5: '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf'
以上情況還原時需要加force關鍵字，否則不能正確還原資料檔案（若在mount狀態下執行restore命令則無需force關鍵字）：
run{
sql 'alter database datafile 5 offline';
restore datafile 5 force;
sql 'alter database datafile 5 online';
}
使用映象複製的switch命令不必使用force關鍵字：
run{
sql 'alter database datafile 5 offline';
switch datafile 5 to datafilecopy '/tmp/ol_mf_exam.dbf';
sql 'alter database datafile 5 online';
}
場景4：起先資料檔案tbs_read01.dbf備份時是隻讀的，後來修改表空間為讀寫，但沒有備份，現在該檔案損壞了：
run{
sql 'alter database datafile 5 offline';
restore datafile 5;
recover datafile 5;
sql 'alter database datafile 5 online';
}
場景5：起先資料檔案tbs_read01.dbf備份時是讀寫狀態，後來其所在的表空間為只讀狀態，但沒有備份，現在資料檔案損壞了：
run{
sql 'alter database datafile 5 offline';
restore datafile 5 force;
recover datafile 5;
sql 'alter database datafile 5 online';
}
4.3 控制檔案損壞情況下的恢復
所謂控制檔案損壞情況下的恢復是指只讀資料檔案和控制檔案一併損壞時的恢復，一般步驟包括恢復控制檔案和只讀資料檔案，步驟如下：
（一）將資料庫啟動到nomount狀態
（二）用restore命令還原控制檔案
（三）將資料庫啟動至mount狀態
（四）用restore還原只讀資料檔案
（五）用recover命令恢復整個資料庫
（六）用resetlogs方式開啟資料庫
場景1：只讀資料檔案tbs_read01.dbf連同控制檔案一併損壞和丟失，啟動例項只能停留在nomount狀態，錯誤報告：“ORA-00205：error in identifying control file,check alert log for more info”
假設擁有控制檔案的自動備份，則：
run{
restore controlfile from autobackup;
mount database;
restore datafile 5;
recover database;
alter database open resetlogs;
}
實驗，此實驗室首先備份整個資料庫，然後修改只讀表空間屬性，總之就是經過一大堆的修改操作，然後再進行還原：
刪除控制檔案和只讀檔案：
[root@rhel6_lhr utf8test]# ll
total 1597788
-rw-r----- 1 oracle asmadmin 10076160 Feb 3 16:09 control01.ctl
-rw-r----- 1 oracle asmadmin 10076160 Feb 3 16:09 control02.ctl
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 09:27 redo01.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 15:57 redo02.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 16:09 redo03.log
-rw-r----- 1 oracle asmadmin 608182272 Feb 3 16:05 sysaux01.dbf
-rw-r----- 1 oracle asmadmin 775954432 Feb 3 16:05 system01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 3 16:05 tbs_read01.dbf
-rw-r----- 1 oracle asmadmin 20979712 Feb 3 10:27 temp01.dbf
-rw-r----- 1 oracle asmadmin 52436992 Feb 3 16:05 undotbs01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 3 16:05 users01.dbf
[root@rhel6_lhr utf8test]# rm -rf control0*
[root@rhel6_lhr utf8test]# rm tbs_read01.dbf
rm: remove regular file `tbs_read01.dbf'? y
[root@rhel6_lhr utf8test]# ll
total 1567860
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 09:27 redo01.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 15:57 redo02.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 3 16:10 redo03.log
-rw-r----- 1 oracle asmadmin 608182272 Feb 3 16:10 sysaux01.dbf
-rw-r----- 1 oracle asmadmin 775954432 Feb 3 16:10 system01.dbf
-rw-r----- 1 oracle asmadmin 20979712 Feb 3 10:27 temp01.dbf
-rw-r----- 1 oracle asmadmin 52436992 Feb 3 16:10 undotbs01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 3 16:05 users01.dbf
重啟資料庫：
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 501059584 bytes
Fixed Size 2229744 bytes
Variable Size 348129808 bytes
Database Buffers 142606336 bytes
Redo Buffers 8093696 bytes
ORA-00205: error in identifying control file, check alert log for more info
進行rman恢復：
[oracle@rhel6_lhr dbs]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Feb 3 16:11:52 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: LILOVE (not mounted)
RMAN> restore controlfile from autobackup;
Starting restore at 2015-02-03 16:11:57
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/03/2015 16:11:57
RMAN-06495: must explicitly specify DBID with SET DBID command
RMAN> set dbid 888888
executing command: SET DBID
RMAN> restore controlfile from autobackup;
Starting restore at 2015-02-03 16:12:25
using channel ORA_DISK_1
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150203
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150202
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150201
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150131
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150130
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150129
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20150128
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/03/2015 16:12:27
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
RMAN> restore controlfile from '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_LIHUARONG.f';
Starting restore at 2015-02-03 16:14:40
using channel ORA_DISK_1
channel ORA_DISK_1: copied control file copy
output file name=/u01/app/oracle/oradata/utf8test/control01.ctl
output file name=/u01/app/oracle/oradata/utf8test/control02.ctl
Finished restore at 2015-02-03 16:14:42
RMAN> mount database;
database mounted
released channel: ORA_DISK_1
RMAN> restore datafile 5;
Starting restore at 2015-02-03 16:15:06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=237 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 00005 to /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/product/11.2.0/dbhome_1/dbs/1opuba7k_1_1
channel ORA_DISK_1: piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1opuba7k_1_1 tag=TAG20150203T100332
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2015-02-03 16:15:07
RMAN> recover database;
Starting recover at 2015-02-03 16:15:15
using channel ORA_DISK_1
datafile 5 not processed because file is read-only
starting media recovery
archived log for thread 1 with sequence 2 is already on disk as file /u01/app/oracle/oradata/utf8test/redo02.log
archived log for thread 1 with sequence 3 is already on disk as file /u01/app/oracle/oradata/utf8test/redo03.log
archived log file name=/u01/app/oracle/oradata/utf8test/redo02.log thread=1 sequence=2
archived log file name=/u01/app/oracle/oradata/utf8test/redo03.log thread=1 sequence=3
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 5 was not restored from a sufficiently old backup
ORA-01110: data file 5: '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf'
media recovery complete, elapsed time: 00:00:01
Finished recover at 2015-02-03 16:15:17
注意：上邊的恢復過程中提示：datafile 5 not processed because file is read-only，ORA-01152: file 5 was not restored from a sufficiently old backup ，造成此問題的原因是資料檔案頭和控制檔案內資訊一致，5號檔案沒有被列入恢復的範疇，所以有：datafile 5 not processed because file is read-only，但是隨著恢復的進行，在重做日誌中發現有將5號檔案置為讀/寫狀態的redo記錄，所以在recover命令結束後丟擲錯誤：ORA-01152: file 5 was not restored from a sufficiently old backup，因此解決辦法也很簡單就是再次執行recover database。
經過以上分析，我們再次執行recover database：
RMAN> recover database;
Starting recover at 2015-02-03 16:15:46
using channel ORA_DISK_1
applied offline range to datafile 00005
offline range RECID=2 STAMP=870711316
starting media recovery
archived log for thread 1 with sequence 2 is already on disk as file /u01/app/oracle/oradata/utf8test/redo02.log
archived log for thread 1 with sequence 3 is already on disk as file /u01/app/oracle/oradata/utf8test/redo03.log
archived log file name=/u01/app/oracle/oradata/utf8test/redo02.log thread=1 sequence=2
archived log file name=/u01/app/oracle/oradata/utf8test/redo03.log thread=1 sequence=3
media recovery complete, elapsed time: 00:00:01
Finished recover at 2015-02-03 16:15:47
RMAN> alter database open resetlogs;
database opened
RMAN>
5 只讀表空間的控制檔案trace不同
下面對錶空間TBS_READ置為只讀後對比前後生成的重建控制檔案的指令碼
對比兩者可以發現，設定只讀屬性後，指令碼中並沒有列出只讀表空間的資料檔案。
因此：
1.使用create controlfile命令時，datafile中未列出只讀表空間的資料檔案
2.成功建立控制檔案並開啟後，使用alter database rename file命令重新命名只讀表空間的資料檔案
3.使用alter tablespace readonly_tablespacename online 將只讀表空間聯機
6 只讀表空間上的物件可以刪除
SQL> select file#,name,enabled from v$datafile where file#=6;
FILE# NAME ENABLED
---------- --------------------------------------------- ----------
6 /u01/app/oracle/oradata/orcl/tbs01.dbf READ ONLY
SQL> select segment_name,segment_type,tablespace_name,owner from dba_segments where
2 tablespace_name='TBS1' and segment_name='TB2';
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME OWNER
-------------------- ------------------ ------------------------------ ----------
TB2 TABLE TBS1 SCOTT
SQL> drop table scott.tb2;
Table dropped.
7 小結
? 1. 表空間置為只讀後將減少資料的備份量
? 2. 表空間置為只讀後，不能對其中的物件執行任何DML操作
? 3. 只讀表空間內的物件可以被清除，因為drop命令更新了資料字典，而不更新物件本身
? 4. 當表空間的狀態發生變化時，應立即備份該表空間，以減少恢復工作，一旦表空間從只讀狀態更改為讀/寫狀態，應該立即對其進行備份。
? 5. 對於狀態多次發生改變且未及時備份的情況，日誌未損壞時，可以使用聯機重做、歸檔日誌來進行恢復
使用下列命令來實現：
刪除受損的資料檔案(rm dbfile.dbf)
重建受損的資料檔案(alter database create datafile n)
進行介質恢復(recover datafile n)
使受損的資料檔案聯機(alter database datafile n online)
? 6. 演示多為在mount狀態下來恢復，生產環境中多在open狀態下恢復，可以按下列步驟實現
先將受損的只讀表空間(資料檔案)離線(offline)
使用備份的表空間(資料檔案)來還原(restore)
使用歸檔、聯機日誌進行介質恢復(recover)
使恢復成功的表空間(資料檔案)聯機(online)
? 7. 對於原始介質受損，不能恢復到原始位置的情況下,使用下面的命令實現轉移
alter database rename file '
? 建議啟用控制檔案自動備份功能，這樣在“alter tablespace ... read only”和“alter tablespace ... read write”後，控制檔案可以自動備份。
? 當控制檔案和資料檔案（只讀或曾經處於只讀）同時損壞，一個保險的run塊應該這樣寫(假設控制檔案自動備份已啟用，只讀檔案為5)：
run{
startup force nomount;
restore controlfile from autobackup;
mount database;
restore datafile 5;
recover database;
recover database;
alter database open resetlogs;
}
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-1425283/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle備份與恢復【丟失資料檔案的恢復】Oracle
- 【備份恢復】Oracle 資料備份與恢復微實踐Oracle
- 備份與恢復--利用備份的控制檔案恢復
- Oracle備份與恢復【丟失控制檔案的恢復】Oracle
- 備份與恢復--重建控制檔案後資料檔案損壞的恢復
- 備份與恢復系列 十一 控制檔案的備份與恢復
- 【備份恢復】無備份線上恢復非關鍵資料檔案
- 備份與恢復（Parameter 檔案恢復篇）
- oracle實驗記錄 （恢復-恢復未備份的資料檔案）Oracle
- 備份與恢復：polardb資料庫備份與恢復資料庫
- 備份與恢復--從備份的歸檔日誌中恢復資料
- Oracle資料泵的備份與恢復Oracle
- oracle資料庫的備份與恢復Oracle資料庫
- rman備份恢復-rman恢復資料檔案測試
- 備份與恢復系列 十 引數檔案spfile的備份與恢復
- 【備份與恢復】archivelog模式中資料檔案的恢復Hive模式
- 【備份與恢復】noarchivelog模式中資料檔案的恢復Hive模式
- Oracle12c多租戶資料庫備份與恢復 - PDB中資料檔案的恢復Oracle資料庫
- 備份與恢復--重建控制檔案
- 備份與恢復--資料檔案損壞或丟失
- 備份恢復之資料檔案丟失
- Oracle資料庫備份與恢復之三：OS備份/使用者管理的備份與恢復Oracle資料庫
- rman備份-（1） 利用備份級恢復資料檔案和控制檔案
- 備份與恢復系列 八 丟失所有資料檔案的還原與恢復
- Oracle資料庫備份與恢復之RMANOracle資料庫
- Oracle資料庫的備份與恢復（轉）Oracle資料庫
- Oracle 資料庫的備份與恢復（轉）Oracle資料庫
- 【備份與恢復】恢復受損的口令檔案
- oracle11g 資料檔案誤刪恢復(無備份)Oracle
- Oracle資料庫控制檔案在備份恢復中的作用Oracle資料庫
- Mysql資料備份與恢復MySql
- 【備份與恢復】控制檔案的恢復（不完全恢復）
- 使用備份的控制檔案恢復資料庫資料庫
- 沒有備份的資料檔案恢復（五）
- 【備份恢復】從備份恢復資料庫資料庫
- rman恢復--歸檔模式有備份，丟失資料檔案的恢復模式
- rman恢復--歸檔模式無備份，丟失資料檔案的恢復模式
- Oracle RMAN 不完全恢復（只有資料檔案備份，丟失歸檔日誌備份）Oracle