Tuning I/O for RMAN Backups when using Tape Device

Tuning I/O for RMAN Backups when using Tape Device

Tuning the BLKSIZE parameter in an Oracle RMAN backup script is a key aspect of optimizing backup and restore performance, particularly when backing up to tape (SBT) devices.

The BLKSIZE parameter determines the size of the I/O buffers used by RMAN, and a larger block size can significantly improve performance by allowing more data to be transferred in a single I/O operation.

How to Set the BLKSIZE Parameter

You can set the BLKSIZE parameter within your RMAN script using the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. The BLKSIZE is specified in bytes.

Here are examples of how to set it:

 

1. Using CONFIGURE CHANNEL (for persistent settings):

This command configures the BLKSIZE for all future RMAN sessions for the specified device type.

CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='BLKSIZE=1048576';

In this example, the BLKSIZE is set to 1MB (1024 * 1024 bytes).

2. Using ALLOCATE CHANNEL (for the current RMAN job):

This command sets the BLKSIZE only for the channels allocated within the current RUN block.

RUN {

  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='BLKSIZE=524288';

  BACKUP DATABASE;

}

Here, the BLKSIZE is set to 512KB (512 * 1024 bytes) for channel c1.

           Best Practices and Considerations for Tuning BLKSIZE

• Backup to Tape (SBT): The BLKSIZE parameter is primarily effective for backups to tape devices. For disk backups, RMAN's default buffer sizes are generally adequate, and other tuning methods are more effective.
• Match Media Manager Settings: For optimal performance, the BLKSIZE in your RMAN script should match the block size configured in your media management software (e.g., NetBackup, Commvault). A mismatch can lead to performance degradation.
• Recommended Values: While the optimal BLKSIZE can vary depending on your hardware and environment, a common starting point is 256KB, with many administrators finding success with values of 512KB, 1MB, or even larger.
• LARGE_POOL_SIZE: When you increase the BLKSIZE, you may also need to increase the LARGE_POOL_SIZE in your database's initialization parameters. This is because RMAN allocates I/O buffers from the Large Pool when using I/O slaves.
• Asynchronous I/O: To prevent I/O from becoming a bottleneck, ensure that asynchronous I/O is enabled at the operating system level. If it's not supported, you can simulate it by setting the DBWR_IO_SLAVES and BACKUP_TAPE_IO_SLAVES initialization parameters.
• Monitoring and Testing: The key to successful tuning is to monitor your backup performance and test different BLKSIZE values. You can use V$ views like V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO to identify bottlenecks.

 

Tune RMAN output buffer size

Ø Output buffers => blocks written to DISK as copies or backup pieces or to SBT as backup pieces

Ø Four buffers allocated per channel

Ø Default buffer sizes

o   DISK: 1 MB

o   SBT: 256 KB

Ø Adjust with BLKSIZE channel parameter

Ø Set BLKSIZE >= media management client buffer size

Ø No changes needed for Oracle Secure Backup

 

Other RMAN Performance Tuning Factors

While BLKSIZE is important, it's just one piece of the puzzle. For comprehensive RMAN performance tuning, consider these additional factors:

• Multiplexing: Adjusting the level of multiplexing, which is the number of input files read simultaneously, can improve performance, especially when tape drives are not being kept busy.
• Number of Channels: Allocating an appropriate number of channels, typically between 50% and 75% of the number of CPU cores, can help parallelize the backup process.
• RATE Parameter: The RATE parameter can be used to limit the I/O bandwidth that RMAN consumes, which can be useful to avoid impacting other database operations. However, for maximum backup speed, this parameter should generally be removed.
• The RATE parameter on a channel is intended to reduce, rather than increase, backup throughput so that more disk bandwidth is available for other database operations. If the backup is not streaming to tape, then confirm that the RATE parameter is not set.
• FILESPERSET: This parameter controls the number of files in each backup set. Finding the right balance can optimize performance and media usage.

 

•  Enable Asynchronous I/O (or I/O Slaves)
• Why it's critical for SBT: This is arguably the most important setting for tape backups. Asynchronous I/O allows RMAN to write data to the tape buffer without waiting for the I/O operation to complete. While one buffer is being written to tape by the media manager, RMAN can be filling the next buffer with data from the database. This creates a smooth, continuous data stream that keeps the tape drive constantly spinning, which is exactly what you want for maximum throughput.
• What happens without it: With synchronous I/O, RMAN fills a buffer, sends it to the media manager, and then waits for the write to complete before it starts filling the next buffer. This pause is often long enough for the tape drive to stop, leading to poor performance.
• Increase LARGE_POOL_SIZE
• Why it's critical for SBT: The buffers used by asynchronous I/O are allocated from the Large Pool. If the Large Pool is too small to hold all the buffers for all your channels, RMAN will fail to allocate them and may revert to synchronous I/O (using the PGA), completely negating the benefits. A generously sized Large Pool is the foundation for high-speed tape backups.
• Calculation: A rough formula to estimate the required size is: LARGE_POOL_SIZE = (number_of_channels * (4 * BLKSIZE)) + overhead for example, with 4 channels and a 1MB BLKSIZE: 4 * (4 * 1048576 bytes) ≈ 16 MB. It's wise to add a significant buffer (e.g., 50-100MB or more) on top of this for other Large Pool uses. Starting with 256MB or 512MB is a safe bet for most environments.
• Increase Parallelism (Channels)
• Why it's critical for SBT: A single CPU core might not be able to read data from the database files fast enough to keep a modern, high-speed tape drive busy. By allocating multiple channels, you parallelize the work of reading data blocks and feeding them to the media manager. This helps ensure the data pipeline is always full.
• Consideration: The number of channels should not exceed the number of physical tape drives you intend to use for the backup, unless your media manager can multiplex multiple streams to a single drive. The goal is to match RMAN's output rate to the tape drive's write capacity.
• Tune BLKSIZE
• Why it's critical for SBT: This parameter is specifically designed for tape devices. Tape drives are block devices that perform best with large I/O operations. A larger BLKSIZE (e.g., 256KB, 512KB, 1MB) means RMAN sends more data in a single I/O call, which is far more efficient for tape.
• Crucial Alignment: It is vital that the BLKSIZE you set in RMAN matches the block size configured in your media management software (e.g., NetBackup, Commvault, etc.). A mismatch can force the media manager to re-buffer the data, adding overhead and slowing down the backup. Check your media manager's documentation for its recommended or default block size.

 

Conclusion for SBT Backups

For SBT backups, these recommendations are not just "good," they are the standard best practices for achieving high performance. Failing to implement them, especially asynchronous I/O and a properly sized Large Pool, will almost certainly result in backups that are significantly slower than what your hardware is capable of.

By systematically evaluating and adjusting these parameters, including BLKSIZE, you can significantly improve the efficiency of your Oracle RMAN backup and recovery operations.

Monitoring & Troubleshoot

Query V$BACKUP_ASYNC_IO and Check EFFECTIVE_BYTES_PER_SECOND column (EBPS) for row where TYPE = 'AGGREGATE'.

    If EBPS < storage media throughput, run BACKUP VALIDATE

  

Ø Case 1:

 BACKUP VALIDATE time ~= actual backup time, then read phase is the likely bottleneck.

Refer to RMAN multiplexing and buffer usage guidelines

Investigate ‘slow’ performing files: find data file with highest (LONG_WAITS / IO_COUNT) ratio

    If ASM, add disk spindles and/or re-balance disks

    Move file to new disk or multiplex with another ‘slow’ file.

  

Ø Case 2:

     If BACKUP VALIDATE time << actual backup time, then buffer copy or write to storage media phase is the likely bottleneck.

Refer to backup compression and encryption guidelines

If tape backup, check media management (MML) settings

§  TCP/IP buffer size

§  Media management client/server buffer size

§  Client/socket timeout

§  Media server hardware, connectivity to tape

§  Enable tape compression (but not RMAN compression)

 

Write Phase for System Backup Tape (SBT)

When backing up to SBT, RMAN gives the media manager a stream of bytes and associates a unique name with this stream. All details of how and where that stream is stored are handled entirely by the media manager. Thus, a backup to tape involves the interaction of both RMAN and the media manager.

RMAN Component of the Write Phase for SBT

The RMAN-specific factors affecting the SBT write phase are analogous to the factors affecting disk reads. In both cases, the buffer allocation, slave processes, and synchronous or asynchronous I/O affect performance.

Allocation of Tape Buffers

If you back up to or restore from an SBT device, then by default the database allocates four buffers for each channel for the tape writers. The size of the tape I/O buffers is platform-dependent. You can change this value with the PARMS and BLKSIZE parameters of the ALLOCATE CHANNEL or CONFIGURE CHANNEL command.

Allocation of Tape Buffers

Tape I/O Slaves

RMAN allocates the tape buffers in the System Global Area (SGA) or the Program Global Area (PGA), depending on whether I/O slaves are used. If you set the initialization parameter BACKUP_TAPE_IO_SLAVES=true, then RMAN allocates tape buffers from the SGA. Tape devices can only be accessed by one process at a time, so RMAN starts as many slaves as necessary for the number of tape devices. If the LARGE_POOL_SIZE initialization parameter is also set, then RMAN allocates buffers from the large pool. If you set BACKUP_TAPE_IO_SLAVES=false, then RMAN allocates the buffers from the PGA.

If you use I/O slaves, then set the LARGE_POOL_SIZE initialization parameter to dedicate SGA memory to holding these large memory allocations. This parameter prevents RMAN I/O buffers from competing with the library cache for SGA memory. If I/O slaves for tape I/O were requested but there is not enough space in the SGA for them, slaves are not used, and a message appears in the alert log.

The parameter BACKUP_TAPE_IO_SLAVES specifies whether RMAN uses slave processes rather than the number of slave processes. Tape devices can only be accessed by one process at a time, and RMAN uses the number of slaves necessary for the number of tape devices.

Synchronous and Asynchronous I/O

When an SBT channel reads or writes data to tape, the I/O is always synchronous. For tape I/O, each channel allocated (whether manually or automatically) corresponds to a server process, called here a channel process.

Synchronous Tape I/O

 

 

*****************************************************************

Configuring RMAN to Make Backups to Recovery Appliance

Configuring RMAN to Make Backups to Recovery Appliance in Oracle AI

RMAN commands can be used to back up target databases to Zero Data Loss Recovery Appliance.

This section describes the configuration steps required to backup a target database to Recovery Appliance using RMAN.
• Prerequisites for Using Recovery Appliance
• Setting Up the Recovery Appliance Backup Module
• Configuring SBT Channel for RMAN Backups to Recovery Appliance

Prerequisites for Using Recovery Appliance
Review the prerequisites to backup a target database to Zero Data Loss Recovery Appliance(ZDLR).

• Set up the Recovery Appliance backup module on the target database server.
The backup module setup file (ra_installer.zip) is located in the ORACLE_HOME/lib directory of the target database.


The Recovery Appliance backup module creates the Oracle wallet containing credentials used to authenticate the target database with Recovery Appliance.

• RMAN requires the system backup to tape (SBT) channel to perform cloud backup and recovery operations. Use the CONFIGURE command to create an automatic SBT channel. Use the SBT_LIBRARY parameter to specify the media library that enables RMAN to communicate with the Recovery Appliance backup module.

Note:
An automatic SBT channel creates a persistent default SBT device setting that applies to all backup and recovery operations. Alternatively, you can use the ALLOCATE CHANNEL  command to manually allocate a one-time SBT channel before each backup or restore operation.

🧣 Starting in Oracle Database 19c Release Update version 27 (19.27), Oracle provides native SBT libraries for RMAN backup and recovery operations with Recovery Appliance.

• On UNIX/Linux systems, the Recovery Appliance SBT library libra.so is located in the $ORACLE_HOME/lib directory.
• On Windows systems, the Recovery Appliance SBT library orara.dll is located in the %ORACLE_HOME%\bin directory.

🎩 Starting in Oracle Database 19c Release Update version 28 (19.28), oracle.zdlra is the alias name for the Recovery Appliance native SBT library.

When you configure the RMAN SBT channel for backups to Recovery Appliance, specify the SBT_LIBRARY alias oracle.zdlra (recommended), or provide the absolute path to the SBT_LIBRARY file: $ORACLE_HOME/lib/libra.so on UNIX/Linux systems or %ORACLE_HOME%\bin\orara.dll on Windows systems.

Run the backup module installer to set up the authentication required for RMAN to access Recovery Appliance. You must use the SBT library included with the patch instead of downloading the library while running the installer.

Setting Up the Recovery Appliance Backup Module
The Recovery Appliance backup module is an Oracle-supplied media management library that enables RMAN to perform backup and restores with Recovery Appliance.


Starting with Oracle Database 19c Release Update version 27 (19.27), the Recovery Appliance backup module setup file (ra_installer.zip) is located in the $ORACLE_HOME/lib directory of the target database.


Note:
For Oracle Database 19c Release Update version 26 (19.26) and earlier versions, download the operating system-specific Recovery Appliance backup module from My Oracle Support Patch Number 37855779.

Run the backup module installer to set up the authentication required for RMAN to access Recovery Appliance. You must use the SBT library included with the patch instead of downloading the library while running the installer.

• Extract the ra_installer.zip file to a subdirectory of your choice. In this example, you extract the setup files to the ramodule subdirectory.

$ mkdir -p $ORACLE_HOME/lib/ramodule
$ cd $ORACLE_HOME/lib/ramodule
unzip -q $ORACLE_HOME/lib/ra_installer.zip

• On the target database server, go to the directory where you have extracted the Recovery Appliance backup module setup files.
In this example, you navigate to the ramodule subdirectory which contains the ra_install.jar file and the README file ra_readme.txt.

$ cd $ORACLE_HOME/lib/ramodule

• Run this command to preview the parameters required to run the Recovery Appliance backup module.

$ java -jar ra_install.jar

Compile the values for the parameters.

• Run the ra_install.jar file by specifying the parameters and values.

Configuring SBT Channel for RMAN Backups to Recovery Appliance
Configure an automatic SBT channel so that RMAN can directly send backups to Recovery Appliance.
When you configure the SBT channel, you must specify the native SBT library that corresponds to Recovery Appliance, and specify the location of the client configuration file stored on the protected database.

The configuration file contains the configuration settings that are used by the Recovery Appliance backup module to communicate with the Recovery Appliance. This configuration file is created when you set up the Recovery Appliance backup module.

• Start RMAN and connect to the target database.
• Use the CONFIGURE command to preconfigure an automatic SBT channel. Use the SBT_LIBRARY parameter to specify the library alias oracle.zdlra. You can optionally specify the native SBT library path instead of the library alias.
• Use the ENV parameter (UNIX and Linux) or the SBT_PARMS parameter (Windows) to directly specify the client configuration parameters for Recovery Appliance.

The client configuration file must contain the location of the Oracle wallet that stores the credentials required to authenticate the target database with Recovery Appliance. Other optional settings may be included.

Note:
On Windows platforms, Oracle recommends that you use the SBT_PARMS parameter to specify the environment variables, instead of the ENV parameter.

Example: Specifying Recovery Appliance Client Configuration Settings

The following command (suggested on LINUX and UNIX platforms) specifies the Recovery Appliance client configuration settings directly as part of the CONFIGURE CHANNEL command:

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= oracle.zdlra, ENV=(BA_WALLET=location=file:/home/oracle/product/19.28.0/dbhome_1/wallet credential_alias=ra-scan:1521/zdlra5:dedicated)';


The following command (suggested on Windows platforms) specifies the Recovery Appliance client configuration settings directly as part of the CONFIGURE CHANNEL command:

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= oracle.zdlra, SBT_PARMS=(BA_WALLET=location=file:/home/oracle/product/19.28.0/dbhome_1/wallet credential_alias=ra-scan:1521/zdlra5:dedicated)';

In this example, oracle.zdlra is the native SBT library that corresponds to the Recovery Appliance backup module. ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the service name of the Recovery Appliance metadata database.


Alireza Kamrani

Oracle Technical Solutions Advisor
ACE Pro

RMAN Pipe Interface & Concepts

RMAN Pipe Interface & Concepts

Alireza Kamrani

Using the RMAN Pipe Interface
The RMAN pipe interface is an alternative method for issuing commands to RMAN and receiving the output from those commands. Using this interface, it is possible to write a portable programmatic interface to RMAN.
With the pipe interface, RMAN obtains commands and sends output by using the DBMS_PIPE PL/SQL package instead of the operating system shell. The pipe interface is invoked by using the PIPE command-line parameter for the RMAN client. RMAN uses two private pipes: one for receiving commands and the other for sending output. The names of the pipes are derived from the value of the PIPE parameter. For example, you can invoke RMAN with the following command:

% rman PIPE abc TARGET /

RMAN opens the two pipes in the target database: ORA$RMAN_ABC_IN, which RMAN uses to receive user commands, and ORA$RMAN_ABC_OUT, which RMAN uses to send all output back to RMAN.
All messages on both the input and output pipes are of type VARCHAR2.

RMAN does not permit the pipe interface to be used with public pipes, because they are a potential security problem. With a public pipe, any user who knows the name of the pipe can send commands to RMAN and intercept its output.
If the pipes are not initialized, then RMAN creates them as private pipes. If you want to put commands on the input pipe before starting RMAN, you must first create the pipe by calling DBMS_PIPE.CREATE_PIPE. Whenever a pipe is not explicitly created as a private pipe, the first access to the pipe automatically creates it as a public pipe, and RMAN returns an error if it is told to use a public pipe.

Note:
If multiple RMAN sessions can run against the target database, then you must use unique pipe names for each RMAN session. The DBMS_PIPE.UNIQUE_SESSION_NAME function is one method that you can use to generate unique pipe names.

Possible used for the pipes interface are:
• Applications coded to automatically invoke one or more backup and recovery functions to achieve their design objectives
• Third party tools which whish to provide their own interface to RMAN
• DBA tools that wish to incorporate some RMAN functionality

Executing Multiple RMAN Commands in Succession Through a Pipe: Example

This example assumes that the application controlling RMAN wants to run multiple commands in succession. After each command is sent down the pipe and executed and the output returned, RMAN pauses and waits for the next command.
To execute RMAN commands through a pipe:
• Start RMAN by connecting to a target database (required) and specifying the PIPE option. For example, enter:

% rman PIPE abc TARGET /
You can also specify the TIMEOUT option, which forces RMAN to exit automatically if it does not receive any input from the input pipe in the specified number of seconds. For example, enter:

% rman PIPE abc TARGET / TIMEOUT 60
• Connect to the target database and put the desired commands on the input pipe by using DBMS_PIPE.PACK_MESSAGE and DBMS_PIPE.SEND_MESSAGE. In pipe mode, RMAN issues message RMAN-00572 when it is ready to accept input instead of displaying the standard RMAN prompt.
• Read the RMAN output from the output pipe by using DBMS_PIPE.RECEIVE_MESSAGE and DBMS_PIPE.UNPACK_MESSAGE.
• Repeat Steps 2 and 3 to execute further commands with the same RMAN instance that was started in Step 1.
• If you used the TIMEOUT option when starting RMAN, then RMAN terminates automatically after not receiving any input for the specified length of time. To force RMAN to terminate immediately, send the EXIT command.

Executing RMAN Commands in a Single Job Through a Pipe: Example

This example assumes that the application controlling RMAN wants to run one or more commands as a single job. After running the commands that are on the pipe, RMAN exits.
To execute RMAN commands in a single job through a pipe:
• After connecting to the target database, create a pipe (if it does not already exist under the name ORA$RMAN_pipe_IN).
• Put the desired commands on the input pipe. In pipe mode, RMAN issues message RMAN-00572 when it is ready to accept input instead of displaying the standard RMAN prompt.
• Start RMAN with the PIPE option, and specify TIMEOUT 0. For example, enter:

% rman PIPE abc TARGET / TIMEOUT 0

• RMAN reads the commands that were put on the pipe and executes them by using DBMS_PIPE.PACK_MESSAGE and DBMS_PIPE.SEND_MESSAGE. When it has exhausted the input pipe, RMAN exits immediately.
• Read RMAN output from the output pipe by using DBMS_PIPE.RECEIVE_MESSAGE and DBMS_PIPE.UNPACK_MESSAGE.


A Practical Scenario

The RMAN Pipe Interface allows Oracle sessions to send RMAN commands to a running RMAN process using Oracle’s internal DBMS_PIPE mechanism.

It’s mainly used for controlling RMAN from inside PL/SQL rather than through OS scripts.

So instead of typing commands in the RMAN CLI, you:
• Start RMAN with PIPE <name>
• Send commands into that pipe using DBMS_PIPE.PACK_MESSAGE and SEND_MESSAGE
• RMAN executes those commands
• Read results via DBMS_PIPE.RECEIVE_MESSAGE

Step 1: Start RMAN in Pipe Mode
From the OS:

$rman PIPE DEMO_PIPE  TARGET / TIMEOUT 600

This launches RMAN and creates two private Oracle pipes:

• ORA$RMAN_DEMO_PIPE_IN
• ORA$RMAN_DEMO_PIPE_OUT

RMAN will wait for incoming PL/SQL commands for up to 600 seconds.

You can confirm it’s waiting via:

SELECT sid, event FROM v$session_wait WHERE event LIKE '%pipe%';

You’ll see RMAN waiting on "pipe get handle" or similar events.

Step 2: Create the PL/SQL Procedure RMAN_CMD

CREATE OR REPLACE PROCEDURE rman_cmd(cmd VARCHAR2) AS
  in_pipe_name  VARCHAR2(2000) := 'ORA$RMAN_DEMO_PIPE_IN';
  out_pipe_name VARCHAR2(2000) := 'ORA$RMAN_DEMO_PIPE_OUT';
  v_info        VARCHAR2(255);
  v_status      INTEGER;
BEGIN
  DBMS_OUTPUT.PUT_LINE('Begin RMAN command: ' || cmd);

  -- Clean old pipe data
  v_status := DBMS_PIPE.RECEIVE_MESSAGE(out_pipe_name, 0);
  WHILE v_status = 0 LOOP
    DBMS_PIPE.UNPACK_MESSAGE(v_info);
    v_status := DBMS_PIPE.RECEIVE_MESSAGE(out_pipe_name, 10);
  END LOOP;

  -- Send the RMAN command
  DBMS_PIPE.PACK_MESSAGE(cmd);
  v_status := DBMS_PIPE.SEND_MESSAGE(in_pipe_name);

  -- Wait for RMAN output
  v_status := 0;
  WHILE v_status = 0 OR v_status = 1 LOOP
    v_status := DBMS_PIPE.RECEIVE_MESSAGE(out_pipe_name, 30);
    IF v_status = 0 THEN
      DBMS_PIPE.UNPACK_MESSAGE(v_info);
      DBMS_OUTPUT.PUT_LINE(v_info);
      IF v_info LIKE '%RMAN-00572%' OR v_info LIKE '%Recovery Manager complete%' THEN
        EXIT;
      END IF;
    END IF;
  END LOOP;
END;
/

This procedure:
• Cleans any stale messages from previous runs.
• Sends your command to RMAN.
• Reads back RMAN’s textual output line-by-line.
• Displays or logs it.

Step 3: Execute Real RMAN Commands from SQL*Plus

Now, in the same SQL*Plus session, you can send actual RMAN commands to the RMAN process:

EXEC rman_cmd('SHOW ALL;');
EXEC rman_cmd('CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;');
EXEC rman_cmd('BACKUP SPFILE;');
EXEC rman_cmd('LIST BACKUP OF TABLESPACE SYSTEM;');
EXEC rman_cmd('LIST BACKUP SUMMARY;');
EXEC rman_cmd('REPORT NEED BACKUP;');
EXEC rman_cmd('CONFIGURE RETENTION POLICY CLEAR;');
EXEC rman_cmd('EXIT;');

Step 4: What Happens in the Background

Each call:
• Sends the text (e.g. "BACKUP SPFILE;") through the pipe to RMAN.
• RMAN executes the command.
• RMAN writes back the results (progress, logs, errors) to the OUT pipe.
• Your PL/SQL procedure prints these results in real time.

A Real-World Use Case
To automate backups or monitoring from PL/SQL (without relying on external OS scripts).

You should follow these steps:

1- Schedule RMAN to start with a private pipe (as a background process or job):

$nohup rman PIPE AUTO_BACKUP TARGET / TIMEOUT 1800 &

2- Inside Oracle, define your procedure (like rman_cmd) to send commands.

3-Create a scheduler job:

BEGIN
  DBMS_SCHEDULER.CREATE_JOB (
    job_name => 'DB_AUTO_BACKUP',
    job_type => 'PLSQL_BLOCK',
    job_action => q'[
      BEGIN
        rman_cmd('BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;');
      END;
    ]',
    start_date => SYSTIMESTAMP,
    repeat_interval => 'FREQ=DAILY;BYHOUR=1',
    enabled => TRUE
  );
END;
/

• Store and analyze RMAN output in a log table for reporting or alerts.

This approach keeps backup orchestration inside Oracle, using RMAN’s own engine but controlled via PL/SQL.

Monitoring and Troubleshooting

To check current RMAN pipe sessions:

SELECT name, type, pipe_size
FROM v$db_pipes
WHERE name LIKE '%RMAN%';

Important Notes :

Privileges: Grant EXECUTE ON DBMS_PIPE only to DBA/specific service account.
Security: Use private pipes only to increase security. Public pipes are blocked by default in 21c.
RMAN lifecycle: The RMAN process must be running before you send commands.
Timeout: If RMAN doesn’t receive any new command within the TIMEOUT window, it will exit automatically.
Parallel RMANs: You can run multiple RMAN instances with different pipe names, e.g., RMAN21_DEV_PIPE, RMAN21_PRD_PIPE.


#############################

About Consistent and Inconsistent RMAN Backups

Use the RMAN BACKUP command to create both consistent and inconsistent backups.

The RMAN BACKUP command supports backing up the following types of files:

• Data files and control files
• Server parameter file
• Archived redo logs
• RMAN backups

Although the database depends on other types of files, such as network configuration files, password files, and the contents of the Oracle home, you cannot back up these files with RMAN. Likewise, some features of Oracle Database, such as external tables, may depend upon files other than the data files, control files, and redo log. RMAN cannot back up these files. Use general-purpose backup software such as Oracle Secure Backup to protect files that RMAN does not support.

When you execute the BACKUP command in RMAN, the output is always either one or more backup sets or one or more image copies. A backup set is an RMAN-specific proprietary format, whereas an image copy is a bit-for-bit copy of a file. By default, RMAN creates backup sets.

 

About Consistent RMAN Backups

A consistent backup occurs when the database is in a consistent state. You can use the BACKUP command to make consistent backups of the database.

A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the data files. If you mount the database and make a backup at this point, then you can restore the database backup later and open it without performing media recovery. 

.But you will, of course, lose all transactions that occurred after the backup was created.

 

About Inconsistent RMAN Backups

Any database backup that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command.

When a database is restored from an inconsistent backup, Oracle Database must perform media recovery before the database can be opened, applying changes from the redo logs that took place after the backup was created.

Note:

RMAN does not permit you to make inconsistent backups when the database is in NOARCHIVELOG mode. If you employ user-managed backup techniques for a NOARCHIVELOG database, then you must not make inconsistent backups of this database.

If the database runs in ARCHIVELOG mode, and you back up the archived redo logs and data files, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups offer superior availability because you do not have to shut down the database to make backups that fully protect the database.

 

About Online Backups and Backup Mode

You can create RMAN backups or user-managed backups.

When performing a user-managed backup of an online tablespace or database, an operating system utility can back up a data file at the same time that the database writer (DBWR) is updating the file. It is possible for the utility to read a block in a half-updated state, so that the block that is copied to the backup media is updated in its first half,

 

while the second half contains older data. This type of logical corruption is known as a fractured block, that is, a block that is not consistent with an SCN. If this backup must be

restored and the block requires recovery, then recovery fails because the block is not usable.

 

For third-party snapshot technologies, you must use one of the following techniques to eliminate the risk of creating fractured blocks:

• Ensure that the snapshot technology complies with Oracle requirements for online backups
• Take the database or data files offline
• Place the database in backup mode before using a third-party snapshot backup

The RECOVER…SNAPSHOT TIME method of recovering a database to a point in time using a particular snapshot is desupported in Oracle AI Database 26ai.

Instead of RECOVER…SNAPSHOT TIME, Oracle recommends that you use ALTER DATABASE BEGIN/END BACKUP before and after creating the storage snapshot of the data files and then use RECOVER …. UNTIL TIME to a specific timestamp or system change number (SCN) after the END BACKUP completion time. Oracle recommends that ALTER DATABASE BEGIN/END BACKUP always be used when performing snapshots on a running database to ensure data recovery integrity. Archived log redo logs must be separately backed up and restored for recovery operations.

Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the data file header checkpoint because it knows the order in which the blocks are read, which enables it to capture a known good checkpoint for the file.

About Backup Sets

When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.

Note:

Data file backup sets are typically smaller than data file image copies and take less time to write.

 

Ø  how RMAN can take a consistent backup of a running (open) database even when heavy DML is happening??

 

1. Key idea — “Consistent image through SCN”

Every Oracle block (in datafiles, undo, etc.) carries a System Change Number (SCN) — a monotonically increasing version stamp of the database at that moment.
RMAN uses these SCNs to guarantee that every block in the backup reflects a consistent point in time (a checkpoint-consistent image).

When you run:

BACKUP DATABASE;

on an open database, RMAN is really performing an online (hot) backup, meaning users can continue DMLs (INSERT, UPDATE, DELETE, COMMIT).

 2. RMAN works with read-consistent block images

When RMAN reads a block from a datafile:

• If that block has already been modified after the backup started (its SCN > backup checkpoint SCN),
• RMAN does not use that dirty block directly,
• Instead, it asks Oracle’s block recovery mechanism (via the DBWR and redo apply engine) to reconstruct the block image as of the backup SCN using the redo + undo information.

This is done by Oracle’s “read-consistent block” mechanism.

So, each block RMAN writes to the backup set is the version that was valid at the backup’s checkpoint SCN — even if users were modifying it at that very moment.

3. How redo logs ensure recoverability

During online backup:

• Oracle continuously writes redo entries for all DMLs.
• RMAN keeps track of the lowest SCN of all datafile backups (the checkpoint SCN) and also ensures all redo up to that SCN is included in the backup.

So, when you later restore and recover:

1.      RMAN restores the datafiles from the backup sets (consistent as of checkpoint SCN).

2.      Then applies archived + online redo logs to bring the database forward to the desired point in time (for example, until last committed transaction).

4. Backup checkpoint concept

Each datafile backup has a checkpoint SCN (start/end):

• Checkpoint SCN = point in time that file content is consistent with.
• RMAN records these in the controlfile and catalog.

During restore:

• Oracle uses these SCNs to know which redo must be applied to make all files consistent with each other.

5. Internal protection (CKPT, LGWR, DBWR, SMON)

Internally:

• CKPT updates headers with checkpoint SCNs.
• DBWR writes dirty buffers to disk regularly.
• LGWR ensures redo is flushed before commit.
• SMON coordinates instance recovery if needed.

RMAN leverages all of this to maintain backup consistency — it does not “freeze” datafiles, but logically guarantees consistency via SCN management and redo.

6. Summary – The consistency triangle

Component	Role	Purpose
SCN	Global timestamp	Defines backup consistency point
Redo	Transaction log	Replays changes to make blocks consistent
Undo	Old versions	Used to reconstruct consistent read image
RMAN	Orchestrator	Reads blocks, manages checkpoint SCNs, invokes kernel consistency logic

7. Example of timeline

T1: RMAN begins backup, notes checkpoint SCN = 1000

T2: User commits a transaction (SCN 1005)

T3: RMAN reads block that was updated at SCN 1005

     -> Oracle reconstructs block as it was at SCN 1000

T4: RMAN writes the consistent block to backup set

So final backup is a point-in-time image as of SCN 1000, even though DML continued during the backup.

8. Notes:

• This mechanism is much safer than user-managed hot backups (which require BEGIN/END BACKUP mode).
• Works only in ARCHIVELOG mode.
• RMAN uses block-level media recovery and backup optimization to minimize overhead.