Which of the following are correct about block media recovery?

Which of the following are correct about block media recovery? (Choose all that apply.)

A.
Physical and logical block corruption is recorded automatically in
V$DATABASE_BLOCK_CORRUPTION.

B.
Logical corruptions are repairable by BMR.

C.
Physical corruptions are repairable by BMR.

D.
RMAN can use any backup for a BMR restore.

E.
ARCHIVELOG mode is not required if you have both a full and incremental backup for
restore.

Explanation:
Overview of Block Media Recovery (link)
Basic Concepts of Block Media Recovery
Whenever block corruption has been automatically detected, you can perform block media
recovery manually with the RECOVER … BLOCK command. By default, RMAN first
searches for good blocks in the real-time query physical standby database, then flashback
logs and then blocks in full or level 0 incremental backups.
Identification of Corrupt Blocks

The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by
database components such as RMAN, ANALYZE, dbv, and SQL queries. The following
types of corruption result in the addition of rows to this view: Physical corruption (sometimes
called media corruption) The database does not recognize the block: the checksum is
invalid, the block contains all zeros, or the block header is corrupt. Physical corruption
checking is enabled by default. You can turn off checksum checking by specifying the
NOCHECKSUM option of the BACKUP command, but other physical consistency checks,
such as checks of the block headers and footers, cannot be disabled.
Logical corruption:
The block has a valid checksum, the header and footer match, and so on, but the contents
are logically inconsistent. Block media recovery may not be able to repair all logical block
corruptions. 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. Logical
corruption checking is disabled by default. You can turn it on by specifying the CHECK
LOGICAL option of the BACKUP, RESTORE, RECOVER, and VALIDATE commands.
The database can detect some corruptions by validating relationships between blocks and
segments, but cannot detect them by a check of an individual block. The
V$DATABASE_BLOCK_CORRUPTION view does not record at this level of granularity.
Prerequisites for Block Media Recovery (link)
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
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 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.