完全恢復：
前提條件：所需要的歸檔日誌檔案和online redolog都在
方式一、資料庫在開啟的情況下進行恢復
適合的環境：普通資料檔案損壞（非system、undo的表空間的資料檔案)
環境準備：
1、以scott使用者登入，往test表當中插入資料，並導致日誌切換至少3組以上。
sql> select count(*) from test;
count(*)
----------
1122、最後再進行insert操作，但是沒有提交：
sql> select count(*) from test;
sql*plus: release 10.2.0.1.0 - production on sun aug 21 06:39:55 2011
connected to an idle instance.
sql> startup
oracle instance started.
檢視資料檔案頭實際的檢查點號：
sql> select name,checkpoint_change# from v$datafile_header;
database altered.
9、嘗試開啟資料庫：
sql> alter database open;
database altered.
10、再對損壞的資料檔案進行recovery，在recovery 過程中，觀察警告日誌檔案：
sql> recover tablespace users;
通過觀察警告日誌檔案，可以看出，oracle做recovery的時候是採用archivelog ＋ online redolog的方式進行。
11、把錶空間改變成online狀態。
sql> alter tablespace users online;
tablespace altered.
12、驗證資料檔案是否正確：
sql> select count(*) from scott.test;
count(*)
----------
112＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
方式二、資料庫在mount狀態下恢復
適合環境：所有型別的資料檔案損壞
1、主機斷電，導致所有的資料檔案損壞（控制檔案沒有損壞）
sql> shutdown abort
oracle instance shut down.
sql> startup
oracle instance started.
3、從最近的備份中restore資料檔案：
rman> restore database;
4、嘗試開啟資料庫：
5、對資料庫進行recovery：
sql> recover database;
注意：recovery 結束後，應該檢視資料檔案頭的檢查點號是否同步了。
6、開啟資料庫，檢查資料的正確性。
＝＝＝＝＝＝＝＝＝＝＝＝＝
方式三、控制檔案和所有的資料檔案損壞
1、主機斷電，導致所有的資料檔案和控制檔案損壞：
2、主機加電，嘗試開啟資料庫：
sql> startup
oracle instance started.
total system global area 167772160 bytes
fixed size 1218316 bytes
variable size 67111156 bytes
database buffers 96468992 bytes
redo buffers 2973696 bytes
ora-00205: error in identifying control file, check alert log for more info
4、把資料庫啟動到mount狀態：
5、使用rman restore所有的資料檔案：
rman> restore database;
6、嘗試開啟資料庫：
7、對資料庫進行recovery：
恢復失敗，因為使用的控制檔案是舊的，無法識別最新的online redolog的序列號，無法做完全恢復。
8、重建控制檔案，重建過程中，oracle會掃瞄redolog，獲得最新的資訊來更新當前的資料。
9、獲得重建控制檔案的語句：
sql> alter database backup controlfile to trace;
該語句被放在user_dump_dest引數指定的目錄下。
10、重新啟動例項到nomount狀態：
11、執行重建控制檔案的語句：
12、重建結束後，檢視v$log檢視，看當前的序列號是否更新：
sql> select * from v$log;
13、再次對資料庫進行完全恢復：
14、恢復結束後，開啟資料庫，驗證資料正確性。
＝＝＝＝＝＝＝＝＝＝＝
方式四：未備份資料檔案損壞
適合環境：要求從建立該資料檔案開始，所有的歸檔日誌都在
1、建立乙個新的表空間：
2、建立新的表，並且放在新建的表空間：
sql> create table scott.test22 tablespace test as select * from scott.emp;
3、主機斷電，導致新建的資料檔案損壞：
4、主機加電，嘗試開啟資料庫：
sql> startup
oracle instance started.
7、嘗試開啟資料庫：
sql> alter database open;
database altered.
8、檢查資料的完整性：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
不完全恢復方式：
1、基於cancel的不完全恢復
環境準備：
1、以scott使用者對錶進行insert操作，並且人為切換日誌：
sql> select count(*) from test;
count(*)
----------
1792
2、再次insert，並且commit，但是日誌沒有切換：
sql> select count(*) from test;
count(*)
----------
3584
3、主機斷電，導致所有的online redo log損壞：
sql> shutdown abort
oracle instance shut down
此時，資料庫無法開啟，因為無法進行例項恢復。
5、對資料庫進行不完全恢復，把所有的資料檔案，restore到以前的某個狀態：
rman> restore database;
6、對資料庫進行不完全recovery：
sql> recover database until cancel;
7、使用resetlogs開啟資料庫：
sql> alter database open resetlogs;
8、驗證資料的完整性：
總結：從oracle 10g開始，用resetlog開啟資料庫後，不需要全庫備份，以前的備份加上現在的歸檔日誌，還可以做完全恢復。
＝＝＝2、基於時間點的不完全恢復：
適合環境：某個關鍵的表被意外刪除。
1、記錄一下表被刪除的時間點
sql> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
to_char(sysdate,'yy
-------------------
2011-08-21 08:50:10
2、把test表給drop掉，新建立乙個表：
sql> drop table test purge;
table dropped.
sql>
sql>
sql> create table test_after as select * from emp;
table created.
3、把所有的資料檔案restore到以前的某個狀態，然後做時間點恢復：
sql> recover database until time '2011-08-21 08:50:10';
4、開啟資料庫，驗證test表是否恢復成功：
sql> alter database open resetlogs;
database altered.
sql> select table_name from dba_tables where owner='scott' and table_name like 'test%';
table_name
------------------------------
test22
test2
test
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
dba小王要恢復一張關鍵的表，當他詢問使用者時，告知該錶在25日16時還存在，現在已知的備份情況如下：
1、每天從1－7是備份時間
2、以最短的recovery時間把關鍵的表給恢復回來
3、資料庫是熱備
小王使用基於時間點的恢復，請問，至少恢復到哪個時間點？
Oracle備份與恢復
oracle的備份與恢復有三種標準的模式，大致分為兩大類，備份恢復 物理上的 以及匯入匯出 邏輯上的 而備份恢復又可以根據資料庫的工作模式分為非歸檔模式 nonarchivelog style 和歸檔模式 archivelog style 通常，我們把非歸檔模式稱為冷備份，而相應的把歸檔模式稱為熱備...
oracle 備份與恢復
oracle備份和恢復 1 邏輯備份 不用去拷貝資料庫的物理檔案 備份邏輯上的結構 外部的工具 匯出和匯入的工具 dos下的命令 cmd下執行 匯出exp export縮寫形式 檢視幫助 exp help y 使用引數檔案匯出 exp parfile c abc.par abc.par的內容 a s...
oracle 備份與恢復
1.建立表空間 sqlplus nolog sql conn sys sys as sysdba sql create tablespace test123 datafile d test123 size 500m 2.建立使用者並指向表空間 sql create user test123 idde...