資料庫檔案備份與恢複案例

     資料庫各種檔案丢失恢複大全

SPFILE 丢失:

模拟操作:

oracle> mv spfileora10g.ora spora10g.ora

oracle>rman target /;

rman> shutdown immediate;

rman> startup nomount;

startup failed: ORA-01078: failure in processing system parameters

LRM-00109: could not open parameter file '/home/oracle/product/10.20/dbs/initora10g.ora'

rman>set dbid 3988862108;

rman>restore spfile from autobackup;

執行該指令，如果沒有找到的話，那可能是檔案的路徑發生錯誤.可以通過直接賦予它的文

件

rman>restore spfile from

'/u01/oracle/flash_recovery_area/ORA10G/autobackup/2008_12_09/o1_mf_s_673025706_4mw

7xc79_.bkp

在dbs/目錄下産生spfileora10g.ora 檔案。證明spfile 已經恢複好

rman> startup ;(如果該指令不能夠啟動資料庫，那麼需要set dbid 3988862108)

controlfile 丢失:

startup nomount;

restore controlfile from autobackup;

alter database mount;

recover database;

alter database open resetlogs;

注意:在做了alter database open resetlogs;會把online redelog file 清空，資料檔案丢失.是以這

個時候要做一個全備份。

oracle>rm *.ctl

oracle>rman target / ;//不能夠連接配接到rman ,因為controlfile 丢失

oracle>sqlplus /nolog;

SQL>shutdown immediate; //因為controlfile 丢失，不能夠正常shutdown

SQL>shutdown abort;

rman>startup nomount;

rman>restore controlfile from autobackup;

rman>alter database mount;

rman>alter database open resetlogs;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-03002: failure of alter db command at 12/09/2008 16:21:13

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/home/oracle/oradata/ora10g/system01.dbf

//出錯, redo log 的scn 記錄在controlfile 裡面的，因為我們有新的controlfile,是以需要

resetlogs;

/*

resetlogs 指令表示一個資料庫邏輯生存期的結束和另一個資料庫邏輯生存期的開始，每次使

用resetlogs 指令的時候，SCN 不會被重置，不過oracle 會重置日志序列号，而且會重置

聯機重做日志内容.

這樣做是為了防止不完全恢複後日志序列會發生沖突（因為現有日志和資料檔案間有了時間

差）。

*/

rman>recover database;

Redolog file 丢失:(下面的這些語句一定要在sqlplus 中執行,不是在rman 中執行)

(sqlplus/nolog)

1.shutdown immediate;

2.startup mount;

3.recover database until cancel;(media recovery)

4.alter database resetlogs;

資料檔案丢失(在rman 中執行sql 語句，在sql 後面用雙引号括起來):

1. sql "alter database datafile 3 offline";

2. restore datafile 3

3. recover datafile 3

4. sql "alter database datafile 3 online";

表空間丢失:

1. sql "alter tablespace users offline";//如果檔案不存在，則用sql "alter tablespace users offline

immeidate";

2. restore tablespace users;

3. recover tablespace users; //與online redolog file 資訊一緻

4. sql "alter tablespace users online";

非catalog 方式完全恢複

資料庫出現問題:

1.startup nomount;

2.restore controlfile from autobackup;

3.alter database mount;

4.restore database;

5.recover database;

6.alter database open resetlogs;

oracle ora10g> rm *;

oracle ora10g> ls;

oracle ora10g> //資料檔案，控制檔案全部删除

oracle ora10g> rman target /; //因為controlfile 丢失，不能夠連接配接到rman

oracle ora10g> sqlplus /nolog;

oracle ora10g> connect / as sysdba;

oracle ora10g> shutdown abort;

oracle ora10g> rman target /

rman> restore controlfile from autabackup;

rman> alter database mount;

rman> restore database;

rman> recover database; //online redolog 不存在

SQL>recover database until cancel; //當redo log 丢失，資料庫在預設的方式下，是不容許進行

recover 操作的,那麼如何在這種情況下操作呢

SQL>create pfile from spfile;

vi /u01/product/10.20/dbs/initora10g.ora，在這個檔案的最後一行添加

*.allow_resetlogs_corruption='TRUE'; //容許resetlog corruption

SQL>shutdown immediate;

SQL>startup pfile='/u01/product/10.20/dbs/initora10g.ora' mount;

SQL>alter database open resetlogs;

基于時間點的恢複:

run{

set until time "to_date(07/01/02 15:00:00','mm/dd/yy hh24:mi:ss')";

restore database;

}

ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';

1.startup mount;

2.restore database until time "to_date('2009-7-19 13:19:00','YYYY-MM-DD HH24:MI:SS')";

3.recover database until time "to_date('2009-7-19 13:19:00','YYYY-MM-DD HH24:MI:SS')";

4.alter database open resetlogs;

如果有open resetlogs,都是不完整恢複.

基于SCN 的恢複:

2.restore database until scn 10000;

3.recover database until scn 10000;

基于日志序列的恢複:

2.restore database until SEQUENCE 100 thread 1; //100 是日志序列

3.recover database until SEQUENCE 100 thread 1;

日志序列檢視指令： SQL>select * from v$log;其中有一個sequence 字段.resetlogs 就會把

sequence 置為1

本文轉自東方之子736651CTO部落格，原文連結：http://blog.51cto.com/ecloud/1339074 ，如需轉載請自行聯系原作者