Execute and Verify RMAN Backup Scripts in Oracle 26ai

A backup script becomes operational only when it runs against the intended database, produces the expected backup pieces, and leaves evidence that you can inspect. The previous lesson introduced FORMAT templates and a command file named full_database.rman. This lesson explains how to execute that file, run a stored catalog script when appropriate, capture the result, and evaluate backup readiness before scheduling recurring work.

A command file contains RMAN statements on the client filesystem. A stored script contains statements in a recovery catalog. An operating-system wrapper launches RMAN and handles paths, log names, and process status. These are separate objects. In particular, EXECUTE SCRIPT invokes an RMAN catalog script, not a PL/SQL procedure. A script name such as backup_acct does not identify an operating-system file unless you explicitly created one with that name.

Confirm the target and execution prerequisites

Before submitting a backup, confirm the database name, DBID, and connection scope. A CDB-wide job needs a connection to the CDB root. A connection to an individual PDB has a narrower scope. Use an appropriately privileged account, such as a common account granted SYSBACKUP for this purpose, or an authorized local operating-system authentication setup. Keep passwords out of command files and wrappers.

CONNECT TARGET "c##backup_admin@prod AS SYSBACKUP";
SHOW ALL;

This illustrative connection prompts for the target password. Replace the account and service with approved values; do not copy an example service name into a production job without checking what it resolves to. Review the connection banner and target identity before proceeding. SHOW ALL displays persistent RMAN configuration, including relevant device, retention, and control file autobackup settings.

Confirm that the target is in ARCHIVELOG mode for the online database-plus-archived-log backup shown here. In a separate authorized SQL session, inspect V$DATABASE and the current container as appropriate. A NOARCHIVELOG database requires a different consistent-backup procedure. A syntax check cannot determine whether the database is in the right state.

Also inspect the two sides of the filesystem boundary. The RMAN client needs a readable command file and a writable log directory. Target server processes need access to the disk backup directory. The examples use Windows client paths and Unix server backup paths deliberately. Replace the latter if your database host uses another filesystem. Ensure capacity and permissions before execution; FORMAT does not create directories.

Review the command file before launching it

Use a known, reviewed version of the file rather than whichever similarly named script happens to be in the current directory. The following example corresponds to the previous lesson's manual DISK channel workflow. Save it as plain text without RMAN prompt prefixes, line numbers, or shell commands.

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;

  BACKUP AS BACKUPSET
    DATABASE FORMAT '/backup/rman/db_%d_%T_%U.bkp'
    PLUS ARCHIVELOG FORMAT '/backup/rman/arch_%d_%T_%U.bkp';

  BACKUP CURRENT CONTROLFILE
    FORMAT '/backup/rman/cf_%d_%T_%U.bkp';

  RELEASE CHANNEL c1;
}
EXIT;

The backup channel is a database server session that performs backup I/O. Because this block allocates its channel manually, its BACKUP statements do not also request automatic channel selection with DEVICE TYPE. The ordinary control file backup has its own FORMAT; it is separate from control file autobackup configuration and the protection of an SPFILE. Review those recovery-file requirements as part of the wider policy.

For backup pieces, %U supplies a unique name incorporating set, piece, and copy information. %d identifies the database and %T supplies a date. The three prefixes make the output categories recognizable, but repository records identify the actual contents. This starter performs no log deletion and does not exclude read-only data files.

Check syntax, then run with an explicit log

First ask RMAN to parse the file without performing a backup. From PowerShell, use the RMAN executable belonging to the intended Oracle home. The path below is illustrative and must be adjusted to the installed location.

$rmanExe = 'C:\Oracle\product\26ai\dbhome_1\bin\rman.exe'
$commandFile = 'C:\rman\scripts\full_database.rman'
& $rmanExe CHECKSYNTAX "CMDFILE=$commandFile"
$syntaxExit = $LASTEXITCODE
if ($syntaxExit -ne 0) {
    throw "RMAN syntax check failed with exit code $syntaxExit"
}

CHECKSYNTAX establishes parser acceptance. It does not authenticate a target, verify a catalog script's contents, test the backup directory, or prove that the requested data can be read. After that preliminary check and an operational review, a local authentication execution wrapper could look like this:

$rmanExe = 'C:\Oracle\product\26ai\dbhome_1\bin\rman.exe'
$commandFile = 'C:\rman\scripts\full_database.rman'
$logDirectory = 'C:\rman\logs'
if (-not (Test-Path -LiteralPath $rmanExe -PathType Leaf)) {
    throw 'RMAN executable not found'
}
if (-not (Test-Path -LiteralPath $commandFile -PathType Leaf)) {
    throw 'RMAN command file not found'
}
if (-not (Test-Path -LiteralPath $logDirectory -PathType Container)) {
    throw 'RMAN log directory not found'
}
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss-fff'
$logFile = Join-Path $logDirectory "full_database_$stamp.log"
if (Test-Path -LiteralPath $logFile) { throw 'Log name already exists' }
& $rmanExe TARGET / "CMDFILE=$commandFile" "LOG=$logFile"
$backupExit = $LASTEXITCODE
if ($backupExit -ne 0) {
    throw "RMAN failed with exit code $backupExit; inspect $logFile"
}
if (-not (Test-Path -LiteralPath $logFile -PathType Leaf)) {
    throw 'Expected RMAN log is missing; inspect console output'
}

This wrapper captures the native process exit code immediately. TARGET / assumes authorized local operating-system authentication; it does not specify a remote target. A remote job needs the appropriate target connection and an approved unattended credential mechanism. An interactive password prompt is unsuitable for a scheduler that cannot answer it.

Check the full log even after a zero exit code. LOG normally directs command output into the named file, so the console can appear quiet. If RMAN cannot open that file, it can fall back to standard output rather than terminate. The existence check above catches a missing log, but it does not establish that its contents show complete success. Retain console output when diagnosing such a failure.

CMDFILE supplied at startup parses the file before executing its statements. Runtime failures can still occur after earlier work has completed. RUN groups commands into a job; it is not a database transaction that rolls completed backups back. After failure, inspect which sets completed and which outputs are usable before retrying. Do not remove unfamiliar backup pieces merely to make a directory look tidy.

Choose command-file or catalog-script execution

From an already connected interactive RMAN session, a command file can be invoked with an at sign:

@'C:\rman\scripts\full_database.rman'

This uses the current session's target and repository connections. At the interactive prompt, RMAN reads and executes file commands sequentially; do not assume it provides the same whole-file startup parsing behavior as CMDFILE. An EXIT statement in the file closes the RMAN client. For reusable interactive fragments, decide deliberately whether they should contain EXIT.

A catalog stored script instead needs a connection to the recovery catalog and the appropriate target association. Connect using approved credentials, inspect available names, and print the selected script before execution:

CONNECT CATALOG rco@catdb;
LIST SCRIPT NAMES;
PRINT SCRIPT full_disk_backup;
RUN { EXECUTE SCRIPT full_disk_backup; }

The catalog connection prompts for its password. It records metadata and stores the script; it is not a backup channel. EXECUTE SCRIPT inserts stored commands into the surrounding RUN block. If the stored body allocates channels, avoid allocating those channels again in the caller. Confirm that its commands cover the intended scope: the shorter full_disk_backup example from the previous lesson illustrates database naming and does not necessarily include every archived-log or recovery-file action in the command file above.

Standard scripts can reduce duplication, but their names are not enough evidence of their behavior. Review changes to a shared script because they affect subsequent callers. Avoid channel-only helpers with hidden allocation assumptions. Keep a documented version of the complete job so an operator can identify exactly what ran when investigating a failed backup.

Back up archived redo without treating age as a deletion policy

Archived redo supplies changes needed to recover an online database backup. RMAN uses repository metadata to identify relevant archived logs; BACKUP ARCHIVELOG ALL is not simply a scan of one named operating-system directory. Do not describe it as backing up an online redo log while the database is still writing to that log.

For a separate archived-log job, the following example archives the current redo and then backs up logs without an existing backup on the selected device type. It assumes suitable automatic DISK channels; change that assumption explicitly if using a configured SBT media manager.

SQL "ALTER SYSTEM ARCHIVE LOG CURRENT";
BACKUP ARCHIVELOG ALL
  NOT BACKED UP 1 TIMES
  FORMAT '/backup/rman/arch_%d_%T_%U.bkp';

Note the SQL spelling ARCHIVE LOG. The main DATABASE PLUS ARCHIVELOG command already includes archive operations as part of its backup sequence, so an extra standalone job should serve a defined policy rather than duplicate work accidentally. Review log generation rate and the acceptable recovery point when choosing its frequency.

Log selection can use time, sequence, or thread criteria. Sequence numbers need their thread context in a database with multiple redo threads. A selection expression chooses input; it does not demonstrate that every earlier log is unnecessary. If time expressions use SYSDATE, confirm the relevant Oracle 26ai time-zone behavior and the intended boundary rather than assuming the client's clock controls selection.

DELETE INPUT removes the input copy backed up successfully; DELETE ALL INPUT can remove all matching copies of the archived logs across destinations. Both are consequential maintenance choices. Review required backup copies, standby transport and apply requirements, and the configured archived-log deletion policy before using them. The basic execution example deliberately keeps backup and deletion separate.

Retention policy, availability, and log deletion policy answer different questions. An obsolete backup is no longer required by the applicable retention rules. An expired record indicates that CROSSCHECK could not find the corresponding file or media object; it does not mean the backup is old enough to delete. CROSSCHECK updates availability metadata and is not a complete content validation. Fast recovery area reclamation also follows its own rules; RMAN does not indiscriminately clean every disk or tape destination after a backup.

Execute the intended incremental strategy

Oracle 26ai RMAN incremental backups use levels 0 and 1. Level 0 supplies the baseline for an incremental strategy. An ordinary full backup can contain similar data but does not become the parent of subsequent incremental backups. Legacy examples involving level 2 do not describe the current model.

BACKUP INCREMENTAL LEVEL 0
  FORMAT '/backup/rman/l0_%d_%T_%U.bkp' DATABASE;

BACKUP INCREMENTAL LEVEL 1
  FORMAT '/backup/rman/l1_%d_%T_%U.bkp' DATABASE;

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE
  FORMAT '/backup/rman/l1c_%d_%T_%U.bkp' DATABASE;

These are separate strategy examples, not three commands to run together in every daily job. Differential level 1, the default, captures blocks changed since the most recent level 0 or level 1 backup. Cumulative level 1 captures changes since the most recent level 0. Retain the required baseline, intervening increments where applicable, and redo for the intended recovery target.

Incremental backups work at the block level. If block change tracking is enabled and applicable, it can reduce scanning for incremental backups. It does not eliminate the need to verify outputs or keep archived logs. Select the strategy using measured backup volume and recovery requirements, and test its restore sequence instead of promising that incremental backups always make both backup and recovery faster.

Verify execution, coverage, and restore readiness

Evaluate the result at several levels. First inspect the process status and full RMAN log for errors and warnings. Next confirm that the target and output handles match the approved job. Finally inspect backup records and perform the validation appropriate to the recovery plan.

LIST BACKUP SUMMARY;
LIST BACKUP OF DATABASE;
LIST BACKUP OF ARCHIVELOG ALL;
LIST BACKUP OF CONTROLFILE;

Compare recorded piece handles with the expected server directory or media-manager destination. A filename containing today's date is not proof of its contents, and a completed database backup does not establish that the required redo range remains available. Keep evidence of the script version, target DBID, execution time, return code, and log location with the job record.

In an authorized SQL session, the backup-job view provides another operational check:

SELECT session_key, input_type, status, start_time, end_time
FROM v$rman_backup_job_details
ORDER BY start_time DESC
FETCH FIRST 10 ROWS ONLY;

Match the displayed job with your execution rather than assuming the newest row must be yours. A job status supports execution review; it does not prove that the backup storage will be available during a disaster or that an application can recover to the required point.

RESTORE DATABASE PREVIEW;
RESTORE DATABASE VALIDATE;

PREVIEW reports the backups selected for a restore without restoring data files. VALIDATE reads the selected backup contents without writing restored files, and therefore still consumes real I/O and media resources. Plan that workload. Neither substitutes for an isolated restore-and-recovery exercise that checks redo availability, recovery files, credentials or keystores, external dependencies, and application behavior.

Use current RMAN capabilities and keep an execution record

RMAN integrates backup metadata, database-aware block handling, and recovery operations. Ordinary RMAN online backups do not require the manual BEGIN BACKUP procedure used in conventional user-managed file copying. RMAN can report block corruption and supports validation, incremental backups, encryption options, and database duplication. Each capability still needs appropriate configuration and operational review.

Data Recovery Advisor is desupported in Oracle AI Database 26ai. Do not build the job procedure around LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, or CHANGE FAILURE. Likewise, do not equate encryption support with automatic key availability during recovery, or backup automation with maintenance that needs no operator oversight.

Before scheduling, complete a supervised successful execution and review its evidence. The scheduler should supply the correct Oracle home, account, environment, script version, and monitoring. Prevent overlapping jobs where they would contend for resources or confuse the recovery policy. Send failures through the site's established operational process and retain usable logs for investigation.

Consult Oracle's RMAN invocation reference, EXECUTE SCRIPT reference, and BACKUP reference for syntax. The RESTORE reference explains validation, while the current command overview records the DRA desupport. The examples here are instructional; no successful execution or recovery is implied. The next lesson examines control-file characteristics, separate from FORMAT filename naming.