Databases Reference
In-Depth Information
•
When Exadata is configured, a diskgroup called RECO is usually created by default. This
diskgroup is created on the partitions closer to the center of the disk, which are slower in
performance. The high-performance peripheral parts of the disk are used for database storage.
•
Since the backup does not have to go over a transport medium, such as a network, this option
offers the fastest backup approach.
•
Finally, this is probably how it was configured by the Oracle on-site engineer. That means
there is nothing else to be done except starting up the RMAN command prompt.
There are always trade-offs. Disadvantages include:
•
The backups are inside the same rack. If the rack suffers a failure, both database and backups
are lost.
•
The overall space inside the Exadata rack is usually limited, especially for high-performance
disk configurations. If you create an FRA from those disks, you are going to deplete the space
even further for database use.
•
The special storage software is highly attractive for databases; not so much for backups. For
instance, Hybrid Columnar Compression available on Exadata storage is relevant only for
databases, not for backups. So using the storage for backups is a waste of their potential.
•
As of the writing of this topic, Exadata doesn't support mixing different types of disk
inside a rack. If you have a high-performance disk configuration, you also have to use that
configuration for RMAN backups, which do not usually require a high-performance disk.
wwSuch a configuration is therefore a waste of valuable resources.
•
Since database and backup are on the same physical disk, there is a possibility of contention.
•
Backup to tape needs RMAN media management layer (MML), which is generally an
extra-cost option, unless you use Oracle Secure Backup.
•
If you have many Exadata racks, you can't use the storage from all of them as a pool. You can
back up the database on one Exadata rack into the same rack, not another. If you want to use
the storage from the other racks, you have to cluster them together, which is complex and also
affects the databases running on the rack.
On an ASM Group Inside the Rack
Still within the rack, you have the option of backing up to an ASM diskgroup rather than to the FRA. Some organizations
do not allow FRAs to be created. Others have a strong preference against them. For whatever reason, if you choose
not to create an FRA, you do have the option to back up internally to the rack using an ASM diskgroup as your target
destination.
As you might surmise, the pros and cons of backing up to an internal ASM group are largely the same as for
backing up to an internal FRA. The approach is generally easy to use and performs well, but your backups are still
subject to failure of the rack.
On an ASM Group Outside the Rack
The single most obvious issue with the previous two approaches is the issue of single point of failure. If the Exadata
Rack fails, so does the backup. So, the equally obvious solution is to move the backup outside the rack. You could
create an ASM diskgroup on an external storage and use that as a backup location.
