使用RMAN恢復完全損壞的資料庫
使用RMAN恢復完全損壞的資料庫 (轉自 metalink.oracle.com) The purpose of this article is to describe how to recover a database from a total failure using RMAN 8i. This article is meant to assist you in performing an incomplete recovery after losing all datafiles, online redo logs, and control files. You need Oracle Services for the database and an init.ora file. Additionally, if you have archive logs that have not been cataloged, you will be able to use them as part of the recovery. 1.RESTORE CONTROLFILE set ORACLE_SID=PROD svrmgr> connect internal svrmgr> startup nomount pfile= svrmgr> Exit set ORACLE_SID=PROD RMAN TARGET INTERNAL/password CATALOG rman/rman@rcat RMAN> run { allocate channel c1 type disk; restore controlfile; alter database mount; release channel c1; } 2.QUERY TARGET AND CATALOG DATABASE Connect to the catalog database and issue the following: set ORACLE_SID=RCAT svrmgr> connect rman/rman svrmgr> select sequence#, thread#, low_scn, next_scn from rlh; SEQUENCE# THREAD# LOW_SCN NEXT_SCN ---------- ---------- ---------- ---------- 188 1 37278 189 1 37891 190 1 38231 191 1 38319 192 1 38389 193 1 38468 194 1 38562 195 1 38649 196 1 38708 197 1 38844 Note the last SCN is 197. This is the last System Change Number that the RMAN catalog is aware of. Now connect to the target database: set ORACLE_SID=PROD svrmgr> connect internal svrmgr> select * from v$log_history RECID STAMP THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# ---------- ---------- ---------- ---------- - ------------ --------- ------------ 188 410011317 1 188 & 37278 189 410011323 1 189 & 37891 190 410011328 1 190 & 38231 191 410011332 1 191 & 38319 192 410011338 1 192 & 38389 193 410011341 1 193 & 38468 194 410011345 1 194 & 38562 195 410011349 1 195 & 38649 196 410011352 1 196 & 38708 197 410011551 1 197 & 38844 Since the database has been mounted using a backup control file, the last Log Sequence Number that the control file is aware of is 197. This happens to match the last LSN known by the catalog because a resync has not been performed since the last backup. But if you look in the archive dump destination, you may see additional archive logs that have not been cataloged. You need to catalog these files so that RMAN can use them during the recovery. Directory of D:ORACLEoradataPRODarchive 0/03/00 11:46a . 0/03/00 11:46a .. 0/03/00 12:09p 11,264 PRODT001S00198.ARC 0/03/00 12:09p 11,264 PRODT001S00199.ARC 0/03/00 12:09p 1,024 PRODT001S00200.ARC 0/03/00 12:09p 1,024 PRODT001S00201.ARC 3. MANUALLY CATALOG ANY INTERMEDIATE ARCHIVED LOGS Archive logs 198 through 201 are available but have not been recorded in the catalog. Perform the following for each available archive log: set ORACLE_SID=PROD RMAN TARGET INTERNAL/password CATALOG rman/rman@rcat RMAN> catalog archivelog 'd:oracleoradataprodarchivePRODT001S00198.ARC'; 4. RESTORE AND RECOVER DATABASE The last archive log available has a log sequence number of 201, so you can perform an incomplete recovery using logs up to and including PRODT001S00201.ARC. RMAN> run { allocate channel c1 type disk; set until logseq 201 thread 1; restore database; recover database; release channel c1; sql "alter database open resetlogs"; } 5. RESET THE DATABASE Before you can use RMAN again with a target database that has been opened with the RESETLOGS option, you must notify RMAN that you have reset the database incarnation. The reset database command directs RMAN to create a new database incarnation record in the recovery catalog. RMAN> reset database; RMAN> List Incarnation of database; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- -------- ---------------- ---- ------------ ------------ 1 2 PROD 4116816026 NO 1 03-OCT-00 1 429 PROD 4116816026 YES 38872 03-OCT-00 6. BACKUP DATABASE Immediately backup the database. Because the database is a new incarnation, the pre-RESETLOG backups are not usable. Prior to running the backup, remove the old archive log file from the archive dump destination. RMAN> run { shutdown immediate; startup mount pfile= ; allocate channel c1 type disk format 'e:oracleoradatabackupdf_%d_%p_%c_%s'; backup database; release channel c1; allocate channel c1 type disk format 'e:oracleoradatabackuparchiveal_%d_%s_%c'; backup (archivelog all delete input); sql 'alter database open'; release channel c1; } [@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10748419/viewspace-986906/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 某個資料檔案損壞完全恢復(三)
- Oracle資料庫UNDO損壞後的恢復Oracle資料庫
- master資料庫損壞之後的恢復AST資料庫
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- Oracle Rman 資料庫的不完全恢復Oracle資料庫
- PG 資料庫檔案損壞的另一個不完全恢復方案.資料庫
- rman 恢復---歸檔丟失and資料檔案損壞
- 資料庫資料恢復—NTFS分割槽損壞如何恢復SqlServer資料庫資料資料庫資料恢復SQLServer
- RMAN_部分資料檔案丟失或者損壞的恢復
- 非系統資料檔案損壞,rman備份恢復
- RMAN_資料庫的絕大部分資料檔案丟失或者損壞的恢復資料庫
- 資料庫資料恢復-SQL SERVER資料庫MDF (NDF)或LDF損壞如何恢復資料?資料庫資料恢復SQLServer
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- RMAN一次RMAN將資料庫不完全恢復資料庫
- 資料底層損壞的恢復方法—拼碎片恢復資料
- 資料檔案或者tablespace損壞基於rman恢復測試
- 探索ORACLE之RMAN_07 磁碟損壞資料丟失恢復Oracle
- RMAN全庫【完全恢復/不完全恢復brief version】
- 資料恢復工具Recoverit使用教程:如何修復損壞的影片資料恢復
- Oracle塊損壞恢復(有rman備份)Oracle
- Oracle資料庫不同損壞級別的恢復詳解Oracle資料庫
- system表空間檔案損壞----完全恢復
- Oracle 11g RMAN恢復-場景1:所有的資料檔案損壞,資料庫CLOSEOracle資料庫
- 【RMAN】rman使用NORESTELOGS 方式恢復資料庫REST資料庫
- 資料檔案丟失損壞的恢復--
- RMAN恢復資料庫資料庫
- catalog損壞情況下的資料庫恢復例項資料庫
- 【RMAN】使用RMAN備份將資料庫不完全恢復到指定時間點資料庫
- [RMAN]使用RMAN備份將資料庫不完全恢復到指定時間點資料庫
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫
- [ORACLE] 系統故障資料庫恢復--資料檔案無損壞Oracle資料庫
- RMAN完全恢復丟失的資料檔案
- MySQL資料庫下.frm.MYD.MYI損壞恢復操作MySql資料庫
- index損壞恢復Index
- 資料恢復記錄:硬碟分割槽損壞修復SqlServer資料庫過程資料恢復硬碟SQLServer資料庫
- 【原創】模擬狀態為active的日誌損壞的資料恢復實驗(不完全恢復)資料恢復
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料