Parallel Media Recovery in Oracle AI Database 26ai

How Parallel Media Recovery Works

The supplied diagram separates recovery into three conceptual activities: reading redo, dispatching work, and applying changes. These activities explain where concurrency helps and where a bottleneck can limit the whole operation.

Read the Required Redo

Recovery processes the redo needed to advance the files from their existing state toward the recovery target. The diagram's ARC_72, ARC_73, and ARC_74 are example archive names, not files to enter in a command. Online redo may also be needed and used when available. Actual log names, sequences, and requirements come from the database and the recovery operation.

Consider a restored application datafile whose backup predates several hours of business activity. Restoring it returns the backed-up blocks to storage. Recovery then brings those blocks forward using the available recovery resources. A file that is already usable and merely needs redo does not need to be overwritten just to enable parallel processing.

Coordinate and Dispatch the Work

Oracle coordinates the recovery work and distributes changes for application to blocks. This is the meaning of the dispatch stage. You initiate the recovery through one appropriate command; you do not reproduce the diagram by opening several client windows and independently recovering overlapping sets of files.

Ordering still matters. If one block has been changed repeatedly, its recovered contents must reflect the required sequence of changes. The diagram therefore represents coordinated concurrency, not permission for unrelated workers to overwrite the same block without synchronization.

Apply Changes to Data Blocks

The unit of useful parallel work is not necessarily an entire datafile. Different workers can process different blocks in the same file. Consequently, a database with one large affected datafile can still contain work that is suitable for parallel media recovery. Conversely, many small files do not guarantee a large performance improvement.

The four output cylinders represent recovered datafiles on filesystem or Oracle ASM storage. They are not four dedicated disks or four required worker assignments. Read the image as an explanation of responsibilities rather than a specification for file placement or an exact process diagram.

Choose a Recovery Degree in RMAN

For the whole-CDB example, connect RMAN to the CDB root as an authorized common user with SYSBACKUP or SYSDBA. Verify the target before submitting the command. The following choices are alternatives for an appropriate recovery operation, not a sequence to execute one after another.

Use the Default Automatic Degree

RMAN enables parallel media recovery by default. Oracle derives the degree from CPU_COUNT. The ordinary command is:

RECOVER DATABASE;

Specify an Explicit Degree

To request an illustrative degree of two, use:

RECOVER DATABASE PARALLEL 2;

The integer is not a promise of exactly that many operating-system processes. Oracle's reference allows one or two execution servers per parallel thread.

Request Serial Recovery

For a diagnosed requirement or a controlled comparison, the serial alternative is:

RECOVER DATABASE NOPARALLEL;

These are RMAN commands. Do not substitute the legacy PARALLEL (DEGREE 2) form into these examples. See the Oracle 26ai RMAN RECOVER reference for command syntax and parallel-degree behavior.

Separate Recovery Workers from Other Parallelism

Prepare the Recovery Operation Before Tuning It

For this example, the CDB must be in the state required by the selected whole-database recovery procedure. If the instance is down, starting it in MOUNT may be the next step. If a failed open has already left it mounted, continue from that state rather than blindly issuing another startup command.

Use a short preparation checklist that records the facts needed for this particular recovery:

• Target: Verify the database identity and CDB-root connection. A familiar service name alone should not substitute for checking the actual target.
• Scope: Identify which files need recovery and whether any must first be restored or relocated.
• Storage: Resolve the underlying access or media problem. Recovery needs reliable destinations as well as readable inputs.
• Resources: Confirm that the chosen backup and recovery chain is available, including decryption access where required.
• Outcome: Record whether the plan is complete recovery or a different procedure with a specified boundary.

These checks are about correctness. A larger recovery degree cannot compensate for choosing the wrong database or a gap in the required recovery chain. If recovery reports an unavailable log, investigate that requirement before treating the delay as a parallelism problem.

The mounted-CDB example does not mean that every media-recovery operation requires the entire database to be unavailable. The previous lesson discussed isolating eligible application datafiles while unaffected data remains accessible. The appropriate file and container states depend on that recovery scope. Do not expand a single-file incident into a whole-database restore solely to use the syntax shown here.

Assess Whether More Workers Will Help

Oracle's performance guidance emphasizes finding the limiting resource before tuning. A restore can be constrained by its backup source, processing, or destination. Additional concurrency cannot raise throughput beyond the capacity of the resource that is already saturated. See Tuning RMAN Performance for the underlying bottleneck approach.

Apply that reasoning to the diagram. If redo cannot be supplied quickly enough, workers may wait for input. If data-block I/O is the constraint, adding workers may produce more waiting rather than more completed work. Available CPU, memory pressure, coordination overhead, asynchronous I/O behavior, and competing workloads also influence the result.

As an illustrative diagnosis, imagine recovery is reading from a congested shared storage system while another job performs a large transfer. A degree increase does not remove that competing traffic. First establish whether the transfer is contributing to the delay and whether it can be rescheduled. If recovery instead has substantial independent block work and spare processing and I/O capacity, an explicit-degree experiment may be useful.

Avoid a fixed rule such as one or two recovery workers per disk. A filesystem path, virtual disk, ASM disk group, and physical device are not interchangeable measures of capacity. Two differently named volumes may share the same underlying resources. Document the storage arrangement and measured behavior rather than deriving a worker count from directory names.

The objective is a shorter, repeatable recovery with acceptable resource use. Maximum CPU utilization, a large process count, or a higher configured degree is not itself an improvement. The default is a sensible baseline to measure before introducing an explicit setting.

Monitor Recovery from a Separate Session

SELECT start_time, type, item, sofar, total, units
FROM v$recovery_progress
WHERE type = 'MEDIA RECOVERY';

Compare Settings in a Controlled Recovery Test

Recovery changes the files it processes. Running a second command after the first recovery completes does not reproduce the first workload. A quick second run therefore cannot establish that its degree was faster. Plan comparisons on an isolated recovery test system with equivalent starting files and the same intended recovery work.

Record the backup used, recovery boundary, available resources, competing activity, and elapsed time for each phase. Change one relevant factor at a time where practical. Include the cost of restoring the test's starting state in the test plan, but keep it separate from the redo-apply measurement you are comparing.

For example, a useful test question is whether an explicit degree reduces the redo-apply phase for a representative restore without creating unacceptable storage contention. A poor test question is simply whether a larger number can be entered successfully. Successful command parsing establishes syntax, not a performance benefit or recoverability.

Use the resulting evidence to update the recovery runbook. Record when an explicit degree was beneficial, the conditions under which it was tested, and when the automatic choice should remain in use. Reassess that decision after significant changes to the storage or processing environment.

Verify the Result Before Returning Service

Confirm that recovery completed successfully and resolve all outstanding errors before proceeding. Review the affected files' recovery requirements and the relevant alert-log entries. Then follow the opening, PDB, service, and application checks specified by the selected recovery procedure.

For the complete-recovery example using a current control file, normal opening is appropriate once its requirements are satisfied. Parallel execution alone never creates a requirement to issue OPEN RESETLOGS. Backup-control-file and point-in-time procedures have their own opening requirements and should follow their corresponding recovery instructions.

Finally, validate the application's ability to read the recovered data and record the actual outage duration. This distinguishes database recovery completion from restoration of the business service. Use both measurements when deciding whether a future tuning change would materially improve availability.

The next lesson demonstrates how to reconstruct a lost or corrupted control file.

Minimize Database Downtime - Quiz