BlockRecover Restrictions and Usage Notes
Restrictions and Usage Notes
The target database must be mounted or open. You do not have to take a datafile offline if you are performing block media recovery on it.
You can only perform complete media recovery of individual blocks. Point-in-time recovery of individual data blocks is not supported.
You can only perform block media recovery on corrupt blocks.
Blocks marked media corrupt are not accessible until recovery completes.
You cannot perform block media recovery when using a backup control file.
You cannot use proxy backups to perform block media recovery. If the only backups that you have are proxy backups, then you can restore them to a nondefault location on disk, which causes RMAN to view the restored files as datafile copies. You can then use the datafile copies for block media recovery.
You must have a full backup of the file containing the corrupt blocks: block media recovery cannot use incremental backups.
If RMAN fails to access a specific archived redo log file needed for block media recovery, it performs restore failover, trying all other backups listed in the RMAN repository that are suitable for use in this operation, and only fails if no suitable backup is available. See Oracle Database Backup and Recovery Advanced User's Guide for details on restore failover.
Block media recovery cannot survive a missing or inaccessible archived log, although it can sometimes survive missing or inaccessible records (Oracle Database Backup and Recovery Advanced User's Guide).
The datafile header block (block 1) cannot be recovered.
You cannot perform block media recovery in NOARCHIVELOG mode.
The target database must be mounted or open. You do not have to take a datafile offline if you are performing block media recovery on it.
You can only perform complete media recovery of individual blocks. Point-in-time recovery of individual data blocks is not supported.
You can only perform block media recovery on corrupt blocks.
Blocks marked media corrupt are not accessible until recovery completes.
You cannot perform block media recovery when using a backup control file.
You cannot use proxy backups to perform block media recovery. If the only backups that you have are proxy backups, then you can restore them to a nondefault location on disk, which causes RMAN to view the restored files as datafile copies. You can then use the datafile copies for block media recovery.
You must have a full backup of the file containing the corrupt blocks: block media recovery cannot use incremental backups.
If RMAN fails to access a specific archived redo log file needed for block media recovery, it performs restore failover, trying all other backups listed in the RMAN repository that are suitable for use in this operation, and only fails if no suitable backup is available. See Oracle Database Backup and Recovery Advanced User's Guide for details on restore failover.
Block media recovery cannot survive a missing or inaccessible archived log, although it can sometimes survive missing or inaccessible records (Oracle Database Backup and Recovery Advanced User's Guide).
The datafile header block (block 1) cannot be recovered.
You cannot perform block media recovery in NOARCHIVELOG mode.
Oracle 11g:
Prerequisites for Block Media Recovery
The following prerequisites apply to the RECOVER ... BLOCK command:
-
The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.
-
If the target database is a standby database, then it must be in a consistent state, recovery cannot be in session, and the backup must be older than the corrupted file.
-
The backups of the datafiles containing the corrupt blocks must be full or level 0 backups and not proxy copies.
If only proxy copy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them datafile copies and searches them for blocks during block media recovery.
-
RMAN can use only archived redo logs for the recovery.
RMAN cannot use level 1 incremental backups. Block media recovery cannot survive a missing or inaccessible archived redo log, although it can sometimes survive missing redo records.
-
Flashback Database must be enabled on the target database for RMAN to search the flashback logs for good copies of corrupt blocks.
If flashback logging is enabled and contains older, uncorrupted versions of the corrupt blocks, then RMAN can use these blocks, possibly speeding up the recovery.
-
The target database must be associated with a real-time query physical standby database for RMAN to search the database for good copies of corrupt blocks.
Oracle 12c:
The following prerequisites apply to the RECOVER ... BLOCK command:
The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.
If the target database is a standby database, then it must be in a consistent state, recovery cannot be in session, and the backup must be older than the corrupted file.
The backups of the data files containing the corrupt blocks must be full or level 0 backups. They cannot be proxy copies or incremental backups.
If only proxy copy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them data file copies and searches them for blocks during block media recovery.
RMAN can use only archived redo logs for the recovery.
RMAN cannot use level 1 incremental backups. Block media recovery cannot survive a missing or inaccessible archived redo log, although it can sometimes survive missing redo records.
Flashback Database must be enabled on the target database for RMAN to search the flashback logs for good copies of corrupt blocks.
If flashback logging is enabled and contains older, uncorrupted versions of the corrupt blocks, then RMAN can use these blocks, possibly speeding up the recovery.
The target database must be associated with a real-time query physical standby database for RMAN to search the database for good copies of corrupt blocks.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/13750068/viewspace-1481827/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 學習blockrecoverBloC
- Restrictions on Analyzing TablesREST
- Restrictions on Create Bitmap IndexesRESTIndex
- Restrictions on Altering Temporary TablesREST
- dnsjava usageDNSJava
- 塊介質恢復(BLOCKRECOVER命令)BloC
- RMAN blockrecover命令恢復資料塊BloC
- costume GIT usage for meGit
- solaris 10 disksuite usageUI
- table type usage sample:
- 如何在 SAP 電商雲裡設定 Time RestrictionsREST
- Mongodb NotesMongoDB
- Typora Notes
- ACM notesACM
- [Oracle Script] Temporary Sort UsageOracle
- [Oracle Script] Rollback Segment UsageOracle
- Clear Case usage tips
- Oracle runInstaller 's UsageOracle
- Oracle NUMA usage recommendationOracle
- MySQL, Incorrect usage of UNION and ORDER BYMySql
- Implementing App Restrictions,Building a Device Policy ControllerAPPRESTUIdevController
- WireGuard Use Notes
- [Oracle Script] check tablespace usage infoOracle
- [Oracle Script] check temp tablespace usageOracle
- [Oracle Script] Undo Usage Per statusOracle
- [Oracle Script] Undo Usage Per sessionOracleSession
- Oracle 11g tablespace usageOracle
- [Shell] Linux monitor tablespace usageLinux
- V$sort_usage, where is the definition?
- 基於RMAN實現壞塊介質恢復(blockrecover)BloC
- c++stl notesC++
- Linux配置notesLinux
- Make notes for disaster recoveryAST
- Thinking in java notesThinkingJava
- 4.Linux monitor tablespace usageLinux
- [Shell] Monitor filesystem usage & delete expire filedelete
- Oracle NUMA Usage Recommendation [ID 759565.1]Oracle
- Index of system requirements for Notes, Domino, Domino Administrator, Domino Designer & Notes TravelIndexUIREM