deploying backup solution and dev/test platform for oracle...

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


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.


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.

http://www.oracle.com/


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


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


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.


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.


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





Restore Datafile(s) directly from



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


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






Back up Physical

Standby Database

with SMO


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


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


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


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


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.


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


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.


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

http://now.netapp.com/eservice/toolchest


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

http://docs.oracle.com/cd/E11882_01/server.112/e25608/toc.htm


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=''


*.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).


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).


3. Restore the datafile on the Exadata production database.

4. Recover the datafile.


5. As it is fully restored and recovered, the datafile can be brought online, or the database can be opened successfully.


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.


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


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.


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.


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.


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.


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


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_TNDR_LI 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.


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.


Figure 17) Multiple clone databases are created for a test environment.


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)


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

deploying backup solution and dev/test platform for oracle...

Documents