Which two statements are true about recovering logically corrupted tables or table partitions from an RMAN backup?

Question

Options

• ATables or table partitions can be recovered by using an auxiliary instance only.
• BTables or table partitions with a foreign key cannot be recovered.
• CTables or table partitions can be recovered only when the database is in mount state.
• DTables or table partitions from the system and sysaux tablespaces cannot be recovered.
• ETables with not null constraints cannot be recovered.

• A
  84% (31)
• B
  3% (1)
• C
  3% (1)
• E
  11% (4)

Explanation

A is correct because RMAN table-level recovery (introduced in Oracle 12c) always requires an auxiliary instance - RMAN restores the backup there, extracts the target table using Data Pump, then imports it into the production database. There is no path to recover individual tables without this intermediate auxiliary step, whether automatic or manually provisioned. D is correct because tables owned by SYS or residing in the SYSTEM and SYSAUX tablespaces are explicitly excluded from table-level recovery; these contain Oracle internal metadata that must be recovered through traditional full/tablespace restore methods.

B is wrong - foreign key constraints do not block the recovery; RMAN handles dependent objects and you can include related tables in the same recovery operation. C is wrong - the target database must be open, not mounted, because Data Pump needs a running database to perform the final import of the extracted table data. E is wrong - NOT NULL constraints have no bearing on RMAN's ability to recover a table; constraint type is irrelevant to the backup/restore mechanism.

Memory tip: Think of table-level recovery as a "staging relay" - it always routes through an Auxiliary instance (A), and it can't touch Oracle's own house (SYSTEM/SYSAUX = D). Everything else - constraints, foreign keys, database state - is a distractor playing on general restore fears.

No community discussion yet for this question.