Post on 21-Aug-2020
Technical Report
Deploying a Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp Brandon Hoang, NetApp
February 2012 | TR-4022
ABSTRACT
Maximize your investment in Oracle® Exadata and protect your Exadata production
environments by offloading and protecting primary backups, improving backup and recovery
options, and enabling flexibility and rapid cloning of Exadata databases on non-Exadata
infrastructure for development and test purposes with NetApp®.
2 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
TABLE OF CONTENTS
1 EXECUTIVE SUMMARY ........................................................................................................................ 3
2 INTRODUCTION .................................................................................................................................... 4
AUDIENCE ............................................................................................................................................................................ 4
SCOPE .................................................................................................................................................................................. 4
3 SOLUTION OVERVIEW ......................................................................................................................... 5
BUSINESS CHALLENGE ...................................................................................................................................................... 5
SOLUTION DESCRIPTION.................................................................................................................................................... 5
SOLUTION ARCHITECTURE ................................................................................................................................................ 6
SOLUTION DETAIL ............................................................................................................................................................... 8
4 SOLUTION IMPLEMENTATION .......................................................................................................... 10
PROTECTING EXADATA BACKUPS ................................................................................................................................. 10
PROVIDING BACKUP AND RECOVERY OPTIONS ........................................................................................................... 16
ENABLING RAPID DEV/TEST ............................................................................................................................................ 26
5 CONCLUSION ...................................................................................................................................... 33
6 REFERENCES ..................................................................................................................................... 33
LIST OF FIGURES
Figure 1) Solution summary. ......................................................................................................................... 5
Figure 2) Solution architecture. ..................................................................................................................... 7
Figure 3) Solution detail. ............................................................................................................................... 8
Figure 4) Protecting backups of Exadata databases. ................................................................................... 9
Figure 5) Providing additional backup and recovery options. ....................................................................... 9
Figure 6) Enabling rapid deployment of development and test environments. .......................................... 10
Figure 7) dNFS channels used for RMAN job. ........................................................................................... 12
Figure 8) Data Guard configuration consisting of Exadata primary and non-Exadata physical standby. .. 17
Figure 9) Physical standby database is receiving redo data from Exadata primary database. .................. 17
Figure 10) Exadata database is showing a missing datafile. ...................................................................... 20
Figure 11) Backing up physical standby database using SnapManager for Oracle. .................................. 23
Figure 12) Mounting the SMO backup of the physical standby database. ................................................. 24
Figure 13) Create a clone database from the backup. ............................................................................... 28
Figure 14) Error when attempting to read HCC data on non-Exadata storage. ......................................... 29
Figure 15) Storage savings when applying compression to a database with HCC data uncompressed. .. 31
Figure 16) Multiple clone databases can be quickly created from a single backup. .................................. 31
Figure 17) Multiple clone databases are created for a test environment. .................................................. 32
3 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
1 EXECUTIVE SUMMARY
Enterprises and service providers are deploying a variety of architectures and storage options to achieve
the specific requirements associated with their respective businesses. These requirements vary from
enterprise to enterprise and balance performance, price, availability, flexibility, and efficiency. These
requirements often lead to a hybrid environment where the tiered storage infrastructure includes multiple
vendors to optimize the end solution. Specifically, in high-performance Oracle Database environments,
many enterprises are looking to provide Exadata systems as the database platform, while leveraging
NetApp storage for backup and recovery as well as development and test environments.
The customers who deploy Exadata in production might want to further protect their Exadata environment
or provide additional means for backup and recovery. They might also want to improve the flexibility and
efficiency in cloning Exadata databases for development and test (dev/test) requirements. Using NetApp
storage, customers can implement a cost-effective backup and recovery solution and deploy a flexible
and efficient dev/test platform. Utilizing NetApp storage for such requirements allows customers to
concentrate Exadata resources on meeting core production operations, thus maximizing the investment in
Exadata.
Implementing a solution using non-Exadata components with NetApp storage to support an Exadata
production environment provides a highly efficient alternative. Leveraging industry-standard x64 servers
with Oracle enterprise software and NetApp storage technology, a solution can be architected to offload
and protect direct Oracle Recovery Manager (RMAN) backups of Exadata databases, provide remote
backup and recovery options for Exadata databases on non-Exadata hardware while preserving Hybrid
Columnar Compression (HCC) format, and create an infrastructure that is simpler and more efficient for
provisioning and cloning of Exadata databases to meet dev/test purposes.
NetApp storage platform and software deliver the efficiency and flexibility of the solution through the
following:
NetApp storage compression reduces the storage footprint of database volumes and backups.
Storage replication allows backups to be transferred to a remote site for further protection.
NetApp Snapshot™ and space-efficient FlexClone® enable rapid cloning of databases with minimal
storage consumption.
NetApp technologies allow customers to clone and provision Exadata databases in minutes and are highly storage efficient in maintaining multiple copies of the database clones.
The solution described in this report has been tested by Oracle and NetApp at the Oracle Solution Center
in North America.
4 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
2 INTRODUCTION
This document describes the use of non-Exadata hardware and software with NetApp storage systems to
implement a solution that supports Exadata production environments. The solution focuses on providing:
Backup protection, backup and recovery options for Exadata environments
Cloning of Exadata databases for development and test
For providing backup and recovery capability and simple dev/test environments, a solution that combines
NetApp storage with non-Exadata components can provide an optimal architecture. Such a solution can
present a lower cost structure and greater flexibility.
The proposed solution is made up of generic Linux® servers, Oracle enterprise software (RDBMS, RAC,
and Data Guard), and NetApp storage systems. Direct Exadata database backups are offloaded to
NetApp storage and replicated to a remote site for further protection. A replicated copy of the Exadata
database is maintained on non-Exadata infrastructure with NetApp storage, which serves as an additional
backup and recovery mechanism and can also be the target for cloning.
This document addresses the following areas of the solution:
Offloading direct RMAN backups of Exadata databases to NetApp storage and protecting backups on remote site with NetApp SnapMirror
®
Leveraging Oracle Data Guard to create physical standby database, which provides a means of backup for Exadata production database
Backing up and cloning of the physical standby database, using NetApp SnapManager® for Oracle, to
create a master clone database
Uncompressing HCC data on non-Exadata platform to enable reading of data
Rapid cloning of master clone database to create multiple clone databases for dev/test purposes
Recovering Exadata databases using physical standby database residing on non-Exadata platform
Recovering Exadata databases using SnapManager for Oracle backups of physical standby database
Applying NetApp storage compression on RMAN backups and clone databases to reduce storage consumption
AUDIENCE
This document is intended for IT professionals looking to deploy a backup and recovery and/or dev/test
solution on non-Exadata hardware to support Exadata production environments. The target audience
includes database administrators, data center managers, sales engineers (SEs), consulting sales
engineers (CSEs), professional services engineers (PSEs), professional services consultants (PSCs),
contracted delivery partners (CDPs), and channel partner engineers.
This document assumes familiarity with Oracle Database, Oracle RAC, Oracle Data Guard, and NetApp
storage and software.
SCOPE
This document illustrates the implementation of a backup and recovery and dev/test solution combined on
a non-Exadata platform to support an Exadata production environment.
The scope includes backup and recovery procedures, the decompression of HCC data, and the cloning of
Exadata databases on a non-Exadata platform. However, it does not cover the configuration and tuning
details of Exadata database machines. Contents that are specific to Exadata database machines are
available at www.oracle.com and/or support.oracle.com.
5 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
3 SOLUTION OVERVIEW
BUSINESS CHALLENGE
Customers who invest in Exadata database machines should make the most out of their Exadata
environments by supporting strictly production workloads. Nonproduction activities such as maintaining
backup and recovery sources and creating dev/test environments for Exadata databases can be run on
non-Exadata platforms to allow customers to take advantage of lower cost and a higher degree of
flexibility.
The intent of this solution is to provide customers with an alternative in implementing backup and
recovery and provisioning dev/test environments of Exadata production databases using non-Exadata
hardware and software.
This solution is designed to take into consideration the following elements:
The combined value of a backup repository and a dev/test environment
The ability to clone and provision Exadata databases in minutes
The ability to provide storage efficiency by maintaining multiple copies of database clones
The ability to provide increased flexibility and manageability in the overall infrastructure
The ability to utilize industry-standard hardware and software as much as possible to minimize the total cost of ownership of the solution
SOLUTION DESCRIPTION
To support an Exadata production environment, this solution addresses three fundamental areas:
protecting the Exadata production database, facilitating additional backup and recovery options, and
enabling the rapid provisioning of dev/test environments.
Figure 1) Solution summary.
Protect
Backup and
Recovery
Rapid
Dev/TestOracle Exadata
6 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
PROTECTING EXADATA PRODUCTION DATABASE
The solution protects the Exadata production environment in two ways:
Protecting RMAN backups of Exadata databases. RMAN backups are directed to NetApp storage. Backup sets are then replicated to a remote NetApp storage system for further protection. Backup sets are compressed while residing on NetApp storage to save space and minimize network bandwidth consumed by the replication. Storing RMAN backups of Exadata databases on external NetApp storage also means smarter and more effective use of Exadata storage space. It eliminates the use of precious Exadata storage capacity for ordinary backups, thus conserving it for essential database datafiles.
Protecting Exadata databases using physical standby databases. Oracle Data Guard is used to create and maintain the physical standby database for the Exadata production database. A physical standby database is an exact block-for-block copy of the Exadata production database. The physical standby therefore serves as a backup image of the production database. It is kept closely synchronized with the production database through the redo log application mechanism of Oracle Data Guard.
BACKUP AND RECOVERY
In addition to maintaining and protecting direct RMAN backups of Exadata databases, this solution also
provides options for the backup and recovery of Exadata databases:
Backup and recovery using physical standby database. As mentioned previously, the physical standby database is a copy of the Exadata production database. The physical standby database itself is a backup of the production database and can be used to recover an Exadata production database in case of loss of datafiles.
Backup and recovery with NetApp SnapManager for Oracle. SnapManager for Oracle supports the backing up of physical standby databases. Based on the same fundamental as described earlier, a backup image of the physical standby database created by SnapManager for Oracle can be used to recover the Exadata production database.
RAPID DEV/TEST
The solution leverages the unique underlying space-efficient Snapshot and thin-cloning technologies of
NetApp that enable databases to be cloned in minutes with minimal storage requirement.
SnapManager for Oracle (SMO) is NetApp’s backup, recovery, and cloning solution for Oracle Databases.
SMO is used to create backups and rapidly clone databases. SMO relies on NetApp’s core Snapshot and
FlexClone features to enable database cloning.
Storage compression is also applied to further improve storage efficiency by significantly reducing the
overall storage consumption. Exadata HCC data is uncompressed prior to cloning and provisioning
databases for dev/test purpose to make the data readable on non-Exadata infrastructure.
SOLUTION ARCHITECTURE
The solution takes advantage of standard Oracle enterprise software, generic Linux servers, and NetApp
storage platform to deliver a backup and recovery and dev/test infrastructure for Exadata production
environments.
Figure 2 provides an example of the solution’s overall environment. It consists of the Exadata production
environment running Oracle 11g Databases. The local NetApp storage system is directly attached to the
Exadata database machine using a 10 Gigabit Ethernet (10GbE) network to host RMAN backup sets and
to replicate them to a remote NetApp storage system for protection. The backup and dev/test
environment consists of standard Linux servers and NetApp storage with both Fibre Channel and 10GbE
connectivity. Oracle Data Guard provides database replication between the Exadata production
environment and the non-Exadata backup and dev/test environment. Gigabit (or WAN/LAN) networks
7 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
between the production site, Exadata, and the dev/test site, non-Exadata, are configured to support
Oracle Data Guard redo log transport and SnapMirror storage replication.
Figure 2) Solution architecture.
Oracle Exadata
FC Switch
10GbE
Switch
Gigabit
Network
10GbE
NetworkFibre Channel
Network
Oracle Data Guard
LAN
WAN
LAN
WAN
10GbE
Switch
Gigabit
Network
10GbE
Network
FAS2240-4FAS2240-4
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Mirrored
RMAN
Backups
Physical
Standby
Backups
Clone
Databases
Physical
Standby
HCC Master Clone
DB Non-HCC
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
RMAN
Backups
SnapMirror
NetApp Storage
Linux Servers Linux Servers
Exadata Production
Environment
Non-Exadata Backup and
Dev/Test Environment
RMAN
Gigabit
Network
The physical standby database in the backup and dev/test environment is a physical copy of the Exadata
production database, and thus it preserves the HCC data format. The physical standby database is then
cloned using SnapManager for Oracle to create a master clone database where HCC data is
uncompressed and storage compression is applied. Multiple non-HCC databases can subsequently be
provisioned by cloning the master clone database to meet the needs of the dev/test environment.
Deploying a backup and dev/test solution on standard hardware and software offers advantages as it
increases the overall flexibility and manageability of the solution. An example of increased flexibility is the
ability to virtualize the underlying infrastructure for databases for dev/test, if it is deemed appropriate and
is a requirement.
8 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
SOLUTION DETAIL
As explained previously, the solution includes three key areas: protecting backups, providing additional
backup and recovery options, and enabling rapid provisioning and cloning of the dev/test environment.
Figure 3 provides a closer look at the solution.
Figure 3) Solution detail.
NetApp Storage
NetApp Storage
Oracle Exadata
FAS2240-4FAS2240-4
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Production
Database on
Exadata with
HCC Data
Physical
Standby
Database with
HCC Data
Back up Physical
Standby Database
with SMO
Create Master Clone
from the Backup of
Physical Standby
Uncompress HCC
Data
Apply Storage
Compression
Leverage Master
Clone to Provision
more Databases
Using SMO
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Full and Incremental
RMAN BackupsMirror RMAN Backups
Using SnapMirror
Replicate Production Database
Using Oracle Data Guard
Restore Datafile(s) from SMO Backups
of the Physical Standby Database
Apply Storage
Compression to
RMAN Backups
Restore Datafile(s) Directly from
the Physical Standby Database
Back up Exadata
using RMAN over
dNFS/10GbE
PROTECT EXADATA BACKUPS
NetApp storage is used to host full and incremental RMAN backups of Exadata production databases.
The local NetApp storage is directly connected to the Exadata database machine using the 10GbE network connectivity (Exadata database machine is equipped with 10GbE network capability).
Oracle Direct NFS (dNFS) client is enabled on Exadata databases to improve RMAN backup speed and throughput.
For added protection RMAN backup sets are replicated to a remote NetApp storage system using storage replication technology and SnapMirror.
Storage compression is enabled to minimize the storage footprint of RMAN backup sets and to reduce network bandwidth required by replication.
The offloading of RMAN backups to NetApp storage saves critical Exadata storage resources that could be used for production database datafiles.
9 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 4) Protecting backups of Exadata databases.
NetApp Storage
NetApp Storage
Oracle Exadata
FAS2240-4FAS2240-4
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Physical
Standby
Database with
HCC Data
Back up Physical
Standby Database
with SMO
Create Master Clone
from the Backup of
Physical Standby
Uncompress HCC
Data
Apply Storage
Compression
Leverage Master
Clone to Provision
more Databases
Using SMO
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Replicate Production Database
Using Oracle Data Guard
Restore Datafile(s) from SMO Backups
of the Physical Standby Database
Restore Datafile(s) directly from
the Physical Standby Database
Full and Incremental
RMAN Backups
Apply Storage
Compression to
RMAN Backups
Production
Database on
Exadata with
HCC Data Back up Exadata
using RMAN over
dNFS/10GbE
Mirror RMAN Backups
Using SnapMirror
PROVIDE BACKUP AND RECOVERY OPTIONS
The physical standby database is deployed on the backup and dev/test site by using Oracle Data Guard.
The physical standby database is closely kept in sync with the Exadata production database, and it is therefore an up-to-date backup image of the production database.
The physical standby database preserves the HCC data format.
The physical standby database’s datafile can be copied and used for recovering the Exadata production database in case of loss of datafiles.
SnapManager for Oracle is used to create backups of the physical standby database. This provides an indirect but additional backup option to the solution.
The backups of the physical standby database created by SnapManager for Oracle can be mounted and transferred to the Exadata environment to be used for recovery.
Figure 5) Providing additional backup and recovery options.
NetApp Storage
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Full and Incremental
RMAN Backups
FAS2240-4FAS2240-4
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Back up Exadata
using RMAN over
dNFS/10GbE
Apply Storage
Compression to
RMAN Backups
Mirror RMAN Backups
Using SnapMirror
NetApp Storage
Oracle Exadata Create Master Clone
from the Backup of
Physical Standby
Uncompress HCC
Data
Apply Storage
Compression
Leverage Master
Clone to Provision
more Databases
Using SMO
Production
Database on
Exadata with
HCC Data
Physical
Standby
Database with
HCC Data
Restore Datafile(s) Directly from
the Physical Standby Database
Replicate Production Database
Using Oracle Data Guard
Restore Datafile(s) from SMO Backups
of the Physical Standby Database
Back up Physical
Standby Database
with SMO
10 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
ENABLE RAPID DEV/TEST
The backup of the physical standby database created by SnapManager for Oracle is used to clone and provision a master clone database.
The HCC data in the master clone database is uncompressed using Oracle Database procedure
(covered later in this document) to make the data readable on non-Exadata hardware.
After HCC data is uncompressed, NetApp storage compression is applied on the database volumes to reduce active storage consumption.
Multiple clone databases can then be rapidly cloned and provisioned for development and testing. These clones inherit storage compression characteristic from the master clone and thus storage savings.
Figure 6) Enabling rapid deployment of development and test environments.
FAS2240-4FAS2240-4
FAS2240-4FAS2240-4
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
DS4243
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
3.0TB
Back up Physical
Standby Database
with SMO
NetApp Storage
Create Master Clone
from the Backup of
Physical Standby
Uncompress HCC
Data
Apply Storage
Compression
Leverage Master
Clone to Provision
more Databases
Using SMO
4 SOLUTION IMPLEMENTATION
This section describes how to implement the backup and dev/test solution to support an Exadata
production environment. It focuses on the application and usage of the key technology components in
meeting the objectives of the solution. For specific product installation and configuration procedures, refer
to the respective product documents provided by the technology vendors.
To cover the three fundamental aspects of the solution, the implementation details are arranged into the
following categories:
Protecting Exadata Backups
Providing Backup and Recovery Options
Enabling Rapid Dev/Test
PROTECTING EXADATA BACKUPS
Direct RMAN backups of Exadata databases can be offloaded to NetApp storage to provide several
benefits; Exadata storage resources, which are premium, can be saved and hence utilized for storing
critical database datafiles. RMAN backup sets that are stored on immediate NetApp storage can further
be protected by replicating them to a remote NetApp storage system.
Using NetApp storage allows customers to take advantage of its cost-effective, high-performance disk-
based storage and large capacity for maintaining database backups. NetApp storage platforms can
11 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
support up to a maximum storage capacity of 4.3TB in a single storage system. In addition, the NetApp
unified storage platform is recognized for providing industry-leading storage efficiency technologies such
as Snapshot, space-efficient clone, compression, and deduplication.
The Oracle dNFS client is highly recommended and should be enabled on the Exadata database
machine to improve RMAN backup throughput and speed. Oracle dNFS is a high-performance NFS client
that delivers exceptional performance for Oracle RMAN backup and restore operations. dNFS should be
configured for customers seeking maximum throughput for backup and restore operations. Storage
compression is enabled on the RMAN backup volumes to reduce the storage footprint occupied by the
backup sets. Storage replication, SnapMirror, is established between the source NetApp storage system
and the remote NetApp storage system to replicate RMAN backup sets to a remote location.
The following steps are covered:
1. Enabling and configuring dNFS on the Exadata database machine
2. Backing up the Exadata database with RMAN
3. Enabling storage compression on RMAN backup repository
4. Utilizing NetApp SnapMirror to replicate RMAN backup sets to the remote storage system
Prerequisites:
NetApp storage system is connected to the Exadata database machine using the 10GbE network connection. (Exadata database machine is equipped with 10GbE network interfaces on each database server. NetApp storage system is provisioned with 10GbE network ports.)
NetApp volume to be used for hosting RMAN backups is provisioned and mounted on the Exadata database machine. The NetApp volume has to be created as a 64-bit volume in Data ONTAP® 8.0.X to use storage compression. Use thin provisioning to allow more efficient use of storage.
Jumbo frames (MTU 9000) should be enabled on the 10GbE network between the Exadata database machine and the NetApp storage system. Jumbo frames can improve network throughput and lower the CPU utilization on the database servers.
ENABLING AND CONFIGURING DNFS ON THE EXADATA DATABASE MACHINE
The Oracle dNFS client is a highly threaded, scalable, and optimized client for Oracle Database I/Os. It
should be used in place of regular/kernel NFS client. Backing up large-scale and high-performance
Exadata databases can demand significant backup throughput, which can be best achieved with Oracle
dNFS.
1. Mount the volume to be used for hosting the RMAN backups on the Exadata database machine, using the following mount options:
rw,bg,hard,rsize=65536,wsize=65536,vers=3,nointr,suid,timeo=600,tcp
2. To enable the dNFS client, enter:
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk dnfs_on
3. The oranfstab file is the configuration file for the dNFS. The oranfstab file is required if multiple network paths are to be used for dNFS load balancing or if the network path to be used for the dNFS traffic is different from the management network path of the storage system (such as in the case of 10GbE network being dedicated for dNFS traffic while the gigabit network is used as the management network to access the storage system). The following is an example of the oranfstab using a single network path ($ORACLE_HOME/dbs/oranfstab):
server: netapp2
local: 192.168.20.66 path: 192.168.20.11
export: /vol/nfs_rman_backup/nfs_rman_backup.qt mount: /rman_backups
12 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
After enabling and configuring the dNFS client on the Exadata database machine, the database and all
instances have to be restarted for dNFS to take effect. For production databases, this should be
conducted as part of the planned downtime.
When enabling dNFS on Exadata database machine, the number of dNFS connections to the NetApp
storage server is determined by the number of RMAN channels multiplied by the number of network paths
to the storage server. Each RMAN channel translates to one RMAN server (background) process. For
each Oracle background (or foreground) process, one dNFS connection (also known as "channel") is
created per network path. Figure 7 is an example of an RMAN backup job with two RMAN channels
configured to run under dNFS. Figure 7 reports the number of files being opened by dNFS and the dNFS
channels established.
Figure 7) dNFS channels used for RMAN job.
Tuning TCP Kernel Parameters on Exadata Database Server and NetApp Storage System
When using dNFS over 10GbE networks, the TCP layer should be tuned for maximum bandwidth by
adjusting some operating system kernel parameters related to TCP. The following kernel parameters
should be set on the Exadata database servers (under /etc/sysctl.conf):
#Receive socket buffer size:
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
#Send socket buffer socket size:
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
#TCP socket buffer size:
net.ipv4.tcp_rmem = 4096 262144 4194304
net.ipv4.tcp_wmem = 4096 262144 4194304
In the NetApp storage system, the TCP send and receive window sizes can be set as follows:
#TCP receive window size:
nfs.tcp.recvwindowsize=262144
#TCP transfer window size:
nfs.tcp.xfersize=65536
13 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
In addition to the preceding TCP kernel tunings, Oracle also recommends disabling the cpuspeed and
irqbalance Linux services on the Exadata database machine if they are not required. cpuspeed is a
daemon that dynamically adjusts the CPU speed and voltage based on the demand for CPU and
automatically detects available CPU speeds. irqbalance is a Linux daemon that distributes interrupts
among the processors and cores in the system. Both of these features are designed to deliver a balance
between power savings and optimal performance. Having these features enabled might interfere with the
throughput of TCP and network operations. They can be disabled by using the following commands:
chkconfig cpuspeed off
service cpuspeed stop
chkconfig irqbalance off
service irqbalance stop
BACKING UP THE EXADATA DATABASE WITH RMAN
RMAN is the only method that can be used to directly back up databases on the Exadata database
machine. You can schedule full and incremental RMAN backups to meet the backup requirements of
Exadata databases. Use multiple RMAN channels to improve the backup throughput and speed. NetApp
recommends enabling block change tracking. RMAN block change tracking allows incremental backups
to complete more quickly. With block change tracking, only the database blocks that have been modified
since the last incremental backup or full backup are read from disk.
If database services are being used with RMAN (that is, if RMAN is connected to the target database
using a database service), RMAN will automatically distribute the channels over the available instances
on which a database service is running. On an Exadata platform, Oracle recommends that RMAN backup
runs on one instance; therefore, configure the service used for the RMAN backup such that it runs on a
single instance at any one time.
The following example describes the creation of a service to be used for RMAN backup where the service
is only active on one node/instance at a time:
srvctl add service -d NET28D -r NET28D1 -a NET28D2 -s NET28D_RMAN_SVC
srvctl start service -d NET28D -s NET28D_RMAN_SVC
To connect RMAN to the target database using the service:
% rman target sys/<password>@<service name>
For example, connecting RMAN to the target database using a database service name
NET28D_RMAN_SVC:
rman target sys/oracle@NET28D_RMAN_SVC
To support RMAN backup and restore operations on a high-performance system such as Oracle Exadata,
a number of parameters related to RMAN buffers must be tuned for optimal performance:
The number and size of buffers used to create and restore backup pieces/sets using DISK channels:
_backup_disk_bufcnt / _backup_disk_bufsz
The number and size of buffers used for all backup and restore operations:
_backup_file_bufcnt / _backup_file_bufsz
14 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Best Practice
For backup and restore operations, the number of buffer (buffer count) is recommended to be set to 64:
_backup_disk_bufcnt=64
_backup_file_bufcnt=64
For backup operations, the buffer sizes are recommended to be set as follows:
_backup_disk_bufsz=1048576
_backup_file_bufsz=4194304
For restore operations, the buffer sizes should be set to:
_backup_disk_bufsz=131072
_backup_file_bufsz=131072
There are two ways to set the preceding RMAN parameters. They may either be configured in the server
parameter file (spfile) or be set dynamically in the RMAN backup/restore script within the run block.
The following example shows an RMAN backup script used for creating an image copy of the database
where it includes the SQL Server® statements to dynamically set the RMAN buffer parameters.
run
{
sql 'alter system set "_backup_file_bufcnt"=64';
sql 'alter system set "_backup_file_bufsz"=4194304';
allocate channel d1 type disk;
allocate channel d2 type disk;
backup as copy database format '/rman_backups/NET28D/df_t%t_s%s_p%p';
release channel d1;
release channel d2;
}
For details on RMAN performance tuning, see article ID 1072545.1: RMAN Performance Tuning Using
Buffer Memory Parameters at support.oracle.com.
ENABLING STORAGE COMPRESSION ON RMAN BACKUP REPOSITORY
Beyond the use of thin provisioning during volume creation to take advantage of storage efficiency for
RMAN backup repository, storage compression should also be applied to further minimize storage
consumption. RMAN backup repository is a great target for storage compression. RMAN backup sets,
image copies, and full and incremental backups are typical candidates that can benefit from compression.
Storage deduplication, in contrast, is usually not effective when applied to Oracle datafiles due to the
uniqueness of the Oracle block (Oracle block is structured with a unique header and a highly variant block
tail). However, deduplication might be considered for RMAN backup repository. An RMAN backup
repository might contain multiple full backups or database image copies and not just distinct incremental
backups. Multiple full backups or image copies of a database could result in overlapping data and similar
blocks. Therefore, applying deduplication would allow customers to realize storage savings.
The following is an example that shows the storage savings on an RMAN backup repository that has
been enabled with storage compression and deduplication. The RMAN repository contains multiple full
and incremental backup sets and image copies.
15 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Storage compression and deduplication are licensed features; therefore, prior to enabling deduplication
and compression, a valid license must exist on the NetApp storage system.
To enable NetApp storage compression and deduplication on a volume, run the following commands.
These commands have to be executed on the NetApp storage system.
To enable deduplication on the volume:
sis on <path>
For example: sis on /vol/nfs_rman_backup
To enable compression on the volume:
vol options <volume name> compression on
Storage savings resulted from deduplication and compression can be viewed by running the ‘df –S’
command on the NetApp storage system.
UTILIZING NETAPP SNAPMIRROR TO REPLICATE RMAN BACKUPS TO THE REMOTE STORAGE SYSTEM
NetApp storage systems are designed to provide a high degree of availability for data through the use of
redundant hardware components and a double-parity RAID (RAID-DP®) internal file system. RMAN
backups that reside on NetApp storage system naturally benefit from the integrated protection features.
To further improve the level of backup and protection, RMAN backups of Exadata databases that are
hosted on the local NetApp storage system can be mirrored/replicated to a remote NetApp storage
system to enable remote backup and protection. A remote copy of the backups can assist in the recovery
effort in case of site failures or disasters.
Mirroring provides a mechanism to facilitate data availability and minimize downtime. NetApp SnapMirror
is a storage replication solution that offers a fast and flexible enterprise solution for mirroring or replicating
data over local area, wide area, and Fibre Channel (FC) networks. SnapMirror can be a key component in
implementing enterprise data protection strategies.
SnapMirror uses block-level updates to reduce bandwidth and time requirements. Data can be replicated
between dissimilar NetApp storage systems. SnapMirror provides synchronous, semi-synchronous, and
asynchronous replication capabilities. SnapMirror also supports network compression to allow efficient
use of network bandwidth. SnapMirror network compression is useful where network bandwidth between
the primary and the destination site might be a limitation or there is a need to conserve bandwidth for
other functions.
For the purpose of replicating RMAN backups, asynchronous mode is recommended to enable the
replication process to be scheduled on a specified, regular interval. Assuming both full RMAN backups
and daily incremental backups usually complete by 2 a.m. each day, SnapMirror could be configured to
initiate the replication every day at 3 a.m.
The following is an example of a SnapMirror configuration file (snapmirror.conf) that specifies the
replication of an RMAN backup repository from the primary storage system, netapp2, to the destination
storage system, netapp1, to occur at 3 a.m. every day. The source volume is nfs_rman_backup on
storage system netapp2, and the destination volume is nfs_rman_backup_mirror on storage system
netapp1. SnapMirror network compression is enabled to minimize replication network bandwidth.
#snapmirror.conf
netapp2:nfs_rman_backup netapp1:nfs_rman_backup_mirror compression=enable 0 3 * *
The destination needs to be restricted prior to establishing the SnapMirror relationship. The destination
volume can be marked as restricted by using the ‘vol restrict‘ command:
vol restrict nfs_rman_backup_mirror
16 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Subsequently the SnapMirror relationship can be initialized. This process creates an initial complete
(baseline) copy of the source volume on the destination and starts the mirroring process:
snapmirror initialize -S netapp2:nfs_rman_backup netapp1:nfs_rman_backup_mirror
For details on how to prepare the storage systems for SnapMirror use and how to configure SnapMirror
options, see Data ONTAP 8.X 7-Mode Data Protection Online Backup and Recovery Guide at the NetApp
Support site.
PROVIDING BACKUP AND RECOVERY OPTIONS
In addition to using RMAN as the primary method to create backups of Exadata databases, secondary
and remote backup options can be accomplished by employing Oracle Data Guard. Oracle Data Guard is
a high-availability data protection and disaster recovery solution for Oracle Databases. Oracle Data
Guard enables standby databases to be created and maintained as transactionally consistent copies of
the production database.
A physical standby database is a type of standby database that provides a physically identical copy of the
primary database, block for block. The physical standby database is kept synchronized with the primary
database using redo log apply, which recovers the redo data received from the primary database and
applies the redo to the physical standby database.
Having a physical standby of Exadata production database on a non-Exadata environment inherently
provides a copy of the production database, which is equivalent to a backup. Therefore, the datafiles of
the physical standby database residing on a non-Exadata platform can be used to recover the Exadata
production database.
The second remote backup option is established using NetApp SnapManager for Oracle based on the
similar principle as described earlier. NetApp SnapManager for Oracle is an Oracle Database backup and
cloning solution. SMO supports the backing up of an Oracle physical standby database. SMO can be
used to create a backup of the physical standby database, which then can serve as a backup source for
recovering the Exadata production database.
The following steps are covered:
1. Providing remote backup of Exadata database using Oracle Data Guard physical standby database
2. Recovering Exadata database using the physical standby database
3. Backing up the physical standby database using NetApp SnapManager for Oracle
4. Recovering Exadata database using SnapManager for Oracle backups of the physical standby database
PROVIDING REMOTE BACKUP OF EXADATA DATABASE USING ORACLE DATA GUARD PHYSICAL STANDBY DATABASE
A physical standby database can be established on a distant, non-Exadata environment to provide a
remote copy of the Exadata production database. The physical standby database can be kept closely
synchronized with the production database to meet strict recovery point objectives (RPOs) and recovery
time objective. Because the physical standby database is a physically identical duplicate of the Exadata
production database with the same on-disk structure, any HCC data on the Exadata production
environment is replicated, and its data format is preserved.
Oracle Data Guard offers three protection modes: maximum protection, maximum availability, and
maximum performance. The intent in using the Data Guard physical standby database here is to provide
a remote backup of the production database, and thus maximum performance mode is recommended.
Maximum performance mode operates with an asynchronous transaction commitment method in which
transactions are committed as soon as they are written to the redo logs of the primary database. Redo
data is asynchronously transferred and written to the standby database. This mode makes it possible to
17 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
keep the physical standby database in close synchronization with the production database without
affecting the performance of the production database.
Figure 8 shows a Data Guard configuration that consists of the Exadata production database, NET28D,
and the physical standby database, NET28DS, where the physical standby database is running in a non-
Exadata environment. The Data Guard configuration is operating in maximum performance mode.
Figure 8) Data Guard configuration consisting of Exadata primary and non-Exadata physical standby.
The redo data from the Exadata database is being written to the physical standby database on the remote
non-Exadata environment to maintain close transaction synchronization (Figure 9).
Figure 9) Physical standby database is receiving redo data from Exadata primary database.
For detailed procedures to configure Oracle Data Guard and to create a physical standby database, refer
to Oracle Data Guard Concepts and Administration 11g Release 2 (11.2). The following examples are
provided to demonstrate the Oracle Database initialization parameters and settings that are related to
configuring Oracle Data Guard. In this context, the physical standby database is configured to serve as
the backup of the production database. It is explicitly intended not to act as a failover target for the
production database. The two sets of parameters are from the production (primary) database and the
Physical Standby Database – non-Exadata
Primary Database – Exadata
18 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
physical standby database. The DB_UNIQUE_NAME of the primary database and the physical standby
database are NET28D and NET28DS, respectively.
The following are the initialization parameters of the primary database on the Exadata environment:
*.audit_file_dest='/u01/app/oracle/admin/NET28D/adump'
*.audit_trail='db'
*.cluster_database=true
*.compatible='11.2.0.2.0'
*.control_files='+NETDATA/net28d/controlfile/current.265.761319659'
*.db_block_size=8192
*.db_create_file_dest='+NETDATA'
*.db_domain=''
*.db_lost_write_protect='TYPICAL'
*.db_name='NET28D'
*.db_recovery_file_dest='+NETRECO'
*.db_recovery_file_dest_size=314572800000
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP)(SERVICE=NET28DXDB)'
*.fast_start_mttr_target=300
*.filesystemio_options='SETALL'
NET28D2.instance_number=2
NET28D1.instance_number=1
*.log_buffer=134217728
*.open_cursors=1000
*.parallel_adaptive_multi_user=FALSE
*.parallel_max_servers=240
*.parallel_threads_per_cpu=1
*.pga_aggregate_target=17179869184
*.processes=1024
*.remote_listener='exa2-scan:1521'
*.remote_login_passwordfile='exclusive'
*.sga_target=17179869184
NET28D2.thread=2
NET28D1.thread=1
NET28D1.undo_tablespace='UNDOTBS1'
NET28D2.undo_tablespace='UNDOTBS2'
*.DB_UNIQUE_NAME='NET28D'
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(NET28D,NET28DS)'
*.LOG_ARCHIVE_DEST_1=
'LOCATION=+NETRECO/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=NET28D'
*.LOG_ARCHIVE_DEST_2=
'SERVICE=NET28DS ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=NET28DS'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.LOG_ARCHIVE_MAX_PROCESSES=30
The following are the initialization parameters of the physical standby database on the non-Exadata
environment:
*.audit_file_dest='/export/home/oracle/app/admin/NET28D/adump'
*.audit_trail='db'
*.cluster_database=true
*.compatible='11.2.0.2.0'
*.control_files='+DATA_NET28D/net28d/controlfile/control01.ctl','+DATA_NET28D/net28d/c
ontrolfile/control02.ctl'
*.db_block_size=8192
*.db_create_file_dest='+DATA_NET28D'
*.db_domain=''
19 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
*.db_lost_write_protect='TYPICAL'
*.db_name='NET28D'
*.db_recovery_file_dest='+FRA'
*.db_recovery_file_dest_size=425931571200
*.diagnostic_dest='/export/home/oracle/app'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=NET28DXDB)'
*.fast_start_mttr_target=300
*.filesystemio_options='SETALL'
*.db_unique_name='NET28DS'
*.db_create_online_log_dest_1='+LOG_NET28D'
*.db_file_name_convert='+NETDATA','+DATA_NET28D'
*.FAL_SERVER='NET28D'
NET28DS1.instance_number=1
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(NET28D,NET28DS)'
*.LOG_ARCHIVE_DEST_1='LOCATION=+FRA/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=NET28DS'
*.LOG_ARCHIVE_DEST_2='SERVICE=NET28D ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=NET28D'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.log_archive_format='%t_%s_%r.dbf'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.log_file_name_convert='+NETDATA/NET28D/','+LOG_NET28D/NET28D/'
*.job_queue_processes=1000
*.log_buffer=134217728
*.open_cursors=1000
*.parallel_adaptive_multi_user=FALSE
*.parallel_max_servers=240
*.parallel_threads_per_cpu=1
*.pga_aggregate_target=4294967296
*.processes=500
*.remote_listener='devtestcluster-scan:1521'
*.remote_login_passwordfile='exclusive'
*.sga_target=4294967296
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.undo_management='AUTO'
NET28DS1.thread=1
NET28DS1.undo_tablespace='UNDOTBS1'
RECOVERING EXADATA DATABASE USING THE PHYSICAL STANDBY DATABASE
The physical standby database running on a non-Exadata platform can be used to recover the Exadata
production database. If a datafile on an Exadata production database is corrupt or accidentally deleted,
the corresponding datafile on the physical standby database can be copied and made available to the
Exadata environment to enable the recovery.
Figure 10 is an example that demonstrates the recovery process. In this scenario, an Exadata production
database is missing a datafile (datafile 7 was actually deleted from ASM).
20 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 10) Exadata database is showing a missing datafile.
To perform the recovery exercise:
1. Copy the corresponding datafile on the physical standby database. The datafile 7 on the physical standby database is copied to a NetApp NFS volume that is also mounted on the Exadata database
machine. The RMAN ‘backup as copy datafile’ command is used to make a copy of the datafile.
2. Once the backup copy of the datafile is available in the Exadata production environment, it can be
cataloged with the production database (the RMAN ‘catalog datafilecopy’ command is executed
while connected to the production database).
21 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
3. Restore the datafile on the Exadata production database.
4. Recover the datafile.
22 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
5. As it is fully restored and recovered, the datafile can be brought online, or the database can be opened successfully.
23 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
BACKING UP THE PHYSICAL STANDBY DATABASE USING NETAPP SNAPMANAGER FOR ORACLE
As explained previously, the physical standby database is a backup copy of the production database.
Therefore, a backup of the datafiles of the physical standby database is also a valid backup for the
production database.
NetApp SnapManager for Oracle is a unique solution that helps to automate and simplify the backup,
restoration, recovery, and cloning of Oracle Databases on the NetApp storage platform. SMO takes
advantage of NetApp core features Snapshot and FlexClone, which makes it a very efficient solution.
Multiterabyte databases can be backed up and cloned in minutes with a few clicks.
As SnapManager for Oracle supports the backing up and cloning of physical standby databases, it is
illustrated here that SnapManager is used to quickly create a backup of the physical standby database.
Figure 11 displays the completed backup operation of the physical standby database, NET28DS, using the
SnapManager for Oracle solution.
Figure 11) Backing up physical standby database using SnapManager for Oracle.
24 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
RECOVERING EXADATA DATABASE USING SNAPMANAGER FOR ORACLE BACKUPS OF THE PHYSICAL STANDBY DATABASE
The backup of the physical standby database created by SnapManager for Oracle can be used to assist
in the recovery of the Exadata production database. The recovery principle and the steps involved in
recovering the production database are similar to those of the recovery method when using datafile copy
of the physical standby database.
There is one distinguishing step that is required when using SMO backups for recovery. SMO backup
must first be mounted to make it accessible on the non-Exadata environment before it can be copied over
to the Exadata environment.
Figure 12 shows the SMO backup of a physical standby database, NET14DS that has been successfully
mounted.
Figure 12) Mounting the SMO backup of the physical standby database.
1. The SMO mount operation essentially attaches the backup volumes to the database server and brings the ASM diskgroups of the backup volumes online. To avoid a naming conflict with existing ASM diskgroups, SMO renames the ASM diskgroup of the backup volumes to a temporary name (for
example, SM_DG_1316623630653) before it brings the diskgroup online.
2. The ASM diskgroup is now online, and the datafiles within the diskgroup are accessible. Using asmcmd commands, the target datafile can be copied from the ASM diskgroup and transferred to the
25 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Exadata environment. As shown in the figure below, the datafile D14.260.762163997 is being copied
to a NetApp NFS share that is also mounted on the Exadata environment.
3. The target datafile is available on the Exadata production environment. It is then cataloged on the production database.
4. The datafile is restored.
26 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
5. Perform the recovery.
6. The datafile on the Exadata production database is recovered, and the database can be opened.
ENABLING RAPID DEV/TEST
NetApp is recognized as a leading vendor in the area of Oracle Database provisioning and cloning for
dev/test environments. Its core underlying storage technologies such as Snapshot, space-efficient
FlexClone, and manageability solutions such as SMO allow databases to be backed up, cloned, and
provisioned using a fraction of the time and space required when compared to traditional cloning
methods. Significantly reducing the duration of the cloning and provisioning stages in the dev/test cycle
can lead to shorter time to market or enable more time to be used for developing and testing.
For some workloads that run on the Exadata platform, deploying dev/test environments on a non-Exadata
platform might be acceptable. If the workloads can take advantage of operating on a non-Exadata
platform for dev/test purposes, customers might benefit from the cost advantage, degree of flexibility, and
ease of management of non-Exadata infrastructure.
27 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
The solution enables the rapid creation of dev/test environments for Exadata databases through the
cloning of the physical standby database. SnapManager for Oracle is the key component in swiftly
deploying clone database environments for development and testing. SnapManager for Oracle truly
simplifies and accelerates the database backup and cloning processes.
SnapManager for Oracle is used to create a backup of the physical standby database. The backup of the
physical standby database serves as the source in generating a clone database. Unlike the physical
standby database, the clone database is a fully open database that can be read and written to. Because
the HCC data format cannot be processed on non-Exadata hardware, any HCC data that exists in the
clone database is then uncompressed to remove the HCC format so as to make it readable. Once the
clone database no longer contains HCC data, it is treated as being the "master" clone. The master clone
database is subsequently used for creating and provisioning more clone databases to satisfy dev/test
needs. The volumes of the master clone database are enabled with storage compression to reduce the
storage footprint prior to producing other clones. Enabling compression on the master clone volumes
permits the succeeding clones to inherit the compression savings and settings, leading to greater overall
storage savings.
The following steps are covered:
1. Cloning a database from the backup of the physical standby database using SnapManager for Oracle
2. Uncompressing Hybrid Columnar Compression data in the clone database
3. Enabling storage compression on master clone volumes
4. Creating clone databases for development and testing from the master clone database
CLONING A DATABASE FROM THE BACKUP OF THE PHYSICAL STANDBY DATABASE USING SNAPMANAGER FOR ORACLE
When deploying databases on a non-Exadata platform with NetApp storage, the task of creating backups
and clones of databases is made very simple and quick by the use of SnapManager for Oracle.
The physical standby database that resides on non-Exadata and NetApp storage can be cloned in a few
minutes, requiring just a few clicks within SnapManager for Oracle. Figure 13 shows an example of how a
backup of a database can be leveraged to create a clone database by simply selecting the clone option.
The database being referenced in the screenshot, NET14DS, is a physical standby database of an Exadata
primary database.
28 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 13) Create a clone database from the backup.
UNCOMPRESSING HYBRID COLUMNAR COMPRESSION DATA IN THE CLONE DATABASE
The Exadata HCC data format was developed by Oracle for the Exadata platform; therefore, it is specific
to the Oracle storage products, which results in HCC data being unreadable when deployed on non-
Oracle hardware. However, the HCC data format can be easily removed by converting data to regular
format, a process that is sometimes referred to as "uncompressing." Uncompressing HCC data on a non-
Exadata environment converts the data to standard format, which can be read and processed on any
platform. In the case of NetApp technologies, HCC data is uncompressed only once, and then thin
clones are created on demand, thus providing multiple space efficient virtual database copies.
In an Exadata production environment where HCC data is enabled, the physical standby database of the
target production database will carry over and preserve the HCC data format. Thus the immediate master
clone of the physical standby database will contain HCC data. HCC data needs to be uncompressed to
make the data readable prior to creating further clone databases.
An attempt to read HCC data on a non-Exadata platform results in a message that indicates that HCC is
only supported on Exadata storage, such as shown in Figure 14.
Create a master
clone database
by cloning from a
backup of the
physical standby
database
29 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 14) Error when attempting to read HCC data on non-Exadata storage.
HCC data is usually enabled on a tablespace or on individual tables. There are a number of ways to
determine which tables and their partitions contain HCC data.
If a tablespace is enabled with compression, the tables that are created within the HCC-enabled
tablespace will inherit the compression unless the tables are explicitly overridden by the DLL during their
creation.
Tables that have been enabled with compression can be identified by querying the dba_tables view:
select table_name, partitioned, compression, compress_for from dba_tables where
compression = 'ENABLED';
If the HCC-enabled tables are partitioned tables, the information will be available using the
dba_tab_partitions view:
select table_name, partition_name, compression, compress_for from dba_tab_partitions
where compression = 'ENABLED';
HCC-enabled tables and partitions have compression types of QUERY LOW, QUERY HIGH, ARCHIVE LOW, or
ARCHIVE HIGH. The compression type is indicated by the result of the compression_for field from the
two preceding queries. The compression type is used to identify tables and partitions with HCC data.
The following is an example showing three partitioned tables that contain HCC data:
SQL> select table_name, compression, compress_for from dba_tab_partitions
where table_name in ('DWB_RTL_TRX', 'DWB_RTL_TNDR_LI','DWB_RTL_SLS_RETRN_LINE_ITEM');
TABLE_NAME COMPRESS COMPRESS_FOR
------------------------------ -------- ------------
DWB_RTL_TRX ENABLED QUERY HIGH
DWB_RTL_TRX ENABLED QUERY HIGH
DWB_RTL_TRX ENABLED QUERY HIGH
DWB_RTL_TRX ENABLED QUERY HIGH
…
DWB_RTL_TNDR_LI ENABLED QUERY HIGH
DWB_RTL_TNDR_LI ENABLED QUERY HIGH
DWB_RTL_TNDR_LI ENABLED QUERY HIGH
DWB_RTL_TNDR_LI ENABLED QUERY HIGH
…
30 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
DWB_RTL_SLS_RETRN_LINE_ITEM ENABLED QUERY HIGH
DWB_RTL_SLS_RETRN_LINE_ITEM ENABLED QUERY HIGH
DWB_RTL_SLS_RETRN_LINE_ITEM ENABLED QUERY HIGH
DWB_RTL_SLS_RETRN_LINE_ITEM ENABLED QUERY HIGH
…
Once HCC-enabled tables and partitions have been identified, they can easily be uncompressed to
remove the HCC format using simple SQL commands.
If the tables are not partitioned tables, use the following SQL command to convert the data to regular,
noncompressed format:
alter table <table name> move nocompress;
Otherwise, if the HCC-enabled table contains partitions, the decompression operation has to be
performed on each partition in the table:
alter table <table name> move partition <partition name> nocompress;
For example:
As HCC data is converted to regular format, the data within the tables and their partitions on the master
clone database can then be accessed.
In planning for the decompression of HCC data, sufficient space should be allocated to the tablespaces
where the HCC-enabled tables and partitions reside to allow the decompression operations to complete
successfully. If there are multiple concurrent decompression SQL jobs being executed and there is
inadequate space in the target tablespace, it will result in Oracle error ORA-01652, related to "extending
temp segment." For example:
ORA-01652: unable to extend temp segment by 8192 in tablespace D28
ENABLING NETAPP STORAGE COMPRESSION ON MASTER CLONE VOLUMES
Upon completing the decompression process of HCC data in the master clone database, NetApp storage
compression can be enabled on the volumes of the master clone database to reduce storage
consumption. The compression settings and savings on the master clone database’s volumes are
inherited by the succeeding clone volumes when clone databases are generated from the master clone
database.
To enable storage compression on a volume, the following commands need to be run on the NetApp
storage system console:
sis on <path>
vol options <volume name> compression on
Turning on compression on an existing volume causes any new data to be compressed automatically as
it is written to the volume. However, current or existing data is not affected (that is, is not compressed). To
compress existing data, use the following command:
vol decompress start <volume name>
Figure 15 shows the savings from enabling storage compression on volumes of a database that has had
HCC data uncompressed.
31 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 15) Storage savings when applying compression to a database with HCC data uncompressed.
CREATING CLONE DATABASES FOR DEVELOPMENT AND TESTING FROM THE MASTER CLONE DATABASE
As the master clone database has had HCC data uncompressed for accessibility and storage
compression has been enabled on its volumes, it can be used to create more clone databases to meet
dev/test requirements.
SnapManager for Oracle is employed to allow the rapid cloning of databases. Figure 16 shows five clone
databases that were quickly created from the master clone database NET28DSC using SMO.
Many databases can be cloned and provisioned for development and testing without requiring significant
time and effort.
Figure 16) Multiple clone databases can be quickly created from a single backup.
32 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
Figure 17) Multiple clone databases are created for a test environment.
33 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
5 CONCLUSION
Customers utilizing Exadata database machines in production might consider leveraging non-Exadata
servers and NetApp storage to implement a supporting solution that can further protect the Exadata
production environment, provide additional backup and recovery options, and enable a cost-effective and
flexible dev/test environment.
Large capacity and cost-effective storage can be made available by employing NetApp storage as a
Exadata backup repository. Backup images can be replicated to remote storage system for added
protection. Storage efficiency technologies such as thin provisioning, compression, and deduplication can
be leveraged to achieve greater storage savings. An added benefit of offloading Exadata backups to
NetApp storage is to save on precious Exadata storage resources for more critical database
requirements.
Certain workloads that run on Exadata might be suited to having their dev/test environments deployed on
a non-Exadata platform. Deploying dev/test environments for Exadata databases on non-Exadata servers
and NetApp storage presents some clear benefits. Databases can be efficiently and rapidly cloned to
meet on-demand dev/test requirements. Space-efficient NetApp FlexClone technology enables
tremendous storage savings when maintaining multiple database clones.
Customers can also combine the implementation of a backup and recovery solution with the deployment
of a dev/test environment on the same infrastructure. Additional backup and recovery options are made
available while providing a flexible dev/test framework.
Overall, in supporting Exadata production environments, customers can benefit from increased flexibility,
manageability, and cost efficiency when deploying a backup solution and dev/test platform on non-
Exadata servers and NetApp storage.
6 REFERENCES
RMAN Performance Tuning Using Buffer Memory Parameters (article ID 1072545.1 at support.oracle.com)
Troubleshooting Backups External to the Database Machine (article ID 1275894.1 support.oracle.com)
34 Deploying Backup Solution and Dev/Test Platform for Oracle Exadata with NetApp
NetApp provides no representations or warranties regarding the accuracy, reliability or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.
© 2012 NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp, the NetApp logo, Go further, faster, Data ONTAP, FlexClone, RAID-DP, SnapManager, SnapMirror, and Snapshot are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. Oracle is a registered trademark of the Oracle Corporation. Linux is a registered trademark of Linus Torvalds. SQL Server is a registered trademark of Microsoft Corporation. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such. TR-4022-0112