RMAN FORMAT Parameter and Backup Scripts in Oracle 26ai

The RMAN FORMAT clause supplies a template for a backup output name. For a disk backup, that template can include the directory and filename of a backup piece. A useful template identifies the database and date while retaining a system-generated unique component. This lesson builds on command files from the previous lesson: you will choose a destination, understand substitution variables, and assemble a script whose database, archived-log, and control file backups have recognizable names.

Keep naming separate from the backup representation. AS BACKUPSET selects an RMAN backup set; AS COPY selects an image copy where supported. Adding .bkp, .ctl, or .tar to a name does not convert its contents. FORMAT cannot invoke an operating-system archive command. A string such as tar:cvf /backup/pets.tar is not an RMAN method for creating a compressed TAR archive. RMAN produces files that its own backup and recovery commands understand.

Choose where the backup pieces belong

Start with the storage decision rather than the filename. For an explicit disk destination, arrange a directory on storage accessible to the target database server. The operating-system account running the database server processes must be able to write there. Confirm available capacity, permissions, and the intended protection of that storage. RMAN does not create a missing directory merely because the directory appears in FORMAT.

The RMAN client and database server may run on different computers. A Windows path used for CMDFILE or LOG is a client-side path. A Unix path in a disk FORMAT is interpreted by the target server processes. Therefore, a Windows client can submit a command file that writes backup pieces under /backup/rman on a Unix database host. Copying that Unix path into a Windows database deployment would require an appropriate replacement.

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

This example uses automatic channels, assuming a suitable DISK channel configuration. It creates one or more backup pieces, rather than promising a single file. Every piece receives a name derived from the template. The template remains fixed in the command, but its substitution variables change according to the backup operation. Use a directory appropriate to your target host; the path above is illustrative.

FORMAT does not expand operating-system environment variables. A string containing $BACKUP_DIR is not automatically translated into that variable's value. Generate a reviewed command file before invoking RMAN if your operating-system wrapper needs to choose a directory dynamically. Keep shell substitution and RMAN substitution separate so that the submitted template can be inspected reliably.

Use substitution variables that identify each piece

RMAN substitution variables are case-sensitive. A date or database name makes an output readable, but neither alone guarantees uniqueness. A full backup can generate multiple sets and pieces, and two jobs can run on the same day. Retaining %U avoids building a naming scheme that assumes only one output per operation.

For backup pieces, %U is shorthand for %u_%p_%c. This explains why an old template containing only %u should not be copied uncritically: it omits distinctions needed when a set has multiple pieces or copies. Image copies use a different expansion for %U, so the backup-piece shorthand should not be presented as its universal definition.

A template such as db_%d_%I_%T_%U.bkp combines readable context with unique naming. Those characters are useful operational labels, but the RMAN repository remains authoritative for the file's contents. Do not infer the complete backup inventory, checkpoint, or recovery coverage from the filename alone. Also avoid renaming pieces with a file manager after RMAN records their handles; that breaks the correspondence between recorded locations and files.

Understand which FORMAT takes precedence

A naming template can be attached to a particular backup specification, to the BACKUP command, to a manually allocated channel, or to a persistent channel configuration. When several apply, RMAN uses the most specific applicable setting. In order of precedence, these are the backup specification, BACKUP command, ALLOCATE CHANNEL, and CONFIGURE CHANNEL.

A specification-level FORMAT is useful when one command backs up both database files and archived logs. The lesson's script assigns a database template after DATABASE and a different template after PLUS ARCHIVELOG. A command-level template placed before DATABASE supplies a broader default. A channel template is useful when jobs should inherit a common destination without repeating it in every command.

CONFIGURE CHANNEL DEVICE TYPE DISK
  FORMAT '/backup/rman/%d_%T_%U.bkp';
SHOW ALL;

This is a persistent configuration example, not a required preliminary action for the script below. Review existing settings before changing them, because other jobs for that target can inherit the change. The main script instead uses explicit naming for its own backup specifications. Running SHOW ALL lets you see persistent settings, but a successful display is not evidence that the output directory is writable.

The fast recovery area provides another destination strategy. To use its normal managed naming for disk backups, avoid explicit FORMAT settings on the relevant BACKUP command or channel. An explicit filesystem FORMAT can direct pieces outside that strategy even if a fast recovery area is configured. Do not assume every file under a directory is automatically managed by the fast recovery area merely because its directory looks familiar.

Create a command file with explicit output names

The following command file illustrates a full database backup with archived logs and a separate current control file backup. It assumes a target suitable for an online backup in ARCHIVELOG mode, an existing writable server directory, and an authorized target connection. For a CDB-wide backup, connect to the CDB root using an appropriately privileged account; a PDB-only connection has a different scope.

Save the commands as a plain-text file such as C:\rman\scripts\full_database.rman on the RMAN client. The file contains RMAN commands, not console prompts or operating-system commands. Keep single percent characters in this file because they belong to RMAN. If you generate the same text inside a Windows batch file, account for that shell's percent expansion separately.

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 manually allocated DISK channel performs the work inside RUN. Consequently, the BACKUP commands do not also specify DEVICE TYPE, which is used for automatic channel selection and is invalid with manually allocated channels. The distinct prefixes help an operator recognize intended output categories without replacing repository inspection.

PLUS ARCHIVELOG adds archived redo log backup work around the database backup. Its output can contain multiple pieces; it does not mean that a single database piece contains every archived log. The separate control file command makes its own output explicit. The example performs no backup deletion or archived-log deletion, and it does not silently exclude read-only data files.

If your backup policy calls for compression, review AS COMPRESSED BACKUPSET and the applicable algorithm, resource cost, and licensing before adopting it. Compression is a separate backup choice. Changing the filename extension to indicate compression has no effect on the backup representation.

Keep control file autobackups separate

A normal BACKUP CURRENT CONTROLFILE operation and a control file autobackup serve related but distinct purposes. The explicit control file backup above uses an ordinary FORMAT with %U. Autobackups have their own configuration and naming rules, supporting discovery when normal repository information is unavailable. An ordinary BACKUP FORMAT does not control their filenames.

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
  TO '/backup/rman/autocf_%F';

These are reviewed configuration commands, rather than lines that must be repeated in every job. A custom control file autobackup format must retain %F, which supplies the DBID, date, and sequence component needed for its naming convention. Use that documented autobackup format rule rather than substituting %U from ordinary backup examples. Record the DBID and any custom location in recovery procedures kept accessible outside the database.

When the database uses an SPFILE, control file autobackups also protect the SPFILE. Plan how these recovery-critical files will remain available after a host or storage loss. Placing them on the same unprotected volume as the database does not by itself solve that problem. If using the fast recovery area defaults, review whether a custom autobackup path is actually appropriate.

Channels, parallel work, and media managers

A backup channel is a target database server session that reads database files and writes backup output through the selected device type. It is not a connection to the recovery catalog, and it is not simply another name for a disk drive. Connecting to a catalog gives RMAN access to repository metadata; it does not allocate a backup data channel there.

Automatic channels are allocated as operations require them according to the target's configuration. Manual ALLOCATE CHANNEL commands inside RUN supply channels for that block and override automatic channel allocation. Multiple channels permit concurrent work, but performance depends on the input files, storage bandwidth, CPU, and destination. Adding channels does not guarantee a faster backup.

For tape or other media-manager storage, use SBT with an installed and configured compatible media management library. The FORMAT string becomes a media handle governed by that integration, rather than an ordinary filesystem pathname. This example illustrates syntax only; it requires the site's media-manager configuration before use.

RUN {
  ALLOCATE CHANNEL t1 DEVICE TYPE SBT;
  ALLOCATE CHANNEL t2 DEVICE TYPE SBT;
  BACKUP AS BACKUPSET
    FORMAT 'full_%d_%T_%U'
    FILESPERSET 10
    DATABASE;
  RELEASE CHANNEL t1;
  RELEASE CHANNEL t2;
}

FILESPERSET limits how many input files RMAN places in a backup set. It does not directly specify piece size, the number of channels, or the number of physical tape drives. Piece size can be constrained separately with channel settings such as MAXPIECESIZE. Tune these parameters against a measured workload and recovery requirements rather than treating one value as a universal performance setting.

The legacy SKIP READONLY option can deliberately omit read-only data files. Use it only when existing protected backups and your recovery plan account for those omitted files. A read-only tablespace still contains data needed for recovery. The basic full backup examples therefore include it rather than assuming another job has already protected it.

Store the commands in a recovery catalog when appropriate

A command file is an operating-system file read by the RMAN client. A stored script lives in a recovery catalog and requires the appropriate catalog connection and registered target. A local stored script is associated with that target. Store the RMAN commands themselves in its body, without shell commands, connection statements, or a nested RUN block.

CREATE SCRIPT full_disk_backup {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  BACKUP AS BACKUPSET
    FORMAT '/backup/rman/db_%d_%T_%U.bkp'
    DATABASE;
  RELEASE CHANNEL c1;
}

PRINT SCRIPT full_disk_backup;
RUN { EXECUTE SCRIPT full_disk_backup; }

This shorter stored script demonstrates database backup naming; it does not replace the archived-log and recovery-file planning in the main example. Use REPLACE SCRIPT to revise an existing script after review. A stored script named BACKUP_TEMP would be misleading for a modern temporary tablespace: RMAN does not back up its tempfiles. Temporary-file handling during recovery is different from restoring permanent data files.

Check the command file and verify its actual outputs

A plain .rman file is input to the RMAN executable. Making it executable with chmod does not turn it into a shell program. First use a parser check from the client operating-system shell, with paths that exist on that client:

rman CHECKSYNTAX CMDFILE="C:\rman\scripts\full_database.rman"

CHECKSYNTAX checks command syntax without performing the backup. It cannot prove that credentials, target scope, storage capacity, or filesystem permissions will work at runtime. For an authorized local operating-system authentication setup, a later execution could use:

rman TARGET / CMDFILE="C:\rman\scripts\full_database.rman" LOG="C:\rman\logs\full_database_20261003_220000.log"

Use a fresh log name for every attempt and inspect the exit status and full log. Local authentication depends on the configured administrative operating-system groups; remote authentication needs an appropriate connection, such as a common user with SYSBACKUP for CDB-root work. Let RMAN prompt for a password or use an approved credential mechanism. Do not embed passwords in command files, shell history, or example connection strings.

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

After an actual successful run, compare repository piece handles with the expected server destination and inspect the recorded status and contents. A file's presence alone does not establish a complete usable backup. Validation and a tested restore procedure provide separate evidence of recoverability. The examples here describe a procedure; their presentation is not a claim that a backup was executed or restored.

Oracle's FORMAT reference, BACKUP command reference, and RMAN configuration guide describe naming, output selection, and persistent settings. Consult the RMAN invocation reference for client options and the RESTORE reference for recovery behavior. The next lesson focuses on executing backup scripts and evaluating their results.