The CONFIGURE CHANNEL command is used to configure RMAN channel options.

This section contains the following topics about advanced channel option:

• About Channel Control Options

• Configuring Specific Channel Parameters

Backup options enable you to control aspects such as backup size, backup compression, and backup encryption.

"About Configuring the Environment for RMAN Backups" explains the basics for configuring RMAN to make backups. This section explains more advanced configuration options. This section contains the following topics:

• Configuring the Maximum Size of Backup Sets

• Configuring the Maximum Size of Backup Pieces

• Configuring Backup Duplexing

• Configuring Tablespaces for Exclusion from Whole Database Backups

• Configuring Compression Options

• Configuring Backup Encryption

You may want to set the names of data files in the auxiliary instance when performing operations such as data file tablespace point-in-time recovery (TSPITR) or data transfer with RMAN. You set these names before starting the TSPITR or database duplication.

CONFIGURE AUXNAME FOR datafileSpec TO 'filename';

CONFIGURE AUXNAME FOR DATAFILE 2 TO '/newdisk/datafiles/df2.df';

CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;

When RMAN needs a read-consistent version of the control file, it creates a temporary snapshot control file. RMAN needs a snapshot control file when resynchronizing with the recovery catalog or when making a backup of the current control file.

The default location for the snapshot control file is platform-specific and depends on the Oracle home of each target database. For example, the default file name on some Linux platforms is $ORACLE_HOME/dbs/snapcf_@.f. If a fast recovery area is configured for a target database, then the default location for the snapshot control file is not the fast recovery area.

This section contains the following topics:

• Viewing the Configured Location of the Snapshot Control File

• Setting the Location of the Snapshot Control File

RMAN cannot connect to a target database through a shared server dispatcher. RMAN requires a dedicated server process.

inst1_shs =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
    (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=shared))
  ) 

1. Create a net service name in the tnsnames.ora file that connects to the nonshared SID. For example, enter:

   inst1_ded =
     (DESCRIPTION=
       (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
       (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated))
     )
   

2. Start SQL*Plus and then connect using both the shared server and dedicated server service names to confirm the mode of each session.

   For example, connect with SYSBACKUP or SYSDBA privilege to inst1_ded and then execute the following SELECT statement (sample output included):

   SQL> SELECT SERVER 
     2  FROM   V$SESSION 
     3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);
   
   SERVER   
   ---------
   DEDICATED
   1 row selected.
   

   To connect to a shared server session, connect with SYSBACKUP or SYSDBA privilege to inst1_shs and then execute the following SELECT statement (sample output included):

   SQL> SELECT SERVER 
     2  FROM   V$SESSION 
     3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);
   
   SERVER   
   ---------
   SHARED 
   1 row selected.
   

3. Start RMAN and connect to the target database using the dedicated service name. Optionally, connect to a recovery catalog.

   See Also:

   Your platform-specific Oracle documentation and the Oracle Database Net Services Reference for a complete description of Oracle Net connect string syntax

A data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, but the write did not occur in the persistent storage. On a subsequent block read, the I/O subsystem returns the stale version of the data block, which might be used to update other blocks of the database, thereby corrupting it.

You can set the DB_LOST_WRITE_PROTECT initialization parameter to TYPICAL or FULL so that a database records buffer cache block reads in the redo log. The default setting is NONE. When the parameter is set to TYPICAL, the instance logs buffer cache reads for read/write tablespaces in the redo log, but not read-only tablespaces. When set to FULL, the instance also records reads for read-only tablespaces. The performance overhead for TYPICAL mode is approximately 5 to 10% and potentially higher for FULL mode.

Lost write detection is most effective when used with Data Guard. In this case, you set DB_LOST_WRITE_PROTECT in both primary and standby databases. When a standby database applies redo during managed recovery, it reads the corresponding blocks and compares the SCNs with the SCNs in the redo log. If the block SCN on the primary database is lower than on the standby database, then it detects a lost write on the primary database and throws an external error (ORA-752). If the SCN is higher, it detects a lost write on the standby database and throws an internal error (ORA-600 [3020]). In either case, the standby database writes the reason for the failure in the alert log and trace file.

To repair a lost write on a primary database, you must initiate failover to the standby database. To repair a lost write on a standby database, you must re-create the entire standby database or restore a backup of only the affected files.

Enabling lost write detection is also useful when you are not using Data Guard. In this case, you can encounter a lost write in two ways: during normal database operation or during media recovery. In the first case, there is no direct way to detect the error. Indirect symptoms such as inconsistent tables cannot be unambiguously traced to the lost write. If you retained a backup made before the suspected lost write, however, then you can restore this backup to an alternative location and recover it. To diagnose the problem, recover the database or tablespace to the SCN of the stale block read, which then generates the lost write error (ORA-752).

If a lost write error is encountered during media recovery, the only response is to open the database with the RESETLOGS option. The database is in a consistent state, but all data after the RESETLOGS SCN is lost. If you recover a backup made after database creation, you have no guarantee that other stale blocks have not corrupted the database. This possibility exists because the restored backup may have been made after an earlier lost write. To guarantee that no lost writes have corrupted the database, you must perform media recovery from database creation, which is not a practical strategy for most database environments.