Restore and Recover the database
Use standard RMAN procedures for restore and recovery of the instances for all these scalable destinations. Refer section 5.5
for sample steps (exclude oracle cloud specific configuration steps)
BACKUP AND RECOVERY FOR ORACLE DATABASE APPLIANCE S|M|L
The Oracle Database Appliance S|M|L are single node configurations. Thus, these configurations do not provide high
availability that Oracle Database Appliance HA configurations provide. If an Oracle Database Appliance S|M|L server becomes
unrecoverable, in most cases, you must re-image, re-deploy, restore, and recover your system from backups.
When re-imaging the system, refer the My Oracle Support note titled “Oracle Database Appliance X6-2S, X6-2M and X6-2 L
(Doc ID 2144642.1”, to identify and download ISO image for the Operating System. You can then re-image the Oracle Database
Appliance S|M|L server using the ISO Image and redeploy the software using the standard process, which includes setting up
the operating system, and installing Grid Infrastructure and RDBMS software. Once the system has been redeployed, you can
restore and recover the database(s) from your backups using standard RMAN procedures.
DATABASE BACKUP AND RECOVERY BEST PRACTICES
This section outlines some of the core best practices when establishing your backup and recovery configuration in an Oracle
Database Appliance environment.
1. Choose backup location based on RTO/RPO requirements
During the Oracle Database Appliance deployment process, you are required to choose backup location and storage
mirroring. These choices determine storage allocation to the DATA and RECO disk groups. The placement of backups on
local storage has direct bearing on backup and recovery processes and time requirements. However, local storage on
Oracle Database Appliance is premium storage and limited to a maximum capacity and configuration. Choosing the
backup location and mirroring options appropriately should allow you to meet your requirements and objectives.
2. Use “weekly full and daily incremental” backup strategy
Incremental backups allow you to back up only those data blocks that have changed since a previous backup. Incremental
backups are thus efficient in terms of time and space requirements. The RMAN block change tracking feature for
incremental backups improves incremental backup performance by recording changed blocks in each data file in a
change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for
incremental backup, thus avoiding the need to scan every block in the data file at backup time.
To enable or disable block change tracking refer to the example below. Additional information can also be found in the
RMAN Incremental Backup documentation.
SQL>ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
SQL>ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
However, prior to you should evaluate if your RTO requirements can still be met if you choose to use this approach.
Incremental backup typically require substantially less time to execute, giving you the option to backup more frequently
and reduce RTO/RPO. By doing incremental backups, you also reduce network usage and network bandwidth
requirements when backing up over a network. Further, incremental database backups reduce backup overhead and read
I/O volume on the database.
3. Schedule archived log backup more frequently to reduce RPO
The archived redo logs residing on the system are vulnerable to loss in case of a complete system failure that renders the
whole system in an unrecoverable state. For this reason, archived redo logs are backed up to a separate external (often
remote) location. Choose a frequency of archived redo log backups that meets your requirements. Many customers use
a standby system to transfer redo data to the remote location to ensure minimal redo loss in case of a complete system
failure.
4. Validate backups
Perform RMAN CROSSCHECK operation on the backups to ensure validate backups.
RMAN> CROSSCHECK BACKUP;
5. Validate backups regularly to check for physical and logical corruptions
After a backup operation, use the RMAN BACKUP VALIDATE command to check the data files for physical corruptions.
To check for logical corruptions, include the CHECK LOGICAL clause in the BACKUP VALIDATE command.
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;
33 DB TECHNICAL BRIEF | Backup and Recovery Best Practices for the Oracle Database Appliance | Version 0.90
Copyright © 2021, Oracle and/or its affiliates