Backup And Recovery practice questions

RECOVER TABLE HR.EMPLOYEES UNTIL SCN 12345;

RECOVER TABLE with UNTIL SCN performs table-level point-in-time recovery, restoring the named table to the specified SCN from a backup. The syntax names the schema-qualified table and the target SCN, matching the stem's requirement precisely.

CONFIGURE BACKUP OPTIMIZATION ON;

Backup optimisation skips datafiles whose identical content is already backed up, based on RMAN's change tracking of block headers. On Exadata this avoids re-reading unchanged files, directly cutting I/O and elapsed time during the backup operation the stem asks about.

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

Compressed backupsets reduce the volume of data written to disk by compressing blocks before they leave the database. On Exadata, where backup throughput is often bounded by cell and disk bandwidth, this shrinks the write payload and shortens the backup window.

RMAN> CONVERT DATAFILE '...' TO PLATFORM '...' FROM PLATFORM '...';

CONVERT DATAFILE translates datafile byte order between platforms, satisfying the endianness constraint. Specifying both FROM PLATFORM and TO PLATFORM lets RMAN rewrite the blocks into the target platform's format, which is required when the source and destination architectures differ in endianness.

CONVERT TABLESPACE ... TO PLATFORM 'Microsoft Windows x86 64-bit';

This correctly identifies the destination platform endian format.

The auxiliary instance must have enough disk space to hold the tablespace being recovered.

TSPITR requires an auxiliary instance to clone the database, then recover only the affected tablespace to the target SCN before exporting it back. Sufficient disk space is essential because the auxiliary instance materialises the full datafile copy of that tablespace, satisfying the storage constraint the recovery process demands.

Ensure the database is in ARCHIVELOG mode.

Flashback Database relies on archived redo logs to reconstruct past block images, so the database must run in ARCHIVELOG mode; without it, flashback logs alone cannot restore the database to an earlier point in time.

Set the DB_FLASHBACK_RETENTION_TARGET parameter.

Setting DB_FLASHBACK_RETENTION_TARGET defines how far back the database can be flashed, satisfying the retention requirement for Flashback Database. It specifies the target recovery window in minutes, guiding automatic retention of flashback logs within the fast recovery area, and must be configured alongside enabling flashback logging.

A Fast Recovery Area (FRA) must be configured.

Flashback Database relies on flashback logs stored exclusively in the Fast Recovery Area, so an FRA must be configured before the feature can be enabled. Without it, Oracle cannot write or retain the flashback logs needed to rewind the database, directly satisfying the stem's storage prerequisite.

Database must be in ARCHIVELOG mode.

Required to record changes.

Flashback logs must be enabled.

Flashback logs capture before-images of changed blocks, enabling block-level rewind without restoring backups. The stem demands the three prerequisites for Flashback Database, and without these logs the database cannot rewind to a past SCN or timestamp.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

Configuring disk parallelism to 4 lets RMAN allocate four channels, reading and writing backup pieces concurrently. In a high-transaction environment this saturates available I/O bandwidth, shortening backup windows while the database continues serving transactional load.

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Enabling block change tracking records modified blocks in a change tracking file, letting RMAN read only changed blocks during incremental backups. This dramatically reduces I/O and backup duration in high-transaction environments where full scans would be prohibitively slow.

BACKUP DATABASE

BACKUP DATABASE against the root container automatically includes every plugged-in PDB, satisfying the requirement that one command covers the whole CDB. RMAN treats the CDB as a single unit here, so no separate per-PDB backup commands are needed.

The RMAN CONVERT command must be used if endianness differs.

When source and target platforms use different endianness, the data files' byte order must be converted; RMAN CONVERT performs this transformation. Identical endianness needs no conversion, so this condition applies specifically to mismatched platforms in the migration.

The source tablespace must be set to READ ONLY.

Transportable tablespaces require the source tablespace to be READ ONLY before metadata export, guaranteeing data files remain unchanged during the operation. This ensures the copied files stay consistent with the exported metadata at the target database.

The compatibility level must be at least 11.0.0.

Cross-platform transportable tablespaces require the source database compatibility to be 11.0.0 or higher, since the datafile format and endianness conversion metadata introduced in that release are essential. Setting compatibility below 11.0.0 prevents RMAN from reading the transported files on the destination platform, so this condition must be satisfied.

Applying archived redo logs.

Recovery applies archived redo logs to roll the restored datafiles forward from their backup SCN to the target point, redo that is no longer present in the online logs. This is the core roll-forward step the RECOVER command performs after restore.

Applying the online redo logs.

Applying online redo logs is a core RECOVER function, rolling forward committed changes recorded after the restored data file's checkpoint. This satisfies the stem's requirement to bring the file current, since archived logs alone cannot capture transactions still resident in the online redo logs at failure time.

Verifying the headers of the datafiles.

Verifying datafile headers is an integral part of RECOVER, which checks each file's header against the control file to confirm it belongs to the correct database and is consistent before applying redo. This satisfies the stem's requirement by ensuring only valid, matching datafiles proceed through recovery.

SET UNTIL TIME '2023-10-10:10:00:00'

SET UNTIL TIME establishes the upper time limit for RMAN's point-in-time recovery, restoring the database to the specified timestamp. It satisfies the stem's requirement to set a target time before issuing RESTORE and RECOVER. The quoted format 'YYYY-MM-DD:HH24:MI:SS' matches Oracle's expected date literal syntax.

A backup configuration file defining the bucket and compartment.

The config file provides the necessary path information for OCI storage.

A wallet containing the OCI credentials must be created.

RMAN reaches OCI Object Storage through the SBT interface, which authenticates using an Oracle Wallet holding the OCI user credentials. Without this wallet, the OCI library cannot sign requests, so the backup fails before any data transfers.

The SBT_LIBRARY must be configured to point to the OCI library.

Configuring SBT_LIBRARY to reference the OCI Cloud Storage library (libociicus.so) lets RMAN's media management layer communicate with OCI Object Storage, satisfying the requirement for a valid SBT channel. Without this library, RMAN cannot allocate the SBT channel needed to write backups directly to the bucket.

In the Fast Recovery Area (FRA).

The block change tracking file is created in the Fast Recovery Area by default when BCT is enabled, unless an explicit filename is supplied. Storing it in the FRA keeps the tracking file with other recovery-related files, simplifying management and backup.

BACKUP DATABASE SKIP READONLY

BACKUP DATABASE SKIP READONLY omits read-only tablespaces from the backup set, directly satisfying the requirement to exclude them. Unlike SKIP INACCESSIBLE, which handles offline data files, this clause targets tablespace read-only status, reducing backup size and time while preserving the rest of the database.

CONFIGURE MAXSETSIZE

This is the correct RMAN command.

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

REDUNDANCY 3 is a valid RMAN retention policy, keeping three complete backups of each datafile regardless of age. It is one of the two retention configurations RMAN accepts, the other being a recovery window measured in days.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

RECOVERY WINDOW OF 7 DAYS is a valid RMAN retention policy, retaining backups and archived logs needed to restore the database to any point within the past seven days. It is the time-based alternative to redundancy-based retention.

Transport the converted file to the target.

After CONVERT produces the platform-appropriate copy of the data file, that converted file must be physically moved to the target host so it can be integrated. This satisfies the migration's transfer requirement between source and destination platforms.

Perform a BACKUP AS COPY of the datafile.

RMAN must first create an image copy of the data file using BACKUP AS COPY, since CONVERT operates on a copy rather than the live data file. This satisfies the prerequisite of having a source copy available for conversion.

Run the CONVERT command on the source.

Running CONVERT on the source database performs the actual tablespace or data file conversion, translating the file's internal format to the destination platform's endianness. This satisfies the migration's core requirement: producing a transportable, platform-compatible copy before transfer, rather than converting after the file has already been moved to the target host.

Cumulative

Cumulative is a valid incremental backup type.

Differential

Differential (a type of incremental) is valid.

Incremental

Incremental is a core backup type.

LIST BACKUP

LIST BACKUP queries the recovery catalog and reports all backup sets and image copies registered for the connected target database, satisfying the requirement to enumerate backups. It draws on catalog metadata rather than the control file, so it lists backups even when control file records are gone.