Best Practices for the Recovery Appliance

This chapter provides several practices that assist in optimally configuring the Recovery Appliance.

Oracle recommends following the operational best practices below when using Oracle Zero Data Loss Recovery Appliance, because they can help prevent issues that might impact performance, availability, or security.

• Modifying the Recovery Appliance configuration is limited. For details on specific restrictions and allowed configuration exceptions, refer to MOS note 2172842.1.

• Best practice for database protection is to enable real-time redo to Recovery Appliance, in which redo is automatically converted to archived log backups.

  If RMAN archive log backups are used instead, LOW compression algorithm is recommended for optimal balance of compression time and space savings.

• To ensure a stable and certified software environment, follow the recommended Recovery Appliance (RA) software configurations outlined in published My Oracle Support (MoS) note- KB202620, PNEWS2275..

  Before applying patches, review the ‘Zero Data Loss Recovery Appliance Supported Versions’ document (Doc ID 1927416.1) to avoid known critical issues and verify compatible software stack combinations.

• When removing databases from the Recovery Appliance, delete them one at a time, starting with the smallest database backups and progressing to the larger ones. Avoid submitting multiple delete requests simultaneously.

• Recovery Appliance operates with an initial Level 0 backup and Level 1 incremental backups thereafter. Refrain from taking multiple L0 backups, unless instructed by support.

• In a Data Guard architecture, backup the primary database to one Recovery Appliance and the standby database to another separate Recovery Appliance. Do not backup a Data Guard primary and the standby to the same Recovery Appliance.

• In a Data Guard architecture, do not send to the same Recovery Appliance backups from the primary and redo logs from the standby, or backups from the standby with redo logs from the primary.

• Dual backup strategies can be complex to maintain for long-term usage and should be avoided if possible. Dual backup strategies are designed for migration from non-Recovery Appliance solutions to an Oracle Zero Data Loss Recovery Appliance solution.

• Use multi section backups: For a Recovery Appliance backup of a bigfile tablespace with an 8K block size, use a SECTION SIZE of 64GB, because it allows for efficient processing in the Recovery Appliance’s flash cache.

  For 8k block size bigfile tablespaces > 16TB, use SECTION SIZE of 128GB.

  If you have extremely large datafiles (larger than 16TB), please open an SR for guidance.

• Run System Activity Report (SAR) on a daily basis and preferably during the same time of the day.

• Regularly monitor and review Enterprise Manager (EM) notifications for any errors or warnings generated by the Recovery Appliance to proactively identify and address potential issues before they become critical, ensuring optimal system performance and reliability.

  If the Oracle Enterprise Manager is not deployed in your environment, leverage the Recovery Appliance System Activity Report (SAR).

• Perform the Exachk health check monthly, thoroughly review the findings, and take corrective action as needed.

  Run Exachk before and after patching to ensure a smooth and successful upgrade process. To track changes over time, use the ‘diff’ command to compare the monthly Exachk reports, allowing for easy identification of new issues or changes in the system’s configuration.

• When integrating databases with a newly installed Oracle Zero Data Loss Recovery Appliance, stagger the initial Level 0 backups to avoid overwhelming the system.

• The following changes are considered best practices when working with the Recovery Appliance

  • CONFIGURE BACKUP OPTIMIZATION ON;

  • CONFIGURE CONTROLFILE AUTOBACKUP ON;

  • CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';

  • Enable the Block Change Tracking File feature.

  • Enable the Flashback Database feature with a minimum of 60-minute retention to avoid recreation of the standby database following a failover.

• Leverage the Data Guard Broker to configure real-time redo in a Data Guard environment for consistent management with existing broker configuration and settings.

• Maximize storage efficiency and improve backup and restore performance by enabling space-efficient encrypted backups.

  By setting RA_FORMAT=true in RMAN channel specification, backups are compressed and encrypted with incremental forever strategy, reducing backup and restore data volume over the network.

  Note that compressed data in the database is not compressed further in the backups.

• For databases with fluctuating workloads or when onboarding new databases to the Oracle Zero Data Loss Recovery Appliance, set the autotune_reserved_space parameter to allow the system to dynamically adjust and determine the optimal reserved space value based on the ingest workload, ensuring efficient resource allocation for space management activities.