您好,登錄后才能下訂單哦!
SPFILE文件損壞的恢復場景:
場景 | 恢復操作 | |
SPFILE文件損壞 | 有備份 | SQL> startup nomount; RMAN> restore spfile from '/backup/ctl_XXXX'; SQL> shutdown immediate; Oracle instance shut down SQL> startup; |
無備份 | 手工創建pfile文件并生成spfile文件 一般只需幾個關鍵參數就能把庫拉起,但考慮到性能問題,得恢復到丟失前的參數設置,可以從以下幾個地方找: 1.awr報告里面的spfile,在awr報告最后 2.alert log里面在庫啟動時都會很很多初始參數輸出 |
控制文件恢復場景及演示:https://blog.51cto.com/wyzwl/1978252
場景 | 恢復方法 | 恢復條件 | |
其中一個控制文件損壞 | 1.1 拷貝冗余的控制文件 | 1、具有多路冗余控制文件鏡像 | |
2、其它冗余控制文件沒有損壞 | |||
1.2 修改control_files參數去除損壞文件 | 同上、但不推薦該方法進行恢復 | ||
所有的控制文件損壞 | 有備份 | 2.1 通過rman備份控制文件進行完全恢復 | 1、通過rman備份了控制文件 |
2、備份了控制文件之后有連續的歸檔和redo文件 | |||
2.2 通過rman備份控制文件進行不完全恢復 | 1、通過rman備份了控制文件 | ||
2、備份了控制文件之后歸檔或redo文件丟失 | |||
2.3 通過trace備份控制文件進行完全恢復 | 1、通過trace備份了控制文件 | ||
2、備份了控制文件之后有連續的歸檔和redo文件 | |||
2.4 通過trace備份控制文件進行不完全恢復 | 1、通過trace備份了控制文件 | ||
2、備份了控制文件之后歸檔或redo文件丟失 | |||
無備份 | 2.5 通過手工重建控制文件進行恢復(noresetlogs) | 1、無有效的備份控制文件 | |
2、redo文件無丟失和無損壞 | |||
2.6 通過手工重建控制文件進行恢復(resetlogs) | 1、無有效的備份控制文件 | ||
2、redo文件丟失或損壞 | |||
2.7 通過SNAPSHOT CONTROLFILE文件進行恢復 | 此處為記錄一個恢復控制文件的方法(不常使用) |
日志文件(redo log)恢復場景及演示(不考慮非歸檔模式):
場景 | 是否歸檔 | 恢復操作 | ||
STATUS=INACTIVE | 日志信息無需寫入數據文件 | 1.在線時損壞 2.正常關閉后損壞 | ARC=YES | open和mount狀態都可以執行,不會丟失數據 SQL>alter database clear logfile group 1; |
ARC=NO | open和mount狀態都可以執行,不會丟失數據 SQL>alter database clear unarchived logfile group 1; | |||
STATUS=ACTIVE | 日志信息需要寫入數據文件 | 1.在線時損壞 2.不正常關閉后損壞 | ARC=YES | 1.實例在線時損壞,直接在線執行,不丟數據(千萬別關庫) SQL>alter database clear unarchived logfile group 1; 2.實例不正常關閉后損壞,丟數據 SQL>startup nomount; SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile; SQL>shutdown immediate; SQL>startup mount; SQL>recover database until cancel; SQL>alter database open resetlogs; |
ARC=NO | 1.實例在線時損壞,直接在線執行,不丟數據 SQL>alter database clear unarchived logfile group 1; 2.實例不正常關閉后損壞,不丟數據 SQL>startup nomount; SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile; SQL>shutdown immediate; SQL>startup mount; SQL>recover database until cancel; SQL>alter database open resetlogs; | |||
STATUS=CURRENT | 日志信息無需寫入數據文件 | 正常關閉后損壞 | ARC=NO | 實例正常關閉后損壞,不丟失數據 SQL>startup mount; SQL>alter database clear unarchived logfile group 1; |
日志信息需要寫入數據文件 | 1.在線時損壞 2.不正常關閉后損壞 | ARC=NO | 1.實例在線時損壞,直接在線執行,不丟數據(千萬別關庫) SQL>alter system switch logfile; SQL>alter database clear unarchived logfile group 1; 2.實例不正常關閉后損壞,會丟失數據 SQL>startup nomount; SQL>alter system set "_allow_resetlogs_corruption"=ture scope=spfile; SQL>shutdown immediate; SQL>startup mount; SQL>recover database until cancel; SQL>alter database open resetlogs; |
表空間和數據文件恢復場景及演示:
場景 | 是否完全恢復 | 恢復操作 | ||
數據文件 | 系統表空間數據文件(system,sysaux,undo) | 有完整備份(歸檔,rman) | 是 | SQL>startup mount; SQL>alter database recover datafile <file_id>; SQL>alter database open; |
無完整備份(缺歸檔等) | 否 | RMAN不完全恢復 1、基本時間恢復 c:\set nls_date_format=yyyy-dd-mm hh34:mi:ss c:\rman target sys/oracle@test nocatalog RMAN>run { startup force mount; set until time='2010-08-22 12:00:08'; restore database; recover database; sql 'alter database open resetlogs; } 2、基于SCN恢復 RMAN>run { startup force mount; set until scn=123456; restore database; recover database; sql 'alter database open resetlogs'; } 3、基于日志序列號恢復 RMAN>run { startup force mount; set until seqence=10; restore database; recover database; sql 'alter database open resetlogs'; } 4、基于備份控制文件恢復 c:\set nls_date_format=yyyy-dd-mm hh34:mi:ss c:\rman target sys/oracle@test nocatalog RMAN>startup force nomount; RMAN>set dbid=1113606269; RMAN>restore controlfile from autobackup maxseq 6; RMAN>alter database mount; RMAN>run { set until time='2010-08-22 12:00:08'; restore database; recover database; sql 'alter database open resetlogs; } | ||
普通表空間數據文件 | 有完整備份(歸檔,rman) | 是 | SQL>alter database datafile <datafile_name> offlie; SQL>alter database recover datafile <datafile_name>; SQL>alter tablespace datafile <datafile_name> online; | |
無完整備份(缺歸檔等) | 否 | 如果缺失歸檔:對庫進行基于時間點不完整恢復 如果無備份: alter database datafile ‘xxx’ offline drop; 或者重建控制文件,代價就是丟失這個數據文件里的數據 | ||
表空間 | 系統表空間 | 有完整備份(歸檔,rman) | 是 | SQL> shutdown immediate --如果無法使用immediate關閉數據庫,則使用shutdown abort RMAN> run { startup mount; restore tablespace system; recover tablespace system; alter database open; } |
無完整備份(缺歸檔等) | 否 | 同系統表空間數據文件無完整備份恢復一樣,得進行不完全恢復: 1、基本時間恢復 2、基于SCN恢復 3、基于日志序列號恢復 4、基于備份控制文件恢復 | ||
普通表空間 | 有完整備份(歸檔,rman) | 是 | SQL>alter tablespace users offlie; SQL>alter database recover tablespace <tablespace_name>; SQL>alter tablespace users online; | |
無完整備份(缺歸檔等) | 否 | 如果缺失歸檔:對庫進行基于時間點不完整恢復 如果無備份: alter database datafile ‘xxx’ offline drop; | ||
全庫恢復 | 所有表空間 | 有完整備份(歸檔,rman) | 是 | RMAN>run { startup mount; restore database; recover database; sql 'alter database open resetlogs; } |
無完整備份(缺歸檔等) | 否 | 同系統表空間數據文件無完整備份恢復一樣,得進行不完全恢復: 1、基本時間恢復 2、基于SCN恢復 3、基于日志序列號恢復 4、基于備份控制文件恢復 |
各種誤刪表數據操作恢復場景:
場景 | 恢復操作 |
誤刪表數據恢復(delete) | 閃回查詢,閃回版本查詢 select * from emp as of timestamp to_timestamp('2004-04-04 09:30:00', 'yyyy-mm-dd hh:mi:ss'); 若11g開啟了閃回歸檔,可利用這個新特性恢復 12c的rman新特性可單獨恢復表 |
誤刪表數據恢復(truncate) | 利用fy_recover_data離線數據文件恢復 |
誤刪表恢復(drop) | 1.沒有相同名字 flashback table 原表名 to before drop [rename to 新表名]; 或 flashback table "回收站中的表名" to before drop [rename to 新表名]; 2.有相同的名字 用戶可能會經常多次創建和刪除同一個表,第一個版本恢復到 TEST1,將第二個版本恢復到 TEST2 FLASHBACK TABLE "BIN$04LhcpnoanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST1; FLASHBACK TABLE "BIN$04LhcpnqanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST2; |
誤修改的VIEW,FUNTION,PROCEDURE,PACKAGE代碼恢復 | 1、使用ODU恢復 2、利用閃回查詢恢復 3、通過基表進行恢復 |
閃回的場景及演示介紹:
技術 | 應用場景 | 步驟 | 限制 |
TSPITR | 1、表空間中,某個表的重要數據被破壞或刪除。 2、誤用DDL語言更改了表空間中的一個或多個表的結構,因此無法使用閃回來恢復這些表。 3、表被誤刪,并且已不在回收站中,如使用了帶purge選項的刪表操作。 | set nls_date_format=yyyy-mm-dd hh34:mi:ss; recover tablespace users until time '2018-01-15 09:20:00' auxiliary destination '/auxdata'; sql 'alter tablespace users online'; | 1、數據庫必須位于歸檔模式,且存在相應的備份集合。 2、要恢復的表空間必須是自包含的,不依賴于其它表空間中的對象。例如,如果一個表在其它表空間中包含索引,則它們或者一起參與恢復,或者先將依賴關系解除才能做恢復。 |
flashback | 在正式生產環境一般都不會輕易閃回整庫,在測試環境中,可以利用這個特性來還原數據,比如第一輪UAT測試完成后,回到初始化狀態,可以進行下一輪測試 | 啟用flashback database步驟 查詢數據庫是否開啟閃回:select flashback_on from v$database; 關閉數據庫à啟動到mount狀態à開啟歸檔,設置閃回,不能設置歸檔路徑,歸檔存放在閃回日志目錄下:alter system set log_archive_dest=’’;à設置閃回日志目錄:alter system set db_recovery_file_dest=’+data’;à設置閃回日志保留3天時間,默認1440分鐘:alter system set flashback_retention_target=4320;à設置閃回日志存儲空間大小:alter system set db_recovery_file_dest_size=5000g;à打開閃回alter database flashback on;à查詢是否開啟à打開DB:alter database open; 如何閃回 查詢閃回能恢復的最久時間段 Select oldest_flashback_scn,oldest_flashback_time from v$flashback_database_log; 重啟DB到MOUNT狀態à閃回數據庫到某個時間點:flashback database to timestamp to_timestamp(‘2016-01-02 00:00:00’,’yyyy-mm-dd hh34:mi:ss’); 或閃回DB到某SCN:flashback database to scn xxx; | 1.flashback 數據庫不能解決media failure 這種錯誤rman是唯一選擇 2.若刪除了數據文件或用戶shrink 縮小了數據文件大小,flashback不能用,需要先利用rman把刪除之前或縮小文件之前恢復,再閃回 3.如果控制文件恢復出來或重建控制文件,不能閃回 4.閃回恢復到最早SCN,取決flashback log 中記錄的最早SCN |
其它恢復工具的介紹:
恢復工具 | 恢復參考 |
ODU工具的使用 | 強大的恢復工具,需要版權,有試用版,功能較小 http://www.oracleodu.com/cn/ |
AMDU恢復 | 針對ASM磁盤無法掛載后的數據文件抽取恢復 http://www.eygle.com/archives/2012/03/asm_amdu_recovery.html |
logmnr | 在delete誤刪數據無法使用快照閃回恢復時,使用logmnr挖歸檔,可以恢復數據 添加需要分析的在線日志 exec dbms_logmnr.add_logfile(logfilename=>'/opt4/arch/1_22560_911528823.dbf',options=>dbms_logmnr.new); 添加其他在線日志 exec dbms_logmnr.add_logfile(logfilename=>'/opt4/arch/1_22560_911528823.dbf',options=>dbms_logmnr.addfile); 分析添加的文件 execute dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog + dbms_logmnr.committed_data_only+dbms_logmnr.print_pretty_sql); 查詢對應內容 select * from v$logmnr_contents; |
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。