About Real-Time Redo Transport

Redo data contains records of all changes made to a database and is therefore critical to minimizing data loss in the event of data failures. Using real-time redo transport substantially reduces the window of potential data loss that exists between successive archived redo log backups. When real-time redo transport is configured, archived redo log backups are transparent to the database administrator. The incoming redo stream from one or more protected databases is stored in the redo staging area on the Recovery Appliance. Protected databases can recover data up to the last change that the appliance received.

How Real-Time Redo Transport Works

With real-time redo transport enabled, Recovery Appliance becomes a remote destination for asynchronous redo transport services, similar to a standby database in an Oracle Data Guard environment. Redo data from the protected database is written asynchronously to the Recovery Appliance as it is generated. Load on production database servers is minimized because redo data is shipped directly from the memory to the Recovery Appliance without the involvement of disk I/O. As the redo stream is received, compressed archived log backups are created in the protected database's storage location every time a log switch occurs. The archived log backups generated by the Recovery Appliance are recorded in the Recovery Appliance catalog as normal backups and can be restored and applied to data files using the RMAN RECOVER command.

See Also:

Oracle Data Guard Concepts and Administration for information about asynchronous redo transport services

If the protected database crashes, redo data received from the current redo log group until the time of the crash is backed up at the Recovery Appliance as a "partial" archived redo log. If the protected database is reopened, crash recovery of the protected database will complete the current redo log group at the time of the crash, and the completed redo log will be re-shipped to the Recovery Appliance through the automatic Data Guard Gap fetching feature. The "complete" archived redo log will be used in any future restore/recover operations instead of the previously backed up "partial" archived redo log.

During recovery of a protected database, partial and complete archived logs are automatically restored as required to completely recover the protected database.

About Configuring Real-Time Redo Transport for Protected Databases

Real-time redo transport requires setup on the Recovery Appliance and the protected database. You need a redo transport user that will be used to authenticate and then send redo data from the protected database to the Recovery Appliance. This user must be the same as the Recovery Appliance user that will be used to send protected database backups to the Recovery Appliance. The credentials of this Recovery Appliance user are stored in an Oracle wallet on the protected database.

On the protected database, configure ARCHIVELOG mode and set up an archive destination for redo data (using the LOG_ARCHIVE_DEST_n parameter) that points to the service name of the Recovery Appliance.