使用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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- 資料庫資料恢復—NTFS分割槽損壞如何恢復SqlServer資料庫資料資料庫資料恢復SQLServer
- 資料庫資料恢復-SQL SERVER資料庫MDF (NDF)或LDF損壞如何恢復資料?資料庫資料恢復SQLServer
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- 資料底層損壞的恢復方法—拼碎片恢復資料
- Oracle資料庫不同損壞級別的恢復詳解Oracle資料庫
- 資料恢復工具Recoverit使用教程:如何修復損壞的影片資料恢復
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫
- 資料恢復記錄:硬碟分割槽損壞修復SqlServer資料庫過程資料恢復硬碟SQLServer資料庫
- 【北亞資料恢復】誤操作分割槽損壞導致SqlServer資料庫資料丟失的資料恢復資料恢復SQLServer資料庫
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料
- 隨身碟顆粒損壞資料恢復資料恢復
- raid5癱瘓導致資料庫損壞的恢復過程AI資料庫
- 成功恢復某公司伺服器故障導致的資料庫損壞伺服器資料庫
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- SQLite資料庫損壞及其修復探究SQLite資料庫
- oracle控制檔案的損壞或完全丟失的恢復辦法Oracle
- RMAN備份恢復典型案例——資料檔案存在壞快
- 【資料庫資料恢復】SQL SERVER資料庫MDF (NDF)或LDF損壞問題如何解決?資料庫資料恢復SQLServer
- InterBase資料庫檔案損壞的修復方法資料庫
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- 【vSAN資料恢復案例】異常斷電導致vSAN底層資料損壞的資料恢復資料恢復
- 【RMAN】如果控制檔案損壞那麼如何恢復?恢復控制檔案的方式有哪幾種?
- 伺服器Oracle資料庫損壞修復伺服器Oracle資料庫
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 【北亞資料恢復】異常斷電導致linux伺服器無法啟動,資料庫損壞的資料恢復資料恢復Linux伺服器資料庫
- 電腦進水導致硬碟損壞資料恢復硬碟資料恢復
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 12C PDB使用RMAN的4種完全恢復場景
- oracle資料庫損壞的恢復過程-基於IBM伺服器儲存Oracle資料庫IBM伺服器
- PostgreSQL 恢復大法 - 恢復部分資料庫、跳過壞塊、修復無法啟動的資料庫SQL資料庫
- 【LINUX】Oracle資料庫 linux磁碟頭資料損壞修復LinuxOracle資料庫
- RMAN備份恢復典型案例——資料庫卡頓資料庫
- 伺服器資料庫損壞能修復嘛伺服器資料庫
- redo損壞修復啟動資料庫辦法資料庫
- 學習這篇Oracle資料庫檔案壞塊損壞的恢復方法,擴充你的知識面Oracle資料庫
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 如何恢復行動硬碟損壞的資料?先找原因後解決硬碟