emc® backup, recovery, and migration for oracle … · white paper abstract this white ... data...

White Paper

Abstract

This white paper describes the key technical considerations and best practices to maximize EMC Data Domain® for faster, more efficient Oracle backup, recovery, and migration in an Exadata environment. Data Domain products with Oracle RMAN on Oracle Exadata provide complete visibility and control of backup, recovery, and cross-platform, business-data repurposing for the Oracle DBA. September, 2013

EMC® BACKUP, RECOVERY, AND MIGRATION FOR ORACLE EXADATA DATABASE MACHINE TRANSPARENT RMAN INTEGRATION, HIGH-SPEED INLINE DEDUPLICATION AND MIGRATION ONTO EMC OPEN ARCHITECTURE

2 EMC Backup, Recovery, and Migration for Oracle Exadata Database Machine

Copyright © 2013 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Oracle, Oracle Recovery Manager (RMAN), and Oracle Exadata Database Machine are registered trademarks or trademarks of Oracle, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number h12346


Table of Contents

Executive summary ........................................................................................... 4

Technology overview ......................................................................................... 5

Exadata backup and recovery with Data Domain ................................................... 7

Migration ....................................................................................................... 14

Scenario 1: Oracle Exadata backup, recovery, and physical migration to a similarly configured target ..................................................................................................... 15

Scenario 2: Logical HCC table migration for full or selective clone ................................. 18

Scenario 3: Data migration and load into SAP HANA .................................................... 22

Conclusion ..................................................................................................... 26


Executive summary Business-critical data environments, 24/7 global business-data solutions, all requiring 99.999% (five nines) availability, rely on Oracle databases to meet key business needs. Maintaining service-level agreements (SLAs) for Oracle databases supporting the full range of business services is essential to information viability and sustainability. However, constant data growth in the face of eroding backup and maintenance windows puts core business information on less than optimal footing.

Some IT organizations have turned to Oracle Exadata database machine environments to host valuable business data, yet the implementation of Oracle Exadata large database solutions to meet SLAs, the corresponding rapid data growth, and the limited legacy tape backup technology can restrict the frequency of backups and hinder attainment of recovery point objectives (RPOs).

Enter EMC® Data Domain® de-duplication storage systems. Data Domain capabilities enable cost-efficient, highly effective repurposing and migration of business-data assets sourced in an Oracle Exadata environment. This empowers agility, scalability, and improved cost of ownership while enabling Oracle database administrators (DBAs) to meet the demands of current and future business-data needs and operational service-level objectives.

EMC backup and recovery and replication technologies, and EMC Data Domain in particular, ensure successful data repurposing and migration that align closely with the practical needs and long-term objectives of business.

Audience

This white paper is intended for Oracle database administrators, systems engineers, partners, and members of the EMC and partner professional services community who are looking to realize optimally scalable, simple, cost-efficient fulfillment of business-data backup, recovery, and migration in Oracle Exadata environments.

Benefits

The following are the core benefits for Oracle Exadata environments discussed and demonstrated in this white paper:

Resilient backup and recovery SLA preservation of RPOs and RTOs

Scalable, simpler, more cost-efficient fulfillment of business-data protection

Oracle Exadata database administrator empowerment through transparent control of backup and recovery operations

Technique and methodology for migrating Hybrid Columnar Compressed tables for use on non-proprietary open architecture Oracle data environments

Technique and methodology for data loading from Oracle to SAP HANA


Technology overview

Solving for speed and simplicity

Oracle RMAN on Exadata backups write directly to the Data Domain system by means of a NFS mount, without the need of an additional application or interface.

A database administrator (DBA) supporting Oracle Exadata, logarithmic data growth, SLA, and recoverability challenges is enabled for success through EMC technology’s high speed, inline de-duplication features.

EMC Data Domain Boost ™ integration with Oracle RMAN on Oracle Exadata uniquely enables and empowers DBAs with familiar, faster, highly efficient and transparent control of backup and recovery operations without requiring an NFS mount.

Shifting off of proprietary Hybrid Columnar Compression becomes a matter of correct sizing and a logical migration using methods and techniques available to all Oracle DBAs, each with advantages that align to business operational criteria and the intended enterprise data target, Oracle or SAP HANA.

Oracle Exadata

The Oracle Exadata database machine consists of storage servers, database servers, and switches connected on an Infiniband fabric integrated to deliver OLTP, OLAP, and mixed application workloads as shown in Figure 1.

Figure 1 Oracle Exadata server components

The storage component runs specialized software (cell services) on Oracle proprietary hardware. This integrated storage layer is focused on reducing and relieving the classical bottleneck between storage and CPU without altering the Oracle Database kernel in any significant way. Central to this design is cell offload processing, which includes the following capabilities:


Data-file initialization

Hybrid Columnar Compression (HCC), data organized into compression units rather than traditional Oracle column orientation

Smart scan, which is the agent for HCC decompression and storage index activation and exploitation within the process PGA

Oracle HCC was introduced in 11g release 2 and is supported only on proprietary Oracle hardware, which can limit practical business data RTO to non-Oracle hardware, as well as complicate recovery and migration of business data to a heterogeneous storage-based data environment. EMC Data Domain technologies can ease challenges in rapidly provisioning test and development of Oracle databases.

HCC data must be uncompressed and converted to a more traditional format before it can be used on non-Oracle hardware. This design challenge underscores the value of high speed inline de-duplication backup and transparent recovery capabilities of Data Domain in Oracle Exadata environments through Oracle RMAN.

Exadata uses Oracle Automatic Storage Management (ASM) as the file system and volume manager in concert with this integrated Oracle storage software. As of Oracle 11gr2, Oracle ASM and Oracle Clusterware have been integrated into the Oracle Grid infrastructure, fully leveraging both cluster and storage services.

Oracle Real Application Clusters (RAC) enables use of multiple database instances on separate servers simultaneously, resulting in extended business-data capabilities. Oracle RAC in an Exadata environment provides increased high availability and a degree of horizontal scale through redundancy and faster failover at the database-tier level. An Oracle Exadata can be configured as multiple RACs to provide isolation between discrete data environments, allowing clusters to be administered independently, just as any ordinary set of clustered servers running Oracle Clusterware.

More frequently than not, however, a single Exadata is configured as a single RAC, with development, testing, and QA/preproduction staging, based in a mixture of storage and server technologies from different vendors. EMC Data Domain enables a fully leveraged, open-architecture approach to data recovery for all supported vendors, including Oracle Exadata.

EMC Data Domain Boost integration with Oracle Exadata

EMC Data Domain Boost (DD Boost) accelerates backup throughput while simplifying administration for the Oracle Exadata DBA. By enabling transparent control of Oracle backup and recovery while offloading the compression burden from RMAN, DD Boost empowers independent, DBA-controlled backup, recovery, and replication operations using the same familiar RMAN interface Oracle DBAs have relied on with great success.

Installation of the DD Boost plug-in consists of nothing more than unpacking and running the installation shell script on each node as the Oracle user. DD Boost


enables inline de-duplication and verification of data, distributing that burden and accelerating backup throughput as shown in Figure 2.

Figure 2 EMC DD Boost distributes de-duplication

This results in seamless integration with existing RMAN scripts without change or modification to the Exadata system. No special provisions, parameters, or adjustments to RMAN scripts already in place are required to maximize the benefits of EMC Data Domain technologies.

Note: A critical assumption is that those scripts already align to Oracle and EMC best practices.

An important operational differentiation between Data Domain and DD Boost is that DD Boost bypasses the need for an NFS share to be explicitly mounted to the Exadata.

Data Domain is built upon the fastest de-duplication storage controller in the industry, and implementing DD Boost on Oracle Exadata means more backup for less processing burden on Exadata hosts. Highly efficient, non-disruptive large database backup for data warehouse environments residing on Oracle Exadata are made possible through DD Boost and observation of Oracle and EMC best-practice recommendations, as shown in Table 1 on page 15.

Exadata backup and recovery with Data Domain

Optimizing Oracle RMAN on Exadata for backup, recovery, and migration

Oracle RMAN provides online backup and recovery of an Oracle database’s files and requires no special licensing or configuration on Exadata. RMAN backup data flows consists of read, copy, and write operations. Optional compression and encryption can be performed by RMAN, as shown in Figure 3, but is not recommended for DD Boost implementations, as it defeats the advantages of distributed de-duplication.


Using RMAN-side lossless compression introduces opportunity for performance bottlenecking while randomizing data patterns and defeating de-duplication. While RMAN can apply a binary compression algorithm (BZIP2) to a backup set, pre-compression needlessly increases resource burden on the target Oracle Exadata.

Figure 3 RMAN backup data flow: read, copy, and write

When optional RMAN encryption is enabled, a unique file is created that ensures that every file gets pushed across the backup network to the target media. Instead, consider Data Doman encryption for data-in-flight and data-at-rest with Data Domain Replicator (DD Replicator) software for secure encryption in the context of highly efficient database replication.

Data Domain encryption-at-rest is enabled by RSA BSAFE FIPS 140-2 compliant software with either 128-bit or Advanced Encryption Standard (AES) algorithms. Block cipher settings may be either Cipher Block Chaining (CBC) or Galois Counter Mode (GCM). Data-in-flight is supported by means of ADH-AE256-SHA cipher suite in the context of replication connections using standard Secure Socket Layer (SSL) protocol version 3. DD Replicator ensures a comprehensive and secure, network efficient DR replication discipline as shown in Figure 4.


Figure 4 Effective encryption with DD Replicator

For granular control and least risk of recovery, RMAN metadata should be directed to a recovery catalog database within Oracle, as opposed to allowing it to default to the database control file.

One effective option is to maintain that recovery catalog within the Oracle Enterprise Manager (OEM) repository, a database residing on a platform other than the Exadata targeted for backup, as shown in Figure 5. The cataloged metadata can be browsed during restoration from either RMAN’s command line interface (CLI) or the OEM GUI.

In an image-based physical migration scenario between and Exadata and a similarly configured open architecture target, keeping the recovery catalog on a target host isolates that catalog from one supporting daily regular operations.

RMAN leverages block change tracking (BCT) to avoid reading each individual data file. This effective capability translates to gains in incremental backup reads in large databases on Oracle Exadata, especially those relying on smallfile tablespaces. RMAN need only read the tracking file for unique data segments to copy to the targeted Data Domain appliance.

DD Boost is fully compatible with Oracle RMAN BCT. Enabling BCT on an Exadata with DD Boost configured on each node in the database cluster results in only those unique segments copied out without having to scan the file system, which distributes deduplication.


Figure 5 RMAN client-level view with a separate recovery catalog

Exadata load-balancing considerations for RMAN and DD Boost

Creating a dedicated service as a connection target for RMAN simplifies debugging, isolates resources, and allows the RMAN client to automatically load balance across all nodes included in the service definition.

Enter the following to define a dedicated service: Srvctl add service –d databasename –s servicename –r node1,node2, node3

Enter the following to connect by means of the RMAN to the dedicated service: oracle@myinstance>$ rman target user/pass@servicename

Figure 6 demonstrates one technique to confirm that the service is running.


Figure 6 Active dedicated service profile for RMAN client

It is also recommended to specify a 10 Gb backup/data guard network on the Exadata to ensure maximum network availability at all times for standard Exadata client connections. This can be accomplished through the Exadata onecommand setup utility and the coordination among network and database administrators.

Both standard Data Doman and the EMC DD Boost plug-in on Exadata negotiate with the target Data Domain system for an interface and distribute the load based on the number of active jobs on a given interface. This application-awareness capability extends RMAN Exadata-side resource load balancing, resulting in dynamic distribution of backup and restore activity on multiple ports of the Data Domain system. A CLI check on active connections for DD Boost is shown in Figure 7.

In addition, DD Boost provides automatic link failover by transparently moving jobs on failed links to healthy links. This fault tolerance results in consistent backup throughput speeds.

Figure 7 DD Boost application awareness connectivity on a Data Domain system

NFS mounts, DD Boost, speed and simplicity

Standard Data Domain software works through NFS. An NFS export with appropriate security definitions and parameters is first created on a Data Domain system. Each Exadata RAC node fully qualified domain name is then added to that NFS export, as show in Figure 8.

Figure 8 Exadata client assignment to Data Domain NFS export


Setup on the Exadata consists of simply updating /etc/fstab and /etc/mtab for the correct mount specifics, as defined in EMC Data Domain product documentation for each RAC node in the cluster.

The command to mount all entries in /etc/fstab on Oracle Linux is: oracle@myinstance>$ mount -a

Figure 9 shows an example of both a DD 990 mounted to an X3-2 Oracle Exadata for standard backup operations or for a physical migration to a similarly configured data target. For correct sizing of Data Domain system appliances to any Oracle data environment, including Oracle Exadata machines, refer to EMC Data Domain controller performance and capacity sizing at support.emc.com.

Figure 9 Example of both a DD 690 and DD 990 mounted on an Exadata

The result of this configuration procedure underscores the simplicity and seamlessness of integration with RMAN. A bash RMAN script on an Exadata RAC node can effectively reference a Data Domain 990 as NFS mounted disk. A basic but highly fast and effective full backup script is shown in Figure 10. Note the connection to the dedicated service for RMAN automated load balancing across all Exadata RAC nodes using standard Data Domain software capabilities.


Figure 10 Simple, fast and effective full backup using a DD 990 as target media

Configuration profile summary for Data Domain and DD Boost on Exadata

Table 1 summarizes the component configuration options reviewed for this solution.


Component Option Configuration

RMAN Parallelism Enable

Channels 8 per node/instance thread of type disk

BCT Enable for unique segment copy

Recovery catalog Maintain and consider high availability of the catalog itself

Compression Disable because pre-compression defeats distributed deduplication advantages

Encryption Disable because it makes unique files defeating deduplication; instead, consider Data Domain encryption of data-at-rest or data-in-flight

Exadata DD Boost installation

One plug-in per RAC node on Exadata

Standard Data Domain backup

Requires an NFS share be mounted to the Data Domain appliance on each RAC node

Backup/Data Guard network

Specify with Exadata onecommand utility for 10 Gb

Dedicated service for all backup/restore operations

Create a service and connect by means of RMAN for automatic load balancing across nodes during backup ops:

srvctl add service –d mydb –s

backup_srv –r node1,node2,node3,

node4

Table 1 RMAN and Exadata configuration profile

Migration Migration can be divided into physical or logical migration and is driven by business-data volume, need for repetition, time, operational investment, and migration outage impacts on SLAs.

Table 2 illustrates common, proven approaches to migration from Exadata to EMC open architecture data environments. This list of heterogeneous migration options is growing as the demand for flexibility and the efficient reuse of business data grows.

As a general rule in migration scenarios, the less tolerance for migration data outage, the greater the requirement for network capacity, throughput, and simplicity and reliability of technique.


Migration category

Toolset Heterogeneous applications and considerations

Physical EMC Data Domain Disaster recovery and migration clone for targets with same endian formats and DB versions EMC replication

manager

Oracle transportable tablespace

Tablespace level migration clone across endian formats, platforms, and DB versions where downtime is acceptable

Logical Oracle Data Pump Selective or full-migration clones across platforms where read-only data, temp space preplanning, and minimal downtime/data outage is involved; does support uncompressed export of data based on license

Oracle to Oracle CTAS/IAS by means of database link

Selective or full-migration clones through high-volume, high-speed copy as direct path inserts or CTAS, allowing for on the fly HCC to standard compression transformation and access to data

Multiple data unload methods

See Scenario 3, Table 4 for options related to SAP HANA load prep

Table 2 Heterogeneous migration options

Scenario 1: Oracle Exadata backup, recovery, and physical migration to a similarly configured target

Introduction

This section discusses the method for backup and recovery based physical migration of Oracle Exadata databases with standard Data Domain to a similarly configured Oracle open architecture data environment using the same DB software version on OEL and EMC storage. Thorough planning must be applied for uncompressed HCC table storage requirements on source and on target, as shown in Figure 11.


Figure 11 Physical migration and DR with EMC Data Domain to EMC open architecture

Procedure

RMAN backup, recovery, and migration with Data Domain consists of the following high level steps:

Planning for storage consumption of uncompressed tables. During testing, a full mix of all HCC compression types was used.

Testing HCC table uncompression at source through a simple alter table MYTABLE nocompress; statement.

Using a basic RMAN script to create a full backup image of the Exadata database. Collecting backup performance metrics on the DD 990 system through NFS mount

on each RAC node. Standard normal Oracle database recovery operations to start, mount, open, and

verify restored data content.

Monitoring and metrics

Ensuring Oracle Direct NFS (DNFS) is enabled and active is a straightforward procedure at the OS level, or alternately, through the alert log. Figure 12 shows application of grep for database writer activity, followed up with an lsof to confirm that only TCP/IP sockets are opened towards NFS server.


Figure 12 Using grep and lsof to confirm active DNFS

Oracle Exadata product documentation provides guidance on enabling DNFS if you observe action against data files that would be an indication that DNFS is not enabled.

Monitoring RMAN throughput on Exadata with Data Domain can be done through the same familiar methods at the disposal of DBAs. Oracle Enterprise Manager 12c Cloud edition provides graphic, interactive, target-driven assessment down through to backup jobs.

The GV$BACKUP_ASYNC_IO and GV$SESSION_LONGOPs views can provided specific, timely, granular insight as well into effective bytes-per-second and any potential Exadata-side throughput bottlenecks. The EMC Data Domain System Manager and CLI provide insight into performance statistics in the context of network, DD system CPU, file system, and disk, as shown in Figure 13.


Figure 13 Performance stats for a Data Domain 990 through System Manager

Summary of Scenario 1

EMC Data Domain technologies enable fast, flexible, and simplified backup, recovery, and physical migration through integration with Oracle RMAN on Exadata to similarly configured data targets.

The following benefits are achieved by employing EMC Data Domain technologies for backup, recovery, and physical migration:

Data Domain software preserves HCC and all Oracle data from backup through to recovery by RMAN on Exadata.

Physical migration must be to similarly configured data environments, such as Exadata to a matching EMC/Cisco data appliance.

Thorough planning and testing for HCC compressed tables must be factored in any migration effort.

The migration method selection must be driven by the criteria of migration outage time allowed, heterogeneous platform-support capabilities, and the allowable time and operational investment.

Scenario 2: Logical HCC table migration for full or selective clone

Introduction

This section discusses one example of logical migration resulting in high volume, very fast uncompressing of HCC tables on the fly. Method and technique reveal a simple, quick logical migration of an Oracle Exadata to an Oracle data environment on EMC storage. Applications include full migration as well as deployment to less costly development, testing, QA and pre- and post-production data staging areas.


The following core assumptions are made for a well-executed logical migration of business data on Exadata:

Exploration, confirmation, and planning for network impacts

Factoring for migration outage allowances, operational investment, and time to use requirements

Data security and control considerations

Thorough testing and adjustment, including practicing the migration prior to performing it

When selectively extracting and copying terabytes of data between databases, with a desire to transform on the fly from HCC table compression to uncompressed tables and to immediately use that data, Oracle database links are an effective migration technique. In contrast to an Oracle Data Pump logical migration, a database link enables reading data once with immediate transfer over the network as direct path inserts. Figure 14 illustrates the relative simplicity with the core assumption that adequate network capacity is available.

Figure 14 Database link CTAS/IAS logical migration


Sizing, planning, and performance considerations for migrating HCC tables

Given that HCC-enabled tables are dependent on Oracle proprietary hardware, care and thorough planning must be given to ensure there is sufficient space in the targeted tablespaces for uncompressed data. It is also an excellent opportunity to realize full performance benefits of the business data on the EMC target.

In comparative testing across similar table structures deployed in different smallfile tablespaces each with a different compression method, findings indicate that OLTP and DW compression results in similar amounts of used space, albeit with slightly different performance profiles. Converting those tables to uncompressed data typically on average required 17 to 35 percent more storage per table.

Having enough disk space is essential, as well as is placing the correct business data on the highest performing, most cost-efficient storage tier. Table 3 relates HCC compression types to relative space consumption and storage-tier assignment considerations.

Table 3 Uncompressed storage performance factoring

Procedure

The following outlines the steps for the logical migration of business data on Exadata to an open architecture EMC/Cisco target:

Planning for storage consumption of uncompressed tables. During testing, a full mix of all HCC compression types was used.

Creation of a database link from the target data environment back to the Exadata. Testing of the database link. Scripted or single-query Create Table As (CTAS) or Insert Append (IAS) SQL pulling

HCC table data from the Exadata to the target EMC data environment. (DDL operations against remote databases are not allowed.)

Gathering speed and storage-consumption metrics to validate the recovered and migrated data environment.


Monitoring and metrics

Oracle database links are proven to accommodate huge data-transfer requirements within a very small downtime window. There was no additional time identified for copying through a database link from an Exadata to the EMC target for HCC tables in comparison to uncompressed tables.

Figure 15 shows the uncompressed tables on the EMC target resulting from CTAS over database link to the source Exadata.

Figure 15 Uncompressed HCC tables on the EMC target

There was also no additional time identified between the two different tnsnames.ora service definition approaches used on the EMC target to describe the Exadata. Those tnsnames definition options are shown in Figure 16. The chief advantage of the first definition is simplified maintenance of a scan over the older, explicit virtual IP (VIP).


Figure 16 Two ways to reference an Exadata instance in tnsnames.ora

To correctly factor for data transfer speed, proactively benchmark by using a select statement against a local table on the Exadata source and then having that same select statement issued remotely from the target data environment. This provides a rough relative data latency indication. Logical migration data throughput is clearly limited by network equipment and configuration, and it is also impacted by TCP protocol tuning. A thorough benchmark of the round-trip time (RTT) between source and target databases is an essential part of migration planning.


The following outlines the results of logical migration from Exadata to an EMC open architecture target:

Highly efficient high-volume on–the-fly conversion of HCC tables to standard tables that can be assigned to storage tiering

Minimal migration outage based on network throughput Efficient repurposing of business data for development, testing, and migration to

heterogeneous storage environments DBA clear visibility and empowerment in all phases of logical migration

Scenario 3: Data migration and load into SAP HANA

Introduction

The primary application for reprovisioning business data residing on an Oracle Exadata database machine into SAP HANA on EMC storage infrastructure is migration from Exadata to a first-time SAP HANA implementation, where there is no preexisting SAP architecture.


Prepping and unloading Oracle Exadata databases

Data transport using .csv files is a proven approach for SAP HANA environments that have no other SAP infrastructure to draw on. Table 3 describes the primary Oracle-side data unload options.

Oracle data tool/technique

Pro Con

Oracle SQLPlus spool to .csv with formatted, delimited select statement

Fast, scriptable at the OS level against the Oracle data dictionary

Cleanup of data types, date format, and so on prior to spool out

PL/SQL utl file to generate .csv through Oracle PL/SQL interface

Provides programmatic repeatability that can be parameter driven

Less efficient throughput and requires PL/SQL skills and code maintenance

PRO C*, perl, C, C#, and so on dataset and file handling

Fast and highly flexible Requires higher coding skill set and code maintenance

Table 4 Oracle tools and techniques for data unload

In cases where there is an existing SAP landscape, data transport tool and technique options increase to include proven approaches such as SAP landscape transform, Sybase SRS, and Sybase ESP, all of which require differing combinations of licenses and appropriate skill sets. In any event, converting from HCC tables to standard tables is a key initial step.

The following are the best practices for planning a migration from Exadata to SAP HANA:

Correct sizing of the right architecture Converting from HCC to standard tables and optimizing the inbound data model

prior to initial load Tuning small subsets of actual target data prior to full initial load for best

efficiency in loading to scale

Correctly sizing the target environment and deploying to an SAP-approved infrastructure for HANA are the essential first steps, however, providing the complete details those steps falls outside the scope of this paper. Based on SAP HANA t-shirt sizing, where 128GB is an XS, a medium-sized appliance would be 4 CPUs/512 GB RAM. Log storage should be sized to match RAM in this SUSE Linux Enterprise Server (SLES) 11 solution, where the EMC VNX®5300 is a SAP-certified storage target.

The following key rules must be observed for optimizing the inbound data model:


Convert from HCC to standard tables, then make those tables narrow Factor for workload deployment; three to five partitions are good for insert speed

per node, which appears extensible on the number of active nodes in configuration

An in-memory database compresses everywhere, both memory and disk, so avoid VARCHARs if they are not essential

Migrating Oracle Exadata-generated data files into SAP HANA

Tune small subsets for data load prior to full-on data loading . Even though SAP HANA allows massively parallel simultaneous loading to a maximum of 80 cores, data-load speed is the central data transport challenge in this migration scenario.

According to SAP, there are three basic methods to loading Oracle-generated .csv into HANA:

SQL import from command syntax Control file load Load through the File Import Wizard

Figure 17 shows an example of an import of an Exadata-generated .csv file against an existing table column list. A HANA control file looks familiar to the Exadata Oracle DBA because of similarities in syntax. While it is tempting to assume functional similarities between Oracle batch load and the HANA bulk loader, there is one significant difference: Oracle bulk load brings no referential integrity/acidity, while HANA bulk loads are report ready at load.

Figure 17 SAP HANA Studio SQL console import from example

The File Import Wizard within SAP HANA Studio simplifies data migration even further by allowing real-time mapping and creation of target HANA schema based on the


inbound Exadata .csv file. This can be a time saver in transferring the essential table structure without Oracle-style keys and indexes, as shown in Figure 18.

Figure 18 Simplified schema creation through the File Import Wizard

Procedure

The following steps are necessary to migrate from Exadata to SAP HANA on EMC infrastructure:

Making the standardized tables narrow Performing a rapid spool and tar of .csv files by means of SQLPlus Using SAP HANA Studio to quickly create target tables based on the transported

data layout and tuning the load Loading the full .csv Gathering speed, storage consumption metrics within SAP HANA to validate the

recovered and migrated Exadata data environment


The following are the results of data migration of business data residing on Exadata into SAP HANA:

Rapid offload of business data with minimal impact to a production Exadata environment

A repeatable, efficient migration of customer business data to SAP HANA Increased levels of DBA visibility and empowerment in all phases of migration


Conclusion EMC was first to deliver complete, transparent control of Oracle backup and disaster recovery to Oracle database administrators, and the same is true for Oracle Exadata database machines. The advanced integration between DD Boost and Oracle RMAN enable greater speed, simplicity, and flexibility than might be possible without EMC Data Domain technologies.

EMC Data Domain capabilities enable cost-efficient, highly effective repurposing and migration of business-data assets sourced in Exadata. This empowers agility, scalability, and improves cost of ownership, while enabling Oracle DBAs to meet the demands of current and future business-data needs and operational service-level objectives.

Migration and data repurposing from Oracle Exadata to EMC open architecture data environments can be accomplished easily with planning and awareness of technical options in the context of business-data priorities and service-level objectives.

emc® backup, recovery, and migration for oracle … · white paper abstract this white ... data...

Documents