CCNA Backup And Recovery Questions

In NOARCHIVELOG mode, Oracle does not archive redo logs, so there is no continuous record of changes to roll forward or back to an arbitrary point. You can only restore the most recent full backup, losing all changes made after it. This makes point-in-time recovery impossible, which is the fundamental limitation of running without archiving.

The recovery catalog schema stores user-created RMAN scripts, letting you persist and reuse stored scripts across sessions. This satisfies the statement that the catalog can hold backup scripts, a capability absent from control-file-only metadata storage.

SWITCH updates the RMAN repository and control file so a datafile copy is treated as the current datafile, satisfying the need to redirect the database to a replacement file without a full restore. It changes metadata pointers only, leaving the physical copy untouched.

REPORT SCHEMA lists tablespaces, datafiles and their sizes, producing the database structure with associated files. It satisfies the stem's requirement to display both structure and datafiles, unlike REPORT OBSOLETE or LIST commands, which target backups or individual file details rather than the full schema layout.

CREATE CATALOG initialises the recovery catalog schema and its internal packages inside the nominated schema. Until this runs, the catalog contains no repository structures, so REGISTER DATABASE cannot store target metadata. It is the mandatory first step before any target registration.

Flashback logs reside in the Fast Recovery Area, the configured disk location Oracle uses for recovery-related files. This placement satisfies the storage constraint, since the FRA is where the database writes flashback data used by Flashback Database operations.

Block-level recovery allows RMAN to restore and recover a single corrupt block from a backup while the database is online. It requires the datafile number and block number, which you can obtain from V$DATABASE_BLOCK_CORRUPTION. This operation is transparent to users and does not require taking the datafile offline, making it ideal for the scenario.

VALIDATE BACKUPSET scans each backup piece and reports logical corruption without restoring data, satisfying the requirement to verify integrity. Unlike RESTORE VALIDATE, which reads datafiles, it checks the backup set itself, confirming blocks are readable and consistent. This directly answers the need to confirm backup pieces are uncorrupted.

COMPRESS applies binary compression to backup pieces, shrinking the output written to disk or tape. It satisfies the stem's focus on backup size by reducing the number of bytes stored, though it consumes extra CPU during the operation.

This policy instructs RMAN to delete archived redo logs only after two successful SBT backups, matching the stem's twice-to-tape requirement. The BACKED UP n TIMES TO DEVICE TYPE clause is the precise mechanism controlling automatic archivelog deletion.

RMAN must be connected to the target with the correct DBID so it can locate that database's backups and archived logs in the recovery catalog or control file. Without the DBID, point-in-time restore cannot identify the right backup set.

Flashback database is performed while the database is mounted.

This command configures the archived log deletion policy so that RMAN can delete archived logs from the FRA once they have been backed up at least once to the specified device type. It ensures that logs are not deleted until they are safely stored on tape, freeing FRA space while maintaining recoverability. This directly meets the requirement.

Datafiles store blocks in the source platform's endian format, so RMAN CONVERT must translate their byte order before the destination can open them. The differing endianness named in the stem is precisely what makes conversion mandatory for these files.

USING BACKUP CONTROLFILE tells RMAN that the control file itself is being restored from backup, so it must extract the datafile and redo information from that backup rather than the current control file. It is mandatory for this recovery path.

RMAN persistent configuration settings, set with CONFIGURE, are stored in the control file and optionally the recovery catalog, and they apply to every RMAN session automatically. This is RMAN's native way to persist backup retention and device policy without retyping commands, matching the requirement to store the policy across sessions.

A Recovery Catalog resides in a separate schema, so its retention is independent of the target's control_file_record_keep_time parameter, which governs only control file records. This satisfies the long-term retention constraint: metadata persists indefinitely even when control file records are overwritten and aged out.

BACKUP PLUGGABLE DATABASE restricts the backup scope to the named PDB alone, so only that pluggable database's datafiles and control file metadata are copied. This satisfies the multitenant constraint of isolating one PDB without touching the CDB root or other PDBs.

V$RECOVERY_FILE_DEST reports the Fast Recovery Area's configured location, disk quota limit, space used, and space reclaimable, directly satisfying the need to check current space usage. Querying it reveals whether the recovery area has filled to its quota, which commonly causes RMAN's inability to access it.

This command deletes archived redo logs that have already been backed up at least once to disk, which is safe because the backups preserve recoverability. It frees space in the fast recovery area immediately while honoring the principle that only backed-up logs are removed. The retention policy ensures logs still needed for recovery are retained, preventing premature deletion that would break restore capability.

Block-level media recovery uses the RECOVER ... BLOCK syntax and can be executed while the database is open, restoring and recovering only the specified block from an RMAN backup. It requires the data file to be online and the database in ARCHIVELOG mode, exactly matching this scenario where only one block in file 7 is corrupt.

RESTORE DATAFILE 7 pulls the most recent usable backup of that file from the fast recovery area or backup set, and RECOVER DATAFILE 7 applies archived and online redo to roll it forward to a consistent SCN. Because the control file is intact, RMAN knows the exact checkpoint and can perform the targeted recovery without touching other data files, minimizing downtime for the SALES tablespace.

This sequence mounts the database, restores all data files from backup, recovers the database up to the specified SCN, and then opens with RESETLOGS. Incomplete recovery requires the database to be mounted, and after recovery, RESETLOGS is mandatory to reset the online redo logs and create a new incarnation.

Marking a block corrupt during an RMAN backup records it in V$DATABASE_BLOCK_CORRUPTION, satisfying the need to track physical corruption for later recovery. RMAN populates this view automatically, so subsequent BACKUP VALIDATE or RECOVER CORRUPTION operations can target the affected blocks without rescanning the entire datafile.

The FROM ACTIVE DATABASE clause copies datafiles directly from the source database's memory and online files over the network, bypassing backup media entirely. This eliminates the restore phase, satisfying the scenario's need for speed, since no backup retrieval or staging is required before duplication proceeds.

Connecting RMAN to the standby and the recovery catalog lets backups taken on the standby be recorded directly in the shared catalog, satisfying the offload requirement. The standby must be registered as its own target so its backup metadata is captured and visible for restore operations.

CONFIGURE CONTROLFILE AUTOBACKUP ON makes RMAN write the control file and server parameter file automatically after every structural change, such as adding a datafile or tablespace. This directly satisfies the stem's requirement for automatic backup on database structure modification, without manual intervention.

The auxiliary instance is a separate, temporary Oracle instance where the target tablespaces' datafiles are restored and recovered to the chosen point in time, isolating the recovery work from the production database before the recovered tablespaces are exported and plugged back in.

RECOVER DATABASE applies archived redo logs and any available incremental backups to the restored data files, rolling them forward to a consistent SCN. This is exactly the step that consumes the archived logs in the fast recovery area and completes media recovery, making it the correct command after the restore.

Enabling row movement lets Oracle reassign a row's physical location during undo-based restoration, which Flashback Table requires to return dropped rows to their original blocks. Without it, the command fails with ORA-08189, so row movement is the mandatory prerequisite the stem demands before execution.

Multiplexing writes identical copies of the control file to separate locations, so one disk's failure leaves a usable copy for instance recovery. This satisfies the availability requirement implied by running in ARCHIVELOG mode, where control file loss otherwise halts recovery.

DELETE OBSOLETE removes backups and archived redo logs that fall outside the configured retention policy, satisfying the requirement to purge unneeded backups. It evaluates the current retention configuration rather than deleting everything, unlike DELETE BACKUP or DELETE EXPIRED.

This sequence starts the instance in mount mode, restores the database from backup, performs incomplete recovery to the specified time using archived logs, and then opens the database with RESETLOGS. This is the standard procedure for point-in-time recovery. The RESETLOGS is required after incomplete recovery to reset the online redo logs and start a new incarnation.

With the control file lost, the instance starts NOMOUNT, restores the control file from autobackup, mounts, restores datafiles, recovers, then opens with RESETLOGS. This sequence satisfies the requirement to restore and recover after control-file loss.

RMAN uses the Media Management Library (MML) API to interface with third-party media managers. The media manager vendor supplies a shared library (e.g., libobk.so on Linux) that must be installed and linked with Oracle. This library allows RMAN to send backup and restore requests to the media manager, which then handles tape operations.

RECOVER TABLE in RMAN allows you to recover a table to a point in time before the drop, even if the recycle bin was purged. It creates an auxiliary instance, restores the necessary data files and archived logs, and extracts the table. This is the most efficient RMAN method for table recovery when Flashback Drop is unavailable.

RECOVER TABLE uses Data Pump to export the recovered table from the auxiliary instance and import it into the target database, restoring the table's data and metadata. This satisfies the requirement that the table be returned to its original schema automatically.

RMAN CONVERT DATABASE is only supported when the source and target platforms have identical endianness.

This command restores the data file from the RMAN backup and then applies archived redo logs to bring it up to date. It is the correct procedure for recovering a data file from a backup. The data file must be offline before restoration, and after recovery it can be brought online. This command works with tape backups as long as the media manager is configured.

Without a Fast Recovery Area, RMAN writes backups to the current working directory of the RMAN session by default, since no other destination is configured. This satisfies the stem's constraint of no FRA being set, making the session's working directory the effective default location.

BACKUP ARCHIVELOG NOT BACKED UP restricts the backup to archived redo log files that have never been backed up. DELETE INPUT then removes each input file from disk after it has been successfully backed up. This matches the scenario exactly, ensuring only new logs are backed up and the originals are removed to free space.

Flashback Database uses flashback logs to return the entire database to an earlier point in time, reversing block-level changes without a full restore. This whole-database rewind is its primary purpose, distinct from object-level or row-level flashback features.

This command enables automatic backup of the control file and SPFILE whenever a backup or structural change occurs. It ensures that you have a current control file backup, which is essential for recovery. The backup is stored in the fast recovery area or a configured location. This is the correct setting to meet the requirement.

BACKUP AS COPY writes a byte-for-byte identical image of each datafile rather than a proprietary backup piece, so the output is usable directly as a datafile. This satisfies the stem's requirement that the output be an exact image copy.

Taking the tablespace offline is mandatory before recovery begins, because Oracle cannot restore and recover datafiles while they remain open to users. Offlining the tablespace quiesces I/O against its datafiles, allowing the restore and subsequent media recovery to proceed without corrupting the online database.

A recovery catalog is a separate schema holding RMAN metadata for many databases, so a single catalogue server can register and manage backups across the whole estate. This satisfies the benefit of centralised metadata, unlike the control file, which is tied to one database.

V$RMAN_STATUS is the dynamic performance view that records every RMAN job and its state, so querying it lists all current and completed backup operations with their status, satisfying the requirement to check all RMAN backup jobs.