Sizing Exadata - Oracle Exadata Recipes: A Problem-Solution Approach - page 131

RMAN level 0 backup, the disk space required for this will impact your overall usable capacity. Also, your decision
about how much archived redo to maintain on disk (in other words, inside an ASM group) as well as your frequency of
performing RMAN backups also has an effect on your usable capacity.
Another factor for many organizations is backup and recovery performance. Backups to ASM disk groups
containing a Fast Recovery Area are cell offloadable operations and can be very fast, but backups to external storage
devices (disk, tape, virtual tape, and so forth) typically incur more overhead. You can address this overhead by using
your high-speed, high-bandwidth InfiniBand network, a dedicated 10 GbE network, and using other Oracle RMAN
performance optimization techniques.

How It Works
Backing up your Oracle environments on Exadata is not much different than non-Exadata backups, but here are some
things to think about:

• Since your database storage will always be with Oracle ASM, you need to use RMAN to back

up your database files.

• When you fill out your Exadata DB Machine Configuration worksheet (please refer to Recipes 8-1,

9-2, and/or 9-3), you will be asked whether to back up to external media or internal to Exadata.
If you select external, the configuration process will establish at 80:20 split between DATA and
RECO , leaving 20% of the usable capacity for archive logs and other archived redo logs, one
plex of your online redo log groups, and flashback logs. I you choose “internal to the database
machine,” the configuration process will allocate at 40:60 split between DATA and RECO storage,
with 60% accounting for the aforementioned recovery structures/files plus RMAN backups.

• Your decision on whether to employ Flashback features, perform RMAN backups to your

FRA, and how long to retain recovery data (archive logs, and so forth) on disk can have a
profound impact on usable storage capacities. With non-Exadata storage arrays, there tends
to be a lower incremental cost to scale capacity for these types of purposes; on Exadata, if your
recovery policies alone push you from a Quarter Rack to a Half Rack, the cost of this jump is
generally considered nontrivial. You should be aware of this when designing your backup and
recovery strategy.

• Databases residing on Exadata tend to be “large.” When planning for large database backups,

ensure your network bandwidth is capable of supporting your backup operations. Since
Exadata is an engineered system with reserved and preconfigured network interfaces,
you won't have as much flexibility to add network cards or drastically change network
configurations as you may in non-Exadata systems. Oracle provides for an “additional
network” ( NET3 ) to address this and you can use 10 GbE NICs.

• When possible, leverage your InfiniBand network to facilitate faster backup and restore times.

An Oracle-centric architecture we've been successful with for both Exadata and Exalogic
backup solutions is comprised of leveraging the InfiniBand network as the backup network
and backing up to Oracle ZFS Storage Appliance shares over InfiniBand.

Oracle has written a backup and recovery best practices paper called Backup and Recovery Performance and
Best Practices for Exadata Cell and Oracle Exadata Database Machine, which you can download from
www.oracle.com/technetwork/database/features/availability/maa-tech-wp-sundbm-backup-11202-183503.pdf .
We strongly recommend reading this paper.