OCP-1Z0-053-V13.02-486题

486.You execute the following Recovery Manager (RMAN) commands in (he following order:

BACKUP VALIDATE DATABAE

RECOVER CORRUPTION LIST;

Which (two tasks are performed by these commands? (Choose two.)

A. Repair the corrupted blocks. If any. In the backup created.

B. Populate VSCOPV_CORRUPTION with names of files that have corrupted blocks-

C. Back up the database after checking whether array of the files have corrupted blocks.

D. Discover any corrupt blocks that are viewable with the VSDATABASE_BI-OCK_CORBUPTION view.

E. Repair all corrupted blocks that have been logged in the VSDATABASE_BLOCK_ CORRUPTION

Answer: BC

答案解析：

根据官方文档可知，此题选DE

VALIDATE

Scans the specified files and verifies their contents, testing whether this file can be backed up and whether the data blocks are corrupt. RMAN creates no output files. This option is equivalent to using the VALIDATE command on the database files specified in the backup. If you do not specify CHECK LOGICAL, then BACKUP VALIDATE checks for physical corruption only. If you specifyCHECK LOGICAL, then BACKUP VALIDATE checks for both physical and logical corruption. RMAN populates theV$DATABASE_BLOCK_CORRUPTION view with any corruptions that it finds. You can use the SET MAXCORRUPT command to set a limit for the number of corrupt blocks tolerated during the backup validation. The default is zero. If you execute BACKUP INCREMENTAL with VALIDATE, then the behavior depends on whether block change tracking is enabled. If change tracking is enabled, then RMAN validates only changed blocks; otherwise, RMAN validates all blocks in the files included in the backup. Note: You cannot validate backups of backup sets.

V$DATABASE_BLOCK_CORRUPTION

V$DATABASE_BLOCK_CORRUPTION displays information about database blocks that were corrupted after the last backup.

Column	Datatype	Description
FILE#	NUMBER	Absolute file number of the datafile that contains the corrupt blocks
BLOCK#	NUMBER	Block number of the first corrupt block in the range of corrupted blocks
BLOCKS	NUMBER	Number of corrupted blocks found starting with BLOCK#
CORRUPTION_CHANGE#	NUMBER	Change number at which the logical corruption was detected. Set to 0 to indicate media corruption.
CORRUPTION_TYPE	VARCHAR2(9)	Type of block corruption in the datafile: ALL ZERO - Block header on disk contained only zeros. The block may be valid if it was never filled and if it is in an Oracle7 file. The buffer will be reformatted to the Oracle8 standard for an empty block. FRACTURED - Block header looks reasonable, but the front and back of the block are different versions. CHECKSUM - optional check value shows that the block is not self-consistent. It is impossible to determine exactly why the check value fails, but it probably fails because sectors in the middle of the block are from different versions. CORRUPT - Block is wrongly identified or is not a data block (for example, the data block address is missing) LOGICAL - Block is logically corrupt NOLOGGING - Block does not have redo log entries (for example, NOLOGGING operations on primary database can introduce this type of corruption on a physical standby)

Prerequisites Specific to RECOVER BLOCK

The following prerequisites apply to RECOVER BLOCK:

• The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.

• RMAN can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file were marked corrupt since the most recent BACKUP or BACKUP ... VALIDATE command was run against the file.

• The backups of the data files containing the corrupt blocks must be full backups and not proxy backups. If only proxy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them data file copies. You can then use the data file copies for block media recovery.

• RMAN can use only archived redo log files for recovery. Block media recovery cannot survive a missing or inaccessible log, although it can sometimes survive missing or inaccessible records (see Oracle Database Backup and Recovery User's Guide).

• For RMAN to be able to search the flashback logs for good copies of corrupt blocks, Flashback Database must be enabled on the target database.

• For RMAN to be able to search a standby database for good copies of corrupt blocks, the target database must be associated with a physical standby database in a Data Guard environment. In addition, the physical standby database must be open read-only in managed recovery.

  
  

  
  

  blockObject

  This subclause specifies the data blocks that require recovery. Refer to blockObject::= for the syntax diagram. Refer to "Prerequisites Specific to RECOVER BLOCK" for prerequisites specific to block media recovery.

  You can either use RECOVER CORRUPTION LIST to recover all blocks reported in the V$DATABASE_BLOCK_CORRUPTION view, or specify the data file number and block number or the tablespace and data block address (DBA). RMAN can only perform complete recovery of individual blocks.

  By default, if Flashback Database is enabled, then RMAN searches the flashback logs for good copies of corrupt blocks. By default, if the target database exists in a Data Guard environment, then RECOVER BLOCK command can automatically retrieve blocks from a physical standby database to a primary database and vice-versa.

  Syntax Element

  Description

  CORRUPTION LIST

  Recovers all physically corrupt blocks listed in the V$DATABASE_BLOCK_CORRUPTION view. Block media recovery may not be able to repair all listed logically corrupt blocks. In these cases, alternate recovery methods, such as tablespace point-in-time recovery, or dropping and re-creating the affected objects, may repair the corruption. The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by Oracle Database components such as RMAN commands, ANALYZE, dbv, SQL queries, and so on. In short, any process that encounters an ORA-1578error records the block corruption in this view. The following types of corruption result in rows added to this view: Physical corruption (sometimes called media corruption). The database does not recognize the block at all: the checksum is invalid, the block contains all zeros, or the header and footer of the block do not match. Logical corruption. The block has a valid checksum, the header and footer match, and so forth, but the contents are logically inconsistent. The view does not record corruptions that can be detected by validating relationships between blocks and segments, but cannot be detected by a check of an individual block. Note: Any RMAN command that fixes or detects that a block is repaired updates V$DATABASE_BLOCK_CORRUPTION. For example, RMAN updates the repository at end of successful block media recovery. If a BACKUP, RESTORE, orVALIDATE command detects that a block is no longer corrupted, then it removes the repaired block from the view.