Symmetrix Integration w Oracle v52 - Srg

Copyright © 2009 EMC Corporation. Do not Copy - All Rights Reserved.

Symmetrix Integration with Oracle - 1

© 2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle Symmetrix Integration with Oracle

Welcome to Symmetrix Integration with Oracle.

Copyright © 2009 EMC Corporation. All rights reserved.

These materials may not be copied without EMC's written consent. 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.

EMC² , EMC, EMC ControlCenter, AdvantEdge, AlphaStor, ApplicationXtender, Avamar, Captiva, Catalog Solution, Celerra, Centera, CentraStar, ClaimPack, ClaimsEditor, ClaimsEditor, Professional, CLARalert, CLARiiON, ClientPak, CodeLink, Connectrix, Co-StandbyServer, Dantz, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, EmailXaminer, EmailXtender, EmailXtract, enVision, eRoom, Event Explorer, FLARE, FormWare, HighRoad, InputAccel,InputAccel Express, Invista, ISIS, Max Retriever, Navisphere, NetWorker, nLayers, OpenScale, PixTools, Powerlink, PowerPath, Rainfinity, RepliStor, ResourcePak, Retrospect, RSA, RSA Secured, RSA Security, SecurID, SecurWorld, Smarts, SnapShotServer, SnapView/IP, SRDF, Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives, xPression, xPresso, Xtender, Xtender Solutions; and EMC OnCourse, EMC Proven, EMC Snap, EMC Storage Administrator, Acartus, Access Logix, ArchiveXtender, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, C-Clip, Celerra Replicator, CLARevent, Codebook Correlation Technology, Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Digital Mailroom, Direct Matrix, EDM, E-Lab, eInput, Enginuity, FarPoint, FirstPass, Fortress, Global File Virtualization, Graphic Visualization, InfoMover, Infoscape, MediaStor, MirrorView, Mozy, MozyEnterprise, MozyHome, MozyPro, NetWin, OnAlert, PowerSnap, QuickScan, RepliCare, SafeLine, SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure, SnapView, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraFlex, UltraPoint, UltraScale, Viewlets, VisualSRM are trademarks of EMC Corporation.

All other trademarks used herein are the property of their respective owners.



© 2009 EMC Corporation. All rights reserved. Symmetrix Integration with Oracle - 2

Course ObjectivesUpon completion of this course, you will be able to:List a number of IT challenges and EMC solutions that best meet a set of business objectives Describe an example of an EMC Consolidated Solution for an Oracle 11g databaseIdentify a list of EMC replication solutions Describe the planning and documentation process to set up an Oracle database environmentDescribe an Oracle OFA compliant environmentDescribe the advantage of spreading Oracle Meta Volumes across multiple back-end “Disk Directors”List RAID configurations and their performance impact within an Oracle database environment Describe an Oracle ASM (Automated Storage Management) environment and its integration with EMC’s TimeFinder applicationDescribe an Oracle RAC (Real Application Clusters) and its integration with a DMX environmentDescribe Oracle’s Flashback Technology and its integration with EMC’s TimeFinder applicationDescribe an Oracle offline and online backup scenario and its integration with EMC’s TimeFinder applicationDescribe TimeFinder clone and snap applications and their integration with an Oracle 11g applicationDescribe EMC’s SRDF/S application and how it best meets an “instant” RPO and a RTO of minutesDescribe EMC SRDF/A replication solution for an Oracle database applicationDescribe EMC’s PowerPath and ECA Consistent Split technology Describe EMC’s Replication Manager application within an Oracle 11g environment

The objectives for this course are shown here. Please take a moment to read them.




Information Technologies / Business Challenges

Upon completion of this lesson, you will be able to:

Describe both the RPO and RTO business requirements and their impact on an Oracle application

List a number of IT challenges and EMC solutions that best meet a set of business objectives

Describe IT configurations for efficient management utilization of storage

Identify the benefits of a well-documented Oracle environment

The objectives for this lesson are shown here. Please take a moment to review them.




Business Challenges

Server and Storage Usage

Underutilized storage High storage costs due to per-server acquisition model

… Business challenges create IT challenges

AvailabilityPoor architecture and inefficient processesInformation access is criticalInformation protection is costly

PerformanceImpact on business processesLost productivity and revenue opportunitiesCustomer satisfaction tied to performance

GrowthComplexity and cost growth directly with capacityNot flexible; difficult to change

IT Challenges

Companies running on distributed environments are often faced with a number of business challenges. Server and storage usage, growth, and application availability are just some of the many challenges IT originations face every day.




IT Challenges

EMC has solutions to meet both business and IT challenges

Complex Technology ChoicesDesigning and deploying comprehensive solutions

Upgrades and MigrationsDeveloping comprehensive project plansEnsuring on-time completionAchieving seamlesstransition

PerformanceMeeting service levelsAdding more usersAdding more applicationsFinding and resolving bottlenecks

IT Resources and Budget

Increasing IT responsibilitiesManaging limited budget Expanding skill sets

OperationsPreparing for data and information growthReducing availability threatsEnsuring scalability of IT service delivery

EMC Solutions to help meet

IT Challenges

Many Oracle database applications are deployed in highly distributed environments. To maintain service levels, many companies have been forced to over purchase so-called point solutions in order to handle peak work loads. Distributed resources are very difficult to maintain, resulting in poor usage of server and storage resources for their business.

On top of all of this are database “Recovery Point” and “Recovery Time” business objectives that must be adhered to.




Recovery Point Objective (RPO) Recovery Time Objective (RTO)

Business Needs Drive the Technology Choice

RPO

RTO

A Recovery Point Objective (RPO) is a business objective that identifies an acceptable point in time for a database to be recovered. A Recovery Time Objective (RTO) is a business objective that identifies an acceptable time to bring the database back on line.

Individual customer business needs drive the technology chosen to meet specific recovery point objectives, as well as a specific recovery time objectives.




Before: Every Server a Management Headache

Unacceptable amount of planned downtime for operations such as increasing capacity and backupLimited flexibility, costly to scale, additional server overhead

Limited growth and scalability

Dispersed management is difficult and costlyMultiple Oracle Database applications scattered throughout the enterprise

Inadequate protection; excessive unplanned downtimeLow fault toleranceTime-consuming backup/restoreIndividual backups on every server

Low resource utilizationRemote replication and disaster recovery are too time-consuming, complex, and costly

Islands of storage inaccessible by other servers and applications

IssuesCharacteristics

Customapplications SAP

Webapplications

OracleE-Business

Suite JD EdwardsPeopleSoftWAN

BackupBackup

This is a typical Oracle database management environment. Here we see many servers using internal disks which create islands of data. The problem is that vast amounts of wasted space are tied to each server.

Local management is difficult to control because the storage is not pooled and it has a low rate of utilization. If more storage is needed, the systems must be taken offline. In some cases, new servers must be added, managed, and synchronized just to allow for more storage.




After: Efficient Utilization, Recovery, and Management

Improved recovery point and recovery time for disaster recoveryCentralized replication

Reduced planned downtimeImproved scalability

Reduced management cost, increased flexibilityServer consolidation

Increased information availability, reduced downtimeRobust fault-tolerant storage

Improved mean time to recovery Consolidated backup and restore

Improved storage utilization; reduced acquisition costsStorage consolidation on EMC

BenefitsFeatures

Custom applications

SAP

Web applications

Oracle E-Business SuiteJD EdwardsPeopleSoft

WAN

Backup

EMC StorageEMC Storage

Backup

This is an example of an EMC consolidation solution for an Oracle 11g database environment. In this solution, the Oracle database applications are deployed on EMC storage arrays. This improves availability and usage for the various database applications.

Consolidating the databases on EMC storage arrays (or NAS – Network Attached Storage environments), makes them easer to replicate, reconfigure, and scale. Centralized management and backup will result in lower IT (Information Technology) costs.




Oracle Environment – Integration / Layout Project

Where do the…Data ControlRedo andArchive files reside?

Documentation

Document the following:Disk GroupsVolume Groups Devices GroupsASM Groups Clone DevicesSnap DeviceStandard and BCV DevicesRDF Configurations

Planning and Documenting the Oracle Environment

IP Host AddressHost Names Root logon passwordsOracle DBA Accounts info Oracle User Accounts info

A critical component when setting up any Oracle environment is to plan and document everything. Knowing where the Oracle files are will enable both the Storage Administrator (SA) and the Database Administrator (DBA) to administer their Oracle environment efficiently.

This includes mapping all active Oracle storage devices that belong to the operating systems, (Disk Groups, and Volume Groups) the Oracle ASM (Automated Storage Management) environments, as well as the all the EMC storage configurations which include clone, snap, mirror, and all RDF configurations.




Planning and Documenting the Oracle Environment (Cont)

ESX 4.0 (Source Host) ESX 4.0 (Target Host)

D

R

A

F

D

R

A

F

/vol1/db1/vol2/db2

/vol3/db3

/vol4/Rd1/vol5/Rd2

/vol6/Ar1

/vol7/Fl1

/vol1/db1/vol2/db2

/vol3/db3

/vol4/Rd1/vol5/Rd2

/vol6/Ar1

/vol7/Fl1

Source Mount Points

Target Mount Points

AA BB

Oracle 11g Binaries Oracle 11g Binaries

Oracle Data (A) Oracle Data (C)Master (R1) Controlling Oracle 11g Host

Target (R2) Backup Mount Host

RDF Data

RDF Arch

RDF Flashback

D

R

A

F

TimeFinder/Clone Data Device Groups

RDF Redo

EMC

ERM 5.2 Server

RM Sym Devices

CC

This diagram depicts an Oracle database configuration. This documentation identifies associated mount points. Notice that the Data, Redo, Archive files have their own mount points.

The Data files themselves can be spread out over many devices and or mount points. How an Oracle database is set up depends on many factors. The key is to document your environment and to keep all documentation up-to-date as the Oracle database environment will change over time.

In larger organizations, the Storage Administrators, DBA (Database Administrators) and the System Administrators may not be the same person. Mapping out an Oracle environment will give all of those responsible a clearer view, in the event any maintenance activity must be performed.

Best practice when documenting any Oracle application would be to include a diagram of your environment, especially with a large Oracle application where many folks are tasked to support the applications. This slide is an example of a diagram that would include the Symmetrix device IDs and where all the Oracle objects reside. Host IDs and mount points are clearly identified and will help System, Storage, and Database personnel understand how the Oracle applications are set up in support of any given business environment.




Oracle Consideration in a DMX / V-Max Environment

Upon completion of this lesson, you will be able to:Describe the benefit of an OFA compliant Oracle environment Identify the components of a Direct (DMX) vs. Virtual (V-Max) storage environment, supporting an Oracle RDBMS applicationDescribe the benefits of auto-provisioning within an Oracle environmentIdentify which database workloads are a best fit for Flash Drive technology Describe the impact “Device Migration” would have within an Oracle database environment Describe the impact “Virtual LUN migration” would have within an Oracle database environment

The objectives for this lesson are shown here. Please take a moment to read them.




OFA: Oracle’s Optimal Flexible ArchitectureOracle OFA UNIX / Linux Directory structure

Minimum: an OFA database requires four UNIX/Linux mount points – /u01 to include the Oracle software – /u02 - /u04 contain the database files

From /u01: create an app (application directory) – /u01/app - /oracle– /accounting– /purchasing

From /u01/oracle/product/11.x.x Version Oracle 11g

The directory path to install Oracle components (example for 11gRelease 1 Version 11.10)– C:\app\oracle\product\11.1.0\db_n

When setting up an Oracle 11g database environment, both the DBA and EMC’s technical architect should incorporate Oracle’s OFA (Oracle Flexible Architecture) standards.

Using Oracle’s OFA standards enables the set-up of multiple Oracle versions to coexist on the same host. Maintaining multiple Oracle versions simultaneously enables users to migrate over time from one version to a newer version. An example would be migrating from an Oracle 10g to an 11g platform.

OFA is a set of Oracle recommendations for naming files, folders, mount points, data directories, and software directories, when installing and implementing an Oracle database configuration. The OFA recommendation set is meant to help organize administrative tasks and control large database environments.




RF

A 01

B 01

C 01

D 01

Global Cache

Symm Device Meta Vol

0 1 2 3

DMX Disk ID 1A01

PortDir 16

A01

B01

C01

D01 Dir

8HA

Global Cache

Global Cache

Global Cache

Dir 1

A01

B01

C01

D01

A 01

B 01

C 01

D 01

A 01

B 01

C 01

D 01

A 01

B 01

C 01

D 01

Dir7

HA

Dir16HA

Dir15HA

Dir2

HA

Dir1

HA( Direct Matrix )

Processor / Instance

Target Array

RF

RF

Symmetrix DMX “Direct” System Overview

It’s important to understand the logical layout of a DMX. With this understanding and the use of the “symdisk list”, “sympd list”, and “symdev show” commands, the storage administrator along with the DBA can map out an Oracle database environment, that is, evenly balance out over the back end. There are a number of basic “Best Practices” that we will discuss throughout this program, but it must be understood that not all best practices will fit every situation. It depends on the application, the amount of hardware, the number of users, and business rules that also play into any configuration. Whatever the situation, knowing the DMX and the V-Max architecture and its operation is a factor in any Oracle layout.

This slide represents an overview of the DMX architecture. Once the storage admin and the DBA understand the devices in their Oracle environment, the next step is to document the configuration. What devices contain or hold these Oracle objects?




HA DAA 0

1B 0

1C 0

1D 0

1

EFGH

Director 10Global Cache

( Virtual Matrix )Port

010101

01

HA DAA 0

1B 0

1C 0

1D 0

1

EFGH

Director 9Global Cache0

10101

01

HA DAA 0

1B 0

1C 0

1D 0

1

EFGH


010101

01

HA DAA 0

1B 0

1C 0

1D 0

1

EFGH


0 1 2 3

V-Max Disk ID 7A01

Symm Device Meta Vol

010101

01

Processor / Instance

Target Array

RFRF

RF

Symmetrix V-Max “Virtual” System Overview

With the V-Max, director ports A thru D are back-end ports where E thru H are reserved for front-end host and RF connectivity. Oracle file placement considerations are the same regardless of array type (DMX or V-Max).

Symmetrix global cache is available across all directors and should not be confused with “Host Caching” which is what Oracle 10g/11g uses for database performance. All Symmetrix storage devices can be accessed (configured) across every director thus the term “Virtual”.




Metavolume Spread across Multiple Back-end Symmetrix Disk Directors

Back End Disk Directors

Front End System Adaptor DMX

Array

Hyper VolumesSplit into 4 – 4.2GB each

Metavolume

Cache 0079

007A

007B

0069

006A

006B

0059

005A

005B

When reviewing a Symmetrix device configuration layout, note that all volumes are in fact distributed evenly across the back-end directors. Understanding this configuration when setting up an Oracle application can be used to further enhance performance.

The Storage Administrator (SA) and the Database Administrator (DBA) can work together to place all database objects onto the proper devices, thereby achieving acceptable performance at the application level.

Careful consideration should be given when creating your file systems and volume groups. With a Symmetrix/Oracle configuration laid out across multiple back-end directors, combined with a file system that takes into consideration file usage, negative performance impact will be minimal.




Management Abstraction Enables Ease, Speed, and Automation

Easy, quick, and automated storage provisioning

– Auto-provisioning groups combine tasks by drive, port, and initiator to reduce time and complexity by 95 percent

Space-efficient, easy-to-manage capacity– Virtual provisioning with new automation to

easily grow and reclaim storage

Nondisruptive mobility across storage tiers– Virtual LUN transparently moves information

to the right tiers and RAID types at the right time

Optimize throughput for virtualized environments

– EMC PowerPath/VE provides multipathing and load balancing for both physical and virtualized environments

As we migrate from the DMX architecture to the V-MAX platform, new functionality becomes available enabling ease, speed, and automation.

New management capabilities include Auto-Provisioning Groups, new Virtual Provisioning features, Virtual LUN technology, PowerPath/VE, which supports virtualized environments, and automated discovery and reporting via ControlCenter.

The next slides introduce these new features with an introduction of Enginuity 5874 and Solutions Enabler 7.0. These new features, when implemented, will have an impact when configuring any new Oracle database application.




Auto-Provisioning

Auto-provisioning groups– Symmetrix V-Max Series

with Enginuity 5874– Solutions Enabler 7.0 and

Symmetrix Management Console 7.0

– Open Systems only– New mapping and masking

feature– Creation of Independent

Groups

(1) Initiator Group

(2) Port Group

(3) Storage Group– Masking View

• Contains individual Initiator, Port, and Storage Groups

• Reduces the complexity of managing multiple groups

Enginuity 5874: Auto-provisioning groups

Easier to manage

Fewer actions to commit

Adds simplicity

Previously: DMX

Auto-provisioning Groups is a new feature introduced with the new Symmetrix V-Max Series with Enginuity 5874 and is supported with EMC Solutions Enabler 7.0 (SE) and Symmetrix Management Console (SMC). This new feature is an easier way to manage mapping and masking tasks, has fewer actions to execute, and adds simplicity to mapping and masking Symmetrix logical volumes.

In today’s environment, applications such as Oracle can reside on virtualized hosts and clustered servers requiring multiple paths to Symmetrix logical volumes. With a DMX, the mapping and masking operations require at least one operation per front-end adapter (FA) port, Initiator (HBA), and Symmetrix logical volume combination. With hundreds of servers, all with multiple paths, this can be a time consuming procedure to carry out and a challenging task to manage.

With the Symmetrix V-Max Series array, all of the individual pieces associated with mapping and masking can be collected into independent groups and managed by one singular association.

1. An Initiator Group will contain host initiators; 2. A Port Group will contain the front-end ports; and 3. A Storage Group will hold Symmetrix logical device names.

These three independent groups can be associated into a Masking View. The Masking View provides the ease of management, reduces the number of actions to commit, and provides ease of use. This functionality enables both the DBA and the Storage Administrator to quickly provision Oracle Virtual environments. The roles of both the DBA and the Storage Administrator are coming together with respect to configuring and implementing Oracle database solutions.




V-Max Auto-ProvisioningSymmetrix V-Max System

Host-A

Host-B

Initiator Group

Masking View

PortGroup

Storage Group

Fabric-AFabric-A10

10

10

10

7A

7B

8B

8AFabric-BFabric-B

Storage provisioning in previous Enginuity versions required a separate command for each initiator port combination through which devices would be accessed. With V-Max auto-provisioning all is done in one step. With Enginuity 5874, users can create a group of:

Host initiators, or initiator group;Director ports, or port group; andSymmetrix devices, or storage group

In a V-Max environment, we associate all three (initiator, port, and storage groups) into a Masking View. When the Masking View is created, the devices are automatically mapped and masked, thereby accessible to the respective hosts. After the masking view is created, any objects (devices, ports, or initiators) added to an existing group automatically become part of the associated Masking View. This means that no additional steps are necessary to add additional devices, ports, or initiators to an existing configuration. All necessary operations to make them part of the configuration are handled automatically by Enginuity once the objects are added to the applicable group. This reduces the number of commands needed for mapping and masking devices and allows for easier storage allocation and or de-allocation. The DBA should understand auto-provisioning when discussing the creation of a Masking View for any specific Oracle application with the Storage Administrator.

Both the DBA and the Storage Admin can add host and or storage as business needs dictate with greater ease. Using the auto-provisioning functionality enables DBAs and Storage Administrators to set up multiple Oracle instances independent of each other quickly and easily. Upon doing so, documentation is key to ensuring that any configuration is understood across all functional groups. The symaccess “Show” command is a great way to build and verify configuration documentation.




EFD – Flash Drive Technology / BenefitsAll apply to an Oracle database environment:

30X IOPS compared to traditional disk drives

98% less power consumption per I/O compared to traditional disk drives

60% lighter in weight than traditional disk drives

No spindles, no mechanical failures

No special software required to manage the EFD technology on EMC’s storage arrays

EFD drives fit in the same enclosure as standard Fiber Channel drives– Same look and feel as traditional drives

Drives are seen by the storage and host as traditional Fiber Channel drives (73 GB, 146 GB, 200 GB, 400 GB) for both V-Max and DMX-4 Series arrays

Mirroring, RAID 5, RAID 6 supported on Enterprise Flash Drives– All members of the RAID group have to be EFD drives

EMC has been a pioneer in Flash Drive (EFD) technology. With the V-Max Systems, EMC has taken another leap in flash drive technology to support larger and denser drives. Typically with EMC Symmetrix V-Max systems, you will see support for 73 GB, 146 GB, 200 GB, and 400 GB EFDs.

This slide presents some of the characteristics and benefits of using Enterprise Flash Drives (EFD) with EMC Symmetrix V-Max Systems. All can be used to benefit an Oracle database application environment.




With the introduction of the DMX-4 running Enginuity 5773, EMC supports enterprise class flash drives – also known as EFD drives

Oracle with EFD Technology

Which database workloads best fit EFD configurations?

Random read workloads

Decision Support System (DSS) and/or Business Intelligence (BI) workloads

Write workloads

Latency critical workloads

Random read workloads – Understanding Symmetrix cache Read-hit and Read-miss is key to understanding how an Oracle environment configured on flash drives would benefit most from low latency flash drive technology. Any workload that has a high Cache Read-miss would benefit by retrieving data from drives at memory speeds

Decision Support Systems / Business Intelligence – Oracle performing full table scans or backups will issue sequential reads. Such sequential reads are long operations and rely on best through-put rather than best latency. The better the throughput, the quicker the report, query, or backup. Flash drives will increase perfect activity during a sequential read process resulting in a positive read-hit rate increasing overall performance.

Write workloads – It should be noted that Oracle online redo logs and archive log file activity are mostly sequential writes and because writes are serviced from Symmetrix cache, logs are not necessarily a good candidate for placement on flash drives. When configuring Oracle, if there is enough room, the database will still benefit by placing log activity on EFD drives. Understanding I/O requests from the host and analyzing front and back-end Symmetrix configurations will play a role as to where log activity should be placed.

Latency critical workloads – System Administrators and Storage Administrators configure a mission-critical application on a number of drives implementing “Short Stroke” data retrial to satisfy acceptable IOPS and latency performance requirements. With flash drives, an Oracle mission-critical application can replace many short stroke drives needed to support acceptable transaction rates. Reducing drives, floor space, and power are just a few benefits flash drive technology brings to the table.




Oracle with EFD Technology (Cont)

Oracle configured with EFD (Enterprise Flash Drive) technology

Possible eight-fold performance improvements

Database components recommended for EFDsIndexesLookup tablesHigh transaction rate tables/indexes or their more current partitions

Database components not recommended for EFDs drivesRedo logs are NOT recommended – Ref high sequential write activity

Here are just a few strategies when implementing enterprise flash drives (EFD) within an Oracle database environment.

1. Place the entire database on EFDs when the database performance ties directly to the business revenue.

2. Place a portion of the database on EFDs based on carefully identifying the busiest portions of the database and it supports both EMC’s and Oracle’s database configuration guidelines.

3. Place active database partitions on EFDs. As they get less active migrate to tier 1, 2, or 3 storage making room for new active partitions on the EFD drives.

4. In general, EFD drives benefit random read workloads such as OLTP applications. DSS (Decision Support Systems) may also benefit as they tend to become “random” over time.

5. Pure sequential workloads will benefit as well although to a lesser degree than random read processes.

6. By improving the performance of the busiest database components, it is likely that the overall database performance will also improve.

Just a note, disks are not always the bottleneck to improve overall performance. However, workloads will benefit when flash drive (EFD) technology is used.




Symmetrix V-Max Series TDEVs (Thin Devices)

Thin to non-thin replication– TimeFinder/Emulation– TimeFinder/Snap– TimeFinder/Clone– SRDF

TDEVs as R11, R21, or R22Multi-virtual Snap

Prohibited

• RAID 5– RAID 5 (7+1) on data devices– TDEVs bound to RAID 5 pool

–TimeFinder/Snap–SRDF

DSE on TDEVs

Allowed Thin DevicesEnginuity 5773

Enginuity 5874

from

To

Since the service release of Enginuity 5773, it has been the case that data devices can be of any protection type. With Enginuity 5874, TimeFinder/Snap or SRDF using thin devices bound to a RAID-5 pool is also allowed.

Now customers can virtually provision all tiers and RAID levels and support local and remote replication for thin volumes and pools using any RAID type. This includes support for RAID 1, RAID 5 (3+1), RAID 5 (7+1), RAID 6 (6+2), and RAID 6 (14+2), as well as support for TimeFinder/Clone, TimeFinder/Snap, SRDF/A, SRDF/S, SRDF/DM, Open Replicator, and Open Migrator.

Note that previously 3+1 was the only allowed RAID 5 configuration, but now 7+1 is also supported.

TimeFinder/Emulation, TimeFinder/Snap, TimeFinder/Clone, and RDF replication cannot be between thin and non-thin devices. The R1 and the R2 devices must both be either TDEVs or non-thin devices—no mixing is allowed in any of these replication relationships.

Thin devices cannot be R11, R21, or R22 devices, meaning that they cannot be used in a STAR configuration. Virtual provisioning does not support multi-virtual Snap. Enginuity 5874 does, however, allow you to have Delta Set Extension (DSE) with thin devices.

For more information on these topics, please consult the course “Symmetrix V-Max Series Business Continuance for Implementation & Management.”




Enhanced Virtual LUN Migration Technology Non-disruptive migration of devices and meta devices – Between RAID levels or Disk Groups– Key enabler for storage tiering within the array

Engine 6

Engine 5Engine 4

Engine 3

Tier 0

Tier 1Tier 2

Tier 3

FlashFlash FlashFlash

15KRPM

15KRPM

7200RPM

7200RPM

10KRPM

10KRPM

The Symmetrix V-Max Series with Enginuity 5874 enables users to perform non-disruptive migration of volumes among storage tiers within the same array and between RAID protection schemes.

Enhanced Virtual LUN technology is supported for both open systems (FBA) and mainframe volumes (CKD) and includes support for meta volumes. Enhanced Virtual LUN Technology is a licensed feature bundled under the Symmetrix Optimization offering which includes Symmetrix Optimizer.

Virtual LUN technology enables data migration within an array without host or application disruption allowing an Information Lifecycle Management (ILM) strategy to be adapted over time by easily moving information throughout the storage system as requirements change. It can assist in system reconfiguration, performance improvement, and consolidation efforts all while helping maintain vital service levels.

In this example, data may start out on a set of tier 0 volumes such as enterprise flash drives. Over time, that data may no longer warrant the high performance of flash drives. Migrating that data off array is time consuming and disruptive. However, leveraging Virtual LUN technology, this data can be moved to another tier in the same array without needing to shut down applications such as Oracle.




Migrate an application to a new Symmetrix arraySolutions Enabler and Symmetrix Management Consolesymrdf migrateReplace R1 or R2 deviceCreate new RDF pairsPlan to modify existing scriptsRDF group attributes will not be migratedConsistency exempt devices can be migratedConsistency exempt state will not be transferredSelect existing RDF pair and new deviceFBA and CKD

Current and new Challenges

symrdf migratesymrdf migrate

R1R1 R2R2

R1R1

The New Array

Adaptive Copy Disk

The New SRDF Device Migration Feature

Each new Enginuity platform creates a challenge for SRDF customers when they want to migrate their applications (Oracle) to a new Symmetrix array. Currently they need to issue a variety of symrdfcommands to complete this task. With Solutions Enabler 7.1 and SMC 7.1, there is a new “SRDF Migrate” feature that eases the migration of R1 or R2 Symmetrix logical volumes. The symrdfmigrated functionality enables DBAs and Storage Administrators to migrate Oracle applications from one array to a new array.

The SRDF Device Migration feature provides the ability to replace an existing R1 or R2 Symmetrix device with a new Symmetrix device and create new SRDF pairs. In this example, the R1 device will be replaced with a new Symmetrix device. In other words, we are migrating an application off the existing R1 device and moving the application to a new device on another Symmetrix array. During the migration, a concurrent SRDF relationship is established to transfer data from an existing R1 device to the new device in adaptive copy disk mode.

After the data is transferred to the new R1 device, the original R1 device is replaced with the newly-populated device and a new SRDF pair is created. An R2 device can also be replaced. The SRDF device migration is performed using the new “symrdf migrate” command.

Some of the challenges that must be considered before and after the migration includes modifying existing scripts with the new Symmetrix IDs, the SRDF device pairs, device groups, or composite groups. Oracle SQL scripts will also need to be reviewed and or modified.




Raid / Database Layout Considerations

Upon completion of this lesson, you will be able to:

Describe RAID technology and database layout considerations

Identify suggested RAID configurations for Oracle objects

List LVM and RAID best practice considerations when layout and Oracle database application

Describe the advantage of spreading Oracle metavolumes across multiple back-end disk directors





RAID Mirroring – Redundant Arrays of Inexpensive Disks

Data protection options are configured at the volume level and the same system can employ a variety of protection schemes– RAID 1

Highest performance, availability, and functionality Two mirrors of one Symmetrix Logical Volume located on separate physical drives

– RAID 0+1 Combination of RAID 0 and RAID 1 Provides the benefit of block-level striping across the array and the security of disk mirroring

– RAID 5 (Parity – Striped RAID Volumes)3 +1 (3 data and 1 parity volume) or 7 +1 (7 data and 1 parity volume) Data blocks are striped horizontally across the members of the RAID (4 or 8 volume) groupNo separate parity drive, parity blocks rotate among the group members

Raid 1

Raid 5

RAID selection should be considered when setting up an Oracle environment because it impacts performance. Today, because of improvements with disk reliability, a RAID 5 solution for many Oracle applications may be a viable solution. RAID 1, which is also known as shadowing or mirroring, should also be considered.

With a RAID 1 configuration, data blocks are replicated to the mirror device. In the event of a disk failure, the storage array (Symmetrix) switches to the mirror device. The performance impact is significantly less than with a RAID 5 configuration.

RAID 0+1, basically has the same fault tolerance as RAID 5. With this configuration, the data will survive the loss of a single disk. With a single disk lost, the result will be a striped RAID 0 environment.

With a RAID 5 configuration, performance is not an issue until one of the disks in the RAID stripe group is lost. Performance will be impacted while the RAID Stripe Group is reconfigured. A business needs to understand the performance impact between a RAID 1 and a RAID 5 configuration when one of its RAID members is lost.

When a business understands this impact, it is ready to select the best RAID configuration that will support any specific Oracle production configuration.




RAID 1 Mirroring

Note – RAID 1 requires a minimum of 2 drives to implement

Block 0Block 0

Block 1Block 1

Block 2Block 2

Block 3Block 3

Host Writes SPFront End

Back EndWrite CacheWrite Cache

Block 0Block 1Block 2Block 3

Raid Group

Block 0Block 1Block 2Block 3

Characteristics and advantages for a RAID 1 configuration include one write, or two reads, possible per each mirrored pair. RAID 1 is also one hundred percent redundant, which means no rebuild is required in the event of a disk failure. Also, the RAID 1 configuration is a very straightforward storage subsystem design.

Oracle applications that best fit a RAID 1 configuration are accounting, payroll, financial, or any application requiring high availability.




RAID 5: Independent Data Disks with Distributed Parity Blocks

Note – RAID 5 requires a minimum of 3 drives to implement

SPFront End

Back EndWrite CacheWrite Cache

Block 0Block 0

Block 1Block 1

Block 2Block 2

Block 3Block 3

Host Writes

…

Block 11Block 11

Block 0Block 3Block 6Parity

Block 1Block 4ParityBlock 9

Block 2ParityBlock 7Block 10

ParityBlock 5Block 8Block 11

Stripe 0Stripe 0Stripe 1Stripe 1

Stripe 2Stripe 2Stripe 3Stripe 3

Raid Group

Characteristics and advantages for a RAID 5 configuration include a very high “Read Data”transaction rate with a medium “Write Data” transaction rate. Low ratio of Parity versus Data on the disk means high efficiency utilization of the disks in this RAID configuration.

On the disadvantage side, a rebuild of the data in the event of any disk failure will have a negative performance impact on the Oracle application running within this RAID configuration.




Database Layout Considerations

Subsystems evenly balancedFront-end ports and back-end adaptors and disks are evenly loaded

Using RAID 5 / 3+1 or 7+1 configuration7+1 can perform twice as many reads as a 3+1Write Pending Limits are about the same Capacity between a 7+1 and a 3+1 RAID 5

Time skew: the data that most recently changed is also the most accessed

Tablespace activity: I/O activity against the data files

Best performance can be achieved when all subsystems within the array are evenly balanced. This means that front-end ports (host adaptors) and back-end disk adaptors are all evenly loaded. This can be achieved in most cases by the use of EMC’s PowerPath application to balance the load across the front-end ports, and by implementing striped volumes to spread the load across the back end of the Symmetrix array.

With respect to Oracle files, the I/O activity against any given object should be understood. With this information, both the Storage Administrator (SA) and the Database Administrator (DBA) can load balance the Oracle objects across selected storage to help avoid application contention within the array.

This is sometimes is referred to as “knowing your data”. Knowing Tablespace activity or the I/O activity against any Oracle data file is required when laying out an Oracle database. Data file placement onto storage is key to achieving optimal Oracle performance.




Tablespace 1System

Tablespace 2Undo Segments

Tablespace 3Temp

Tablespace 4Data

Primary Disks

Mirror Disks

Tablespace Striping Consideration for Performance

Striping is a technique available with metavolumes that provides performance benefits by spreading the I/O load across multiple disk spindles. With striped metavolumes, the addresses are interleaved with all members of the metavolume. Striped metavolumes reduce I/O contention on the physical disks, because the data is distributed across the metavolume.

A technique called “double striping” can also be implemented. It involves host-based striping with striped metavolumes.

When laying out a Relational Data Base Management System (RDBMS) database, tablespaceplacement must be carefully considered. The DBA must understand what database content resides in the different tablespaces. For example, a Storage Administrator should not place the system tablespaceon the same spindle as the Temp tablespace. Other considerations come into play that may be specific across different RDBMS applications.




Database Redo Log Layout

hyper 0Outer Hypervolumes for Redo Logs

hyper 4

0

4

Redo logs are write intensive

Redo logs are read during Archival or Recovery from a database crash

Redo logs are traditionally placed on their own physical disk

The Redo write performance can affect the performance of the entire database

Redo Logs are always sequential writes

Redo logs within a database are write-intensive operations. The redo logs are traditionally placed on their own physical disks. With the advent of large disks, it may not be practical to dedicate a physical disk to each redo log file. The redo log-write performance can affect the performance of the entire database. This is because a transaction commit is not considered complete until the corresponding redo log write is acknowledged by the Oracle kernel.

The Symmetrix system acknowledges all writes to a hypervolume (including redo log writes) at memory speed. This is true unless the write-pending limit for that hypervolume is reached. If a striped metavolume is used for the redo logs, the write-pending limit for the metavolume is the sum of the write-pending limits of its members. Therefore, the probability of hitting the write-pending limit is reduced.




Oracle Database Layout: DMX / V-Max

RedoVg

Ora_Data_Vg

Ora_Sys_Vg

PathSet_2PathSet_2

PathSet_3PathSet_3

PathSet_1PathSet_1

Oracle Instance

Production Host

PowerPath

Volume Management Control

Oracle Sys Tablespace

Oracle Data TablespaceOracle Redo

Tablespace

When implementing an Oracle application, careful planning and documentation will help organize your environment for both users and support staff. Integrating host-based striping with EMC PowerPath and a well-planned Volume Management structure, such as “Veritas” will result in a number of performance benefits as well as an environment that can be modified to support ongoing changes within any business.

With a well-planned Volume Management structure, adding or removing storage capacity can be done quickly and easily, with no impact to your RDBMS application.

Some consideration could be given to file placement on a given spindle within a volume group, but the result of any significant performance gains may be somewhat limited with this approach.

For recoverability, your redo logs should not reside on any devices that contain your Oracle data or system files.




Oracle Database Layout: DMX / V-Max (Cont)TimeFinder/Clone Point in Time Oracle Integration

Once the clone session is activatedClone devices can be mounted to a secondary Host Can be used for reporting / development / or testingCan be used to create point in time backups to tape or disk

RedoVg

Ora_Data_Vg

Ora_Sys_Vg

Oracle Instance

Source Host

Standards

Clone

Redo Device Group

System Device Group

Target Host

Oracle Point in time Instance

With this TimeFinder/Clone example, the result is a point in time replica. The “Point in Time” will be when the clone session was activated.

Performing a TimeFinder/Mirror is a little more involved. With BCVs, the following should be considered when creating a replica.

With TimeFinder/Mirror, an initial “Full Establish” will require a full track-for-track copy of all the device groups that make up the Oracle database. When initially replicating an Oracle database, the data, control, and redo log files are all required to ensure that the database will restart successfully on the target side.

Once a full replicated copy has been established, moving forward only requires an incremental copy of the redo and the control files. Once the Redo and Control has been synchronized, the Storage Admin should perform a consistent split. Then apply the redo files to bring the database up to the point-in-time of the split. The benefit is significant, with respect to time and cost savings because the data files, being the largest Oracle objects, are replicated only once.

There are specific steps to ensure your target database environment will start up successfully. They include putting the database in hot backup mode and synchronizing the source and target devices. Then perform a TimeFinder Split utilizing the consistency option to ensure that all devices within the TimeFinder device group are split at the same time. Once the consistent split has been performed, the DBA can take the database out of hot backup mode.




Oracle Objects: Suggested RAID Configuration

Oracle Control, Redo, and ArchiveRAID 1

SymmetrixStorageArray

D D D POracle Data Files

RAID 5

This table represents only a set of suggested RAID layouts. When setting up an Oracle application, careful file layout should be given for every Oracle object. I/O activity against Oracle files may differ from application to application.

Input from the DBA, System Administrator, and the Storage Administrator should be considered when selecting the appropriate RAID configuration for any Oracle application.




Reference:• Engineering White Paper Oracle Database Layout on Symmetrix DMX• “Oracle Database on EMC Symmetrix Storage Systems Solutions Guide”

Best PracticesBest performance when all subsystems are evenly balancedUse RAID 1 or RAID 5 configurationsUse striped metavolumes or concatenated metavolumesPlacing Redo Logs on separate disk spindles may not be necessary

Monitor the write-pending values for theses volumes

LVM considerations Use multiple disk groups for data, redo, temp, undo, and archive Configure disk groups where LUNs are the same size and have the same performance Use EMC PowerPath for load balancing and path failover

When setting up an Oracle application environment, the following best practices should be considered.

First, the use of either RAID 1 or RAID 5 configurations provides good performance in most cases. Next, use either striped metavolumes or host striping to spread the data files across larger number of disks. Keep in mind that the use of concatenated metavolumes can result in bottlenecks. Finally, place Redo Logs onto separate disk spindles when possible.




Oracle Overview and Storage Features Upon completion of this lesson, you will be able to:

Identify the terms database and instance

Identify the major components that make up the Oracle database and an Oracle instance

Describe an Oracle ASM (Automated Storage Management) environment and its integration with EMC storage

Describe an Oracle RAC (Real Application Clusters) and its integration with a DMX / V-Max environment

Describe Oracle’s Flashback Technology and its integration with EMC’s TimeFinder application





SGAData Buffer

CacheRedo Log

Buffer

DBW0DBW0 CKPTCKPT LGWRLGWR ARC0ARC0

SMONSMON PMONPMON RECORECO

Data Files Control Files Redo Files

Library CacheData Dictionary Cache

Shared Pool

The OracleInstance

The Database

The Oracle Instance

The components that make up an Oracle Instance consist of a set of memory structures and a number of system processes. The memory for the Oracle instance is called the System Global Area, or SGA. The SGA consists of a number of memory components that all support the Oracle database. When the “instance” is started, the SGA allocates memory per the init<sid>.ora file. This file contains startup parameters and settings for the instance.




SGA

SMON PMON RECO

DBW0 CKPT LGWR ARC0


Data BufferCache

Redo Log BufferLibrary Cache

Data Dic Cache

Shared PoolSGA

Memory Structures for the InstanceData Buffer CacheShared Pool

- Library Cache- Data Dictionary

Redo Log Buffer

The SGA

Oracle Memory Structures

The Data Buffer Cache is cached data retrieved from the Oracle database. Oracle uses this memory buffer to store data that has recently been used. Any data that has been retrieved or modified is stored in this memory buffer anticipating that the same data will be used again. Using data that is found in the Data Buffer Cache results in improved performance because the system does not have to execute an I/O to disk operation.

The Shared Pool consists of the Library Cache and the Data Dictionary Cache. SQL statements and procedures are cached into the Library Cache area for reuse. Any commands that are issued to Oracle must be interpreted. The results are stored into this memory area. When the command or procedure is reissued, Oracle does not have to reinterpret it, resulting in significant performance gains.

The Data Dictionary Cache area maintains the structures for all the tables and views for the database.




SMONSMON PMONPMON RECORECO

DBW0 CKPT LGWR ARC0


SMON - The System MonitorPMON - The Process MonitorRECO - The Recover Process

SGAData Buffer

CacheRedo Log

BufferLibrary CacheData Dic Cache

Shared Pool

Oracle System Processes

The primary function of SMON (System Monitor) is to ensure that all of the Oracle processes are working together correctly. The SMON process performs recovery on a failed database instance. SMON is not a guarantee that a failed instance will recover, but it will always attempt to correct any problems. SMON also plays a role in coordinating multiple instances in a Parallel Server (Multi-System) database environment.

The PMON (Process Monitor) ensures that all the Oracle processes are running correctly. It also interfaces with the operating system. The PMON process links the Oracle database processes back to the kernel (the operating system).

The RECO (Recover Process) is used when the database is restarted after a failure has occurred. When the instance starts and Oracle detects that a crash has occurred, the RECO performs an instance recovery automatically. Every time you start an Oracle Instance, a check is performed on the control files and all the database files ensuring that all the files are synchronized. If they are not synchronized, then an instance recovery is done automatically.

Recovering a database requires the use of the Redo Logs which contain a record of all database changes. All the modifications from the last checkpoint are applied to the database files. The Recover Process automatically commits the uncommitted modification. This is called a Roll Forward Instance Recovery. Once this is done, the Control Files and Database files are synchronized to reflect a good “Instance”. A new Checkpoint is established and the database is opened to all users.




SGAData Buffer

CacheRedo Log

Buffer

SMON PMON RECO

DBW0DBW0 CKPTCKPT LGWRLGWR ARC0ARC0


Library CacheData Dic Cache

Shared Pool

DBW0 - Database Writer ProcessCKPT - Checkpoint ProcessLGWR - Log Writer ProcessARC0 - Archive Process

Oracle Processes

Oracle Processes

The Redo Log Buffer caches redo (database change) information until it is written to the redo log files on the disk. The reason for this is to improve performance by avoiding the constant writing of all modifications to the disk.

The DBW0 (Database Writer) process writes database blocks from the database buffer cash (within the SGA) to the appropriate database files out on the disk. The Oracle Instance can have up to ten DBW (DBW0 – DBW9) processes running at the same time. Most Oracle environments will be running only one DBW process at any time. Think of this Oracle process as how data moves from memory (Cache) to the disk.

The CKPT (Checkpoint) process marks data blocks that have been written to disk as “committed”. This is how Oracle synchronizes the Data Files with the Redo Files. Remember Redo works in a circular fashion and overwrites previous redo (change) entries. A redo entree is not overwritten unless the checkpoint process has marked the entry as committed.

The LGWR (Log Writer) process writes redo log entries from the Redo Log Buffer Cache to the Redo Log Files on the disk.

The ARC0 (Archive) process, when in Archive Log Mode, moves redo (database changes) data from the Redo Log files to the Archive Log files.




ASM: Oracle’s Automated Storage Management

Automated Storage Management (ASM) introduced with Oracle database release 10g

ASM provides a flexible storage solution, supporting a dynamic database environment

ASM helps minimize manual I/O performance tuning tasks

Helps automate best practices and increases DBA productivity

Automated Storage Management (ASM) is a feature introduced with the release of Oracle 10g. It is a high-performance storage management solution for Oracle database files, supporting all platforms. ASM is designed specifically to simplify the job of the database administrator (DBA). ASM provides a flexible storage solution that simplifies the management of a dynamic database environment.

Adding and or removing disks to the Oracle database environment has been simplified with the introduction of ASM. In the event of a tablespace running out of disk space up to now has been a difficult task to solve. With the introduction of ASM, the DBA now has control of simply adding a disk to the Oracle database environment. No shutdown or loss of production time is required. Adding additional disks to the Oracle application within ASM control will result in the database files rebalancing themselves across the new disk.




The ASM File SystemThe ASM File System

The Oracle ASM Disk Group

Oracle databasefiles are spread across the ASM disk group

The Oracle DatabaseKernel

The Oracle ASM Disk Group

A disk group is a collection of disks managed as a logical unit. The Oracle ASM environment spreads each file evenly across all disks within the ASM disk group to balance the Oracle I/O activity automatically. The ASM file system layer transparently sits atop the disk group. It is not visible to O/S users. The ASM files are only visible to the Oracle database kernel.

Do not confuse an ASM disk group with a Logical Volume Management disk group or an EMC device group. The ASM disk group is controlled by a separate Oracle instance which has Oracle objects spread out across the disks within the ASM group.




ASM: Automatic Storage Management (Cont)

Storage can be added or removed without shutting down the production database

ASM will automatically rebalance any DB files across the newly configured (added) disks

Within 11g their are two instances:– The production database instance– The ASM instance

The ASM instance must be running before you can start the production database instance

The ASM functionality increases database availability. A DBA can add or remove disk devices from the ASM disk group without shutting down the database. ASM automatically re-balances the database files across the ASM disk group after disks have been added or removed.

Disk groups are managed by a special Oracle instance, called an “ASM Instance”. This instance must be running before the database instance can be started. When you choose ASM as the storage mechanism for your database, the Oracle kernel will create and start the ASM instance automatically.




The RAC Application Cluster Pool

The Network

Users

Oracle RAC Memory and System Processes

The Storage Network

The Database

Also referred to as Oracle Grid

Oracle RAC (Real Application Clusters)

What is Oracle RAC? With Real Application Cluster (RAC), Oracle allows multiple hosts running multiple instances to access one database.

As described in previous slides, the Oracle Instance, consisting of Oracle Memory and System processes, enables access to a single database—the database being Data, Control, Redo, and Archive files.

With Oracle RAC, the hosts in the cluster, having their own instance, connect or access a single database. In other words, every host in the Oracle RAC cluster has its own Oracle Memory and System Processes, all accessing one database.




What are the Oracle RAC Benefits?

High Availability – Redundancy of hardware, memory, and system processes ensures High Availability

Scalability – Performance is spread across the RAC cluster pool

Growth – The DBA can add users, hosts, and storage to the RAC environment without shutting the database down

Cost Savings – Reduced hardware cost as a result of running applications across the cluster

Because Oracle RAC allows multiple systems to access the database, a number of benefits can be seen.

First is High Availability. Because of redundancy, (Multiple Hosts) the availability of the database to the user becomes very high. If one of the hosts in the Oracle RAC cluster pool were to go down, the availability of the database to the user stays up, because of the redundancy.

Second is Scalability. Performance is spread across the Oracle RAC cluster pool. If additional resources are needed to improve performance, hardware can be easily added to the RAC cluster environment.

Third is enabling Growth. Servers or storage can be added without bringing the production environment down. Keeping production up and available at all times is one of the key objectives for any Oracle RAC environment.




The Storage Layer

The Computer System Layer

The Database Server Layer

The Application Server Layer

11

22

33

44

The Database

The Network

Users

Oracle Clusterware ServicesOracle Cluster File System (OCFS)

Oracle ASM Disk Groups

Oracle RAC Interconnects

The Oracle RAC Interconnect is made up of a number of layers. The first layer is the (1) Computer System layer or Node Layer which consists of all the nodes that make up the cluster. The second layer is the (2) Application Server layer and consists of RAC services, Cluster Services, and the Cluster File System.

Oracle Clusterware Services is responsible for all the nodes in the RAC environment. The Cluster Service is installed and runs on every node in the cluster. This service detects all other cluster nodes and detects the failure of any node in the cluster. Another way of saying this is that the Cluster Service running on each node in the cluster keeps track of the membership and services within the entire cluster.

The Oracle Cluster File System (OCFS) enables all the nodes in the cluster to access the same file system. Because multiple instances residing on multiple nodes are accessing one database, the OCFS enables multiple node data caching.

The third layer is the (3) Database Server which consists of Database Management Extensions. These are stored procedures and/or user-defined routines addressing specific business application requirements.

The fourth layer is the (4) Storage Layer. Within this layer Oracle’s ASM application is recommended to help control volume utilization within a RAC cluster environment.




The Network

User


The Storage Network

The Database

In Memory / Data Buffer Cache

AA CC

AA CC

Shared Cache

User


Oracle RAC Shared Everything

Oracle RAC ensures that any data that has been modified becomes the most current to all the RAC users. Let’s look at an example.

User A updates a record in the database and the modification is placed in the data buffer cache. This modification may end up on Host A. User C, moments after the update, queries the database, but at the time of the query the modification has not been flushed out to disk. At this point in time, if the query reads the data off the disk, User C will not see the updated record that was created by User A.

RAC uses a function called Cache Fusion which looks at all memory cache elements as “one” across all the nodes in the Oracle RAC cluster. In this diagram, we have four nodes, each having its own data buffer cache. With Cache Fusion, the four data buffer cache elements are looked at as one element.

With Cache Fusion, the query first checks the data buffers across all the nodes. The most recent modification to satisfy User C’s query happens to reside on Host A. The query notices that the most current modification is still in data buffer cache. With Cache Fusion, it does not matter which host has the modification. Because the record in question is more current in the data buffer than what is out on the disk, resulting in User C getting the most up-to-date modification. Cache Fusion is also referred to as Shared Everything.





The Network

Users


ASM DG1 Data

Shared Cache

The Database

ASM DG2 Redo

ASM DG3 Archive

Oracle RAC / Storage Solution

Oracle RAC will not run on a regular file system. Oracle RAC works directly on “Raw Devices” or requires a clustered file system such as Oracle Cluster File System (OCFS). If OCFS is not selected, then Oracle RAC requires Oracle ASM (Automated Storage Management).

To run Oracle ASM, each disk group must have its own Oracle instance. In most cases, when setting up a RAC environment, Oracle will recommend a storage configuration that includes devices managed by an ASM instance.




ASM DG2Redo

Raid 1

S.A.M.E. Stripe and Mirror Everything

ASM DG3ArchiveRaid 1

D

DD

PD

D

DD

DP

DD

D

DD

PD

DD

D

PP

DD

DD

P

ASM DG1Data

Raid 5

Oracle RAC / Storage Solution

With respect to physical storage, data must be kept redundant. The RAID technology one selects depends on a number of factors. The file type and the application itself are just a couple of the key factors that drive the RAID type.

Oracle recommends a “Stripe and Mirror Everything” approach to ensuring redundancy. Mirroring a drive addresses a device hardware failure where Striping addresses performance. Whatever RAID strategy is used, the key is to ensure the data is available at all times.

Oracle RAC ensures that the Oracle environment will always be available where the RAID strategy ensures that the data will always be available. One without the other means that the Oracle database environment will at some point be down, and in today's fast-paced environment, any down time is unacceptable.




Global Solutions Oracle 11g RAC Case Study Configuration

Clients (6)

Cisco 35686LAN Switch Oracle 11g

RAC Servers

Brocade 4900SAN Switch

EMC SymmetrixDMX3 4500

1122

33

11 Dell 6850 Clients

22 Dell 2950 RAC Servers

33 Symm DMX 3 4500Data /Raid 5Redo / Raid 1Archive / Raid 1

3 ASM Disk GroupsDataRedoArchive

Oracle RAC / Storage Solution (Cont)

According to tests performed in EMC labs, increasing disks by twenty percent of your original storage will increase your performance by eight percent. This increase means that you can support more users and more transactions.

By using ASM, you can add or remove disks from your ASM disk groups without shutting down the database. Either operation will trigger a rebalance. This operation rebalances any database files across the newly configured ASM disk group. The database parameter asm_power_limit controls the power limit. This is a numeric parameter and it has a range from 1 to 11, with 11 being the most powerful.

The tests performed in EMC labs were done by adding and removing 16 disks and using 17,000 users. The results have proved that using the maximum power had the greatest effect on the node where the rebalance operation was running. The other nodes were affected but to a lesser intensity.

For detailed performance metrics reference User Case studies “Oracle 11g RAC on DMX3 with Linux” (Project 9) and “Oracle 11g RAC on DMX3 with Solaris” (Project 15), both authored by the Global Solutions Operations group.




Oracle 11g Flashback Technology

What is Oracle Flashback?

Database “point in time” recovery facility introduced with Oracle 9i

Provides features to view and rewind the database back and forth in time

Enables query of past versions of schema objects

Enables self service repair to recover from logical corruption while the database is online

11g Flashback Technology enables the DBA to “undo”the past

Oracle introduced Flashback technology in version 9i and has extended this technology into versions 10g and 11g. Flashback is a new strategy supporting point-in-time recovery. It rewinds an Oracle database to a previous point in time to help identify logical data corruption or user errors.




The OracleInstance

The OracleInstance

At timestamp “T2” the “test_table”was accidentally dropped

At timestamp “T3” the table “test_table”was Flashbacked or recovered.

Data

Flashback

Recovery

Area

T1 T2 T3

Oracle Production Host

Table Dropped

Oracle 11g Flashback Technology (Cont)

Flashback is similar to the “Undo” feature found in most office applications such as word processing or spreadsheets. End users suddenly realize that things are not going well. Rather than trying to fix it, the database administrator with the correct privileges can just undo it.

Database environments in the last several years actually allowed DBAs to implement an “undo”function that will undo transactions or roll back the database to a specific point in time.

Flashback is Oracle’s roll back or undo function for its RDBMS database. Once Flashback is enabled, and the DBA has been given permission to use it, the database can "flashback" a dropped table or undo the last SQL changes to a table. The DBA can even flashback an entire database to get back to an earlier point in time.




Drop / Flashback: The Recycle Bin

SQL> drop table customer;

SQL> drop table inventory;

SQL> show recyclebin;

SQL> flashback table customer to before drop;

SQL> flashback table inventory to before drop;

The Oracle Instance (Prod)The Oracle Instance (Prod)

Flashback Enabled

Control Data Redo ArchStd01 Std02 Std03 Std04

Oracle Source Host

Flashback Recycle bin

“Customer”“Inventory”

Tables

11Contents of the “Recycle Bin”after the drop table command

Dropped

Recovered

In this example, a user or application has inadvertently dropped both the customer and inventory tables. The statements in the slide will recover both the customer and inventory tables from the “Flashback” Recycle Bin.




EMC / Oracle integrated Replication Solutions Upon completion of this lesson, you will be able to:

Describe an Oracle offline and online backup scenario and its integration with EMC’s TimeFinder applicationDescribe an Oracle ASM / RAC and Flashback integration with EMC’s TimeFinder applicationDescribe TimeFinder clone and snap applications and their integration with an Oracle 11g application environment Describe EMC’s SRDF/S and how it best meets an “instant” RPO and a RTO of only a few minutesDescribe EMC SRDF/A solution for an Oracle database applicationDescribe EMC’s PowerPath and ECA Consistent Split technology Describe EMC’s Replication Manager application within an Oracle 11g environment





Local

TimeFinder Mirror (Note 1)

STD

BCV

• BCV mirror copy can be mounted to the Target host

TimeFinder Clone

STD

STD

• Clone copy used to create a point in time copy

TimeFinder Snap

STD

Snap• Snap: disk saving

point in time copy

Clone Emulation with 5874 /SE 7.0

Remote

SRDF/A Asynchronous

• Remote Target database is restartable

SRDF Synchronous

• Source will always equal Target

EMC Solutions

EMC offers a number of Business Continuance applications that support both Oracle 10g and 11g business environments. These solutions are meant to help solve a number of Business Continuance situations and assist IT environments by helping businesses meet their Recovery Point and Recovery Time objectives. RPO and RTO business requirements drive the selection of the most appropriate Business Continuance application.

This lesson will present functionality for both the Symmetrix DMX and Symmetrix V-Max product families. The term “Symmetrix Storage Array” when describing Business Continuity functionality is used to refer to both platforms.

When describing Business Continuity functionality for the Symmetrix V-Max Storage System platform, it should be understood that Enginuity 5874 with Solutions Enable 7.0 has been implemented.

Note: With Enginuity 5874 and Solutions Enable 7.0, invoking TimeFinder/Mirror functionality invokes TimeFinder/Clone functionality, which is also known as “Emulation Mode”.

It should also be understood that the Symmetrix V-Max Storage System is a new offering in the Symmetrix product family. The Symmetrix V-Max is not a replacement for the Symmetrix DMX. EMC is expanding its Symmetrix Storage offering with the Symmetrix V-Max introduction.




Oracle “Cold” Backup and TimeFinder Integration

The safest and easiest form to backup or replicate an Oracle database

Cold or offline backup requires shutting down the database

Used to create a point-in-time Oracle image

TimeFinder can be used to create the second database image

SourceHost

oratrgdg

Standards

Backup Host

BCV’s

X

An “Offline” backup of an Oracle database is the safest and easiest to perform. When the Oracle environment is online, control files, data files, and redo logs are consistently being written. Shutting the database down, which quiesces all I/O activity to the Oracle files, results in a point-in-time Oracle environment that can be replicated to target devices.

Once the Oracle database is shut down, TimeFinder can be used to replicate the Oracle database. Once a full establish has been performed, the storage administrator can split and mount the BCV devices to the target host. At this point, the system administrator can bring both databases back up on the Source Host and Target Host.

The second instance can be used for development, testing, or reporting. This process means that the Oracle production environment is unavailable to the business for some time. Depending on the size of the Oracle database, this timeframe could be significant and cost prohibitive to the business.

The key here is if the business accepts the shutdown of the database as its restart point (Recovery Point) and the business can be without the database for the amount of time it takes to replicate it (Recovery Time) then an offline strategy can be implemented.




Oracle “Hot” Backup and TimeFinder Integration An online or hot backup is a physical backupThe database remains open or onlineExtra archived log files during the backupAdditional archived logs can be applied to update the databaseWhy Hot Backup?– A recoverable copy of the

database is required – Zero business down time

Data

System

oratrgdg

SourceHost

Standards

Backup Host

BCV’s

X

Arch

An online or hot backup is done while the database remains open. This process is usually scripted, which includes placing Tablespaces into a “Hot Backup” mode. When a tablespace is placed in this mode, Oracle logs change data blocks to a set of archive log files. This log keeps track of all database transactions as long as the tablespace is kept in this mode.

TimeFinder can be used to copy the archived log to the target destination. The DBA on the target host simply applies the archive logs to the data files, which results in a synchronized target database. The archived log file is generally not as large as database files, resulting in saved network bandwidth. The entire database is not required to be copied over every time a backup is needed.

The key here is if the business cannot accept the shutdown of the database as its restart point (Recovery Point) and cannot be without the database for the amount of time it takes to replicate it (Recovery Time) then an online “Hot Backup” strategy should be implemented.




EMC TimeFinder / ASM Integration

The Oracle - Disk Group

The ASM File SystemThe ASM File System

DEV01DEV01 DEV02DEV02ASM Disk

GroupThe Oracle databasefiles spread across the ASM disk group

The Oracle DatabaseKernel

BCV01BCV01 BCV02BCV02 BCV03BCV03EMC’s TimeFinder Device Group

DEV03DEV03

Can be used for…Disk-based backupDatabase replicasDecision support Problem resolution

Source Host

Target Host

EMC’s TimeFinder application allows customers to use business continuance volumes which are mirror copies of standard storage devices. A BCV device can be accessed (when split) by a separate host while the standard devices remain online. When the BCV are in a split state from its standard, it represents a mirror of the standard device, or a point-in-time copy, which can be accessed directly by a second host. This functionality provides the user the ability to start up a second Oracle instance, which may include an ASM instance.

The introduction of Automatic Storage Management (ASM) greatly reduces the administrative tasks associated with managing Oracle database files. ASM is a fully integrated host-level file system and volume manager for Oracle, and eliminates the need for third-party volume management for database files.

What’s key here is that a TimeFinder device group must be aligned with the Oracle ASM disk group. Devices added or removed from the ASM disk group should include adding or removing devices from the TimeFinder Device Group.




The “Production Database”

ASM DG1 Data

ASM DG3 Archive

ASM DG2 Redo

StandardDevices

TimeFinder / BCVDevices TimeFinder – “Point In Time Copy”

TimeFinder – “Device Group”

Oracle RAC / EMC Integration

With RAC/ASM, storage devices assigned to any ASM disk group can be removed or new devices can be added. Once a storage device is added or removed, Oracle will rebalance the I/O across the ASM disk group. All of this can be done without bringing the database down.

Removing or adding a storage device to any ASM disk group must be taken into consideration across the TimeFinder device group. For example, if the storage administrator adds a new device to the ASM Redo disk group, a new BCV device needs to be added to the TimeFinder device group.

If the BCV point-in-time copy is to be used in an RAC/ASM environment then the –exact flag should be used. Doing so will enable the DBA and Storage Administrator to recreate a set of ASM disk groups that can be used by the backup Oracle RAC environment.




1. Shutdown the Target database2. Un-Mount the target file system3. Put the production database in backup

mode4. Flush the source redo5. Establish (TimeFinder) Source to

Target6. Split (-Consistent) the device group7. End backup mode 8. Mount the target file system9. Startup the target database

The Oracle Instance (Production)The Oracle Instance (Production)

Flashback Enabled

Control Data Redo

Oracle Target Host

Arch

Flashback Enabled

Control Data Redo ArchBCV01 BCV02 BCV03 BCV04

Std01 Std02 Std03 Std04

TimeFinder Device Group“flash_dg”

The Oracle Instance (Backup)The Oracle Instance (Backup)

Oracle Source Host

1

Oracle Flashback: Integration with EMC TimeFinder/Mirror

This scenario represents an Oracle Flashback environment integrated with EMC’s TimeFinderapplication. The Flashback Database feature included with Oracle 11g is especially suited for use with EMC TimeFinder technology. The ability to flash back a TimeFinder replicated database to a point in time, without disturbing production, is invaluable when determining the root cause of any corruption situation.




With a TimeFinder database copy:

A recovery plan can be created and tested

Using Oracle flashback the user can determine (Flashback query) the point in time to revert back

The business can Flashback the production database or perform a TimeFinder restore (BCV to Std copy)

Testing is done on the TimeFinder copy

Oracle Flashback: Integration with EMC TimeFinder/Mirror

Once a get well plan has been established, the Storage Administrator and the DBA can perform one of two things. The production database can be brought back online using the command set that was used on the target database, or the Storage Administrator could perform a TimeFinder restore to bring the database back online.




TimeFinder Mirror Copy

Production orSource Host

Backup orTarget Host

Source Device

Target Device

Symm

Symm 1 Symm 2

RDF LinkSRDF

Production orSource Host

Backup orTarget Host

Source Device

Target Device

TimeFinder / SRDF Replication Concepts

Regardless of what method or application a business uses to replicate their data, when a device is mirrored, the “Disk Signature” from the source device is copied to the target device. Having two devices with the same PID (Physical ID), disables the user from using both the source and target disks at the same time from the same host.




The Source Oracle InstanceThe Source Oracle Instance/u01/app/oracle/product/10.1.1

ora_sys_vg/u02/data1

ora_data1_vg/u03/data2

ora_data2_vg/u04/redo

ora_redo_vg

The Target Oracle InstanceThe Target Oracle Instance

ora_sys_vg

ora_data1_vg

ora_data2_vg

ora_redo_vg

= TimeFinder Device Groups

ora_sys_dg

ora_data_dg

ora_redo_dg

Dev#Production

Backup

EMC TimeFinder Integration / OFA

This slide takes a number of issues into consideration when setting up an Oracle environment. Is the environment “OFA” compliant? Are my Oracle files laid out efficiently within the Symmetrix storage array? Are the Volume Groups appropriately sized to support the Oracle application?

These are just some of the questions that the Oracle support staff should consider when developing an environment to support both an Oracle database and an Oracle application. Creating a diagram (see slide) for any business application will also help the support staff understand all hardware and software involved in creating an Oracle environment that works efficiently for the business.




orasrcdg

oraarchdg

orasysvg

oradatavg

oraarchvg

oratrgdg

= Veritas Volume Groups= SRDF – Device Groups

Production Host (1)

Target Host (2)

= TimeFinder Clone – Mounted to the third Host (Clone/Snap Host)

= TimeFinder Snap Session – Mounted to the third Host

oradatadg

R2 Env.R1 Env.

R1 DMX R2 DMX

Clone Copy

Snap Session

Clone Snap Host

Mount Host (3)

SRDF – TimeFinder Clone / Snap Environment

Once the disk groups, mount points, and all devices have been set up and documented, the next step is to set up the SRDF and/or TimeFinder applications. The diagram on this slide is an example of an SRDF / TimeFinder / Clone and Snap environment. This lesson references this setup from time to time. Notice this setup has three hosts: a Production Host, a Target Host and a Mount Host. Take a moment to review the environment and try to relate this diagram to a real world database application.

It is critical to understand the relationship of the host volume manager to the storage configurations within your Oracle environment. As mentioned, it is also critical to document any database environment. As the database grows, any initial setup may need to be adjusted to ensure that performance will always meet business demands.




TimeFinder/Clone Oracle Integration

TimeFinder/Clone is an instant “point-in-time”copy of a Symmetrix standard device or a TimeFinder BCV

symclone command set

SourceDev001

SourceDev001

TargetDev005TargetDev005

Target Host

Controlling Host

TimeFinder/Clone is an “Instant” point-in-time copy, which makes the Oracle database immediately available to the target host upon activation. When activation takes place, the session copies all tracks to the clone device that the source modifies (Copy-On-Access). If a track is requested from the target host that has not been copied, the clone process will copy this track from the source to the target and mark the track as “copied”. The TimeFinder/Clone solution is an ideal application for any Oracle database that is not write intensive.




EMC TimeFinder/Clone Point-in-Time Copy

Oracle Data (Tracks) are copied to the “Target” device– The first time a track on the source device is “Written” to– Or a track on the target side is “Accessed”

Oracle“Point-In-Time” Copy

The “Point-In-Time” is established …

- When the Clone Session is “Activated”

Production Host Write

toTrack

OriginalTrack

BackupHost

Source Device

CloneDevice

When you initiate a clone session on an Oracle device, any track that is written to or read from will first be copied to the Clone target device. This may have some negative impact on the Oracle application. Using the full copy flag will create a full Oracle-replicated database environment on the clone that can be used for reporting. Moving decision support activity off production and onto the clone devices should result in positive performance gains for the business.




TimeFinder/Clone Set-up Steps

Shut down the Oracle application (target).

Deport the Veritas dg # vxdg deport <dg_name>

# symclone –sid <remote_sid> –file <file> recreate

Re-Create the clone session.

Re-Establish a new point in time clone session.

7

# symclone –sid <remote_sid> –file <file> activate

–consistentActivate the new clone session8

% sqlplus /nolog

sql> connect / as sysdba

sql> startup pfile = <‘$ORACLE_HOME/...>

On the target host start the Oracle instance.

6

# vxdg import <dg_name> (Veritas) On the target host, import the disk group.

5

# symclone –sid <remote_sid> –file <file> activate

-consistentActivate the clone session 4

Use an editor to create this file. Create a Clone device pair file. 1# symclone –sid <remote_sid> create –file <file>

-precopy –diffCreate a clone session 2

# symclone –sid <remote_sid> create –file <file>Perform a query on the clone session.

3

CommandExplanationStep

This slide displays the command steps to set up a TimeFinder/Clone session. The key to remember is that once the clone session is activated, the target host has a point-in-time copy of the Oracle environment that can be used immediately. Please take a moment to review the commands.




TimeFinder/Snap Oracle Integration

Source

Standard DevDevice

TargetVirtual Dev

Device

Sav Dev

I/O

I/O

TargetHost

ControllingHost

Pointers from Virtual to Original Data

Original Data Copiedto Sav-Dev’s

“CopyOnFirstWrite”

Pointers to Sav Dev’s

Another EMC replication application to consider is TimeFinder/Snap. A snap session must first be created that defines the snap devices. Once the session is activated, the target virtual devices become accessible to the host. When the information is no longer needed, the session can be terminated.

Multiple snap sessions against an Oracle environment can be created, resulting in multiple “point-in-time” database snaps. TimeFinder/Snap is best for an Oracle environment that requires multiple point-in-time images against a database environment that has minimal track changes.




“Point-In-Time” Snaps

Std#DEV##

Std#DEV##

VDEVVDEV##

ControllingHost

Source VDEVVDEV##

DEFAULT_POOL

Device Group(1) Ora_300

Host A Source

Oracle Point in time3:00 pm


Ora_600_POOL


Std#DEV##

VDEVVDEV##


Ora_900_POOL


Host B Target

Host C Target

This slide displays point-in-time snap sessions that reflect the state of the Oracle database at the time the snap session was activated. A practical use could be the creation of a production reporting environment that reflects the status of a “shop floor” manufacturing line at various time stamps throughout any given day.




Ref – Notes for Snap / Oracle SQL command lines.

Activating an Oracle Hot Backup Environment for an Active Snap“Point in Time” Copy Session

1. Create a Copy session that includes all the Oracle Data files2. Create a second Copy session that include archive redo logs and a

backup of the control file3. Enable “Archive Log Mode”4. Place all Tablespaces (those that you want to backup) into “Hot

Backup Mode”5. Activate Snap session for the Data File Copy6. Take all the Tablespaces out of “Hot Backup Mode”7. Archive the current online redo log8. Save a copy of the backup control file9. Activate the archive log copy session, which makes a point-in-time

image of the archive redo log and the backup control file available

This slide lists the process steps needed to activate a snap session against an Oracle database that is in archive mode. This process should be scripted and tested before it is placed into any production environment.

Please take a moment to review this procedure.




Oracle Integration using SRDF/S Synchronous

Source and Target are equal at all times

RPO recovery point is instant

RTO recovery time may be only a few minutes

Production transaction committed only when the target acknowledges the transaction

orasrcdg

oraarchdg

orasysvg

oradatavg

oraarchvg

oratrgdg

“Production”Host(1)

“Target”Host(2)

oradatadg

R2 Env.R1 Env.

R1 DMX R2 DMX

SRDF/S (Synchronous) is used when the configuration requires that the source and target must be equal at all times. When a customer’s Recovery Point Objective (RPO) must include the last database transaction, then SRDF/S should be implemented.

With SRDF/S, any database transaction on the production host is committed only when the target storage array acknowledges the transaction back to the production array.

SRDF/S will maintain full synchronization at all times. When using SRDF in full synchronization mode, a best practice is to keep the RDF link established at all times. With an active RDF link, every database transaction is replicated to the target array, enabling an instant RPO (recovery point) and a RTO (recovery time) of only a few minutes.




Oracle Integration using SRDF/S Synchronous (Cont)

Setting up the SRDF device groups

Add your devices to the device groups

R1 synchronized with R2

Production Oracle “Available”

Target Oracle “Not Available”

orasrcdg

oraarchdg

orasysvg

oradatavg

oraarchvg

oratrgdg

“Production”Host(1)

“Target”Host(2)

oradatadg

R2 Env.R1 Env.

R1 DMX R2 DMX

Oracle isUp and

AvailableOracle NotAvailable

When setting up an Oracle SRDF/S environment, the storage administrator may need to create a number of RDF device groups. Once the device groups are set, the storage devices must be added to the appropriate groups. This is where good documentation and planning help make the process very easy. Once the R1 to R2 relationship has been established, out-of-synch tracks on the production array are replicated to the target array.

The replication process continues until all the out-of-synch tracks are replicated to the target array. During this process, the Oracle database is available to all production users. When a user enters a transaction on the source side, the R1/ R2 relationship identifies the out-of-synch track and immediately copies this track (or tracks) to the target array.

When in SRDF/S mode, the relationship between the R1 and R2 devices are always in a synch (synchronized) state.

On the target side, Oracle is not available because the R2 devices are not mounted or available to the target host when the RDF links are active.




RDF – SRDF/S (Synchronous) Setup Steps

# symrdf –g <src_dg> split –consistent RDF – Device Group split –consistent7

# symrdf –g <src_dg> establish –full“Establish” command, replicates tracks from the Source to the Target

8

# symrdf –g <src_dg> restore -full“Restore” command, replicate tracks from the Target to the Source

9

# symrdf suspend# symrdf resume

To suspend / resume the RDF link between the source and target

6

# symrdf –g <src_dg> queryTo check the status of a device group5

# symdg show <src_dg> Display the device group and all of it’s associated devices

4

# syminq# vxdisk list

Commands to gather physical device names on both the Source and Target hosts

1

# symdg –type RDF1 create <src_dg>

# symdg –type RDF2 create <trg_dg>SRDF Commands to create Source and Target

(Type RDF1 and RDF2) device groups 2

# symld –g <src_dg> add dev ###

# symld –g <trg_dg> add pd C#t#d#Adding devices to a specific device group 3

CommandExplanation

Steps one through six represent the command steps required to set up an SRDF/S (Synchronous) RDF session.

The split command (step seven) suspends the RDF link, enabling the R1 and R2 devices to become accessible from the source and target hosts. Notice the -consistent flag used with the symrdfsplit command. This is used to ensure that ALL the devices in the RDF device group are split at the same time, resulting in ALL the database application files maintaining a consistent and “recoverable”point-in-time copy on the target (R2) side.

The database, when active, needs to be put into a “hot backup” state when replicating the R1 to R2 tracks.

More on this in the next slide.




sql> alter <tablespace_name> end backup;

sql> alter database end backup; Will take the entire database out of online backup mode (note 2 below)

6

# symrdf –g <src_dg> split –consistent RDF split -consistent5

# symrdf –g <src_dg> querySRDF query to check for synchronization across the RDF link

4

sql> alter system archive log current;Will archive the current log file

ensuring the redo necessary for recovery

1

sql> alter <tablespace_name> begin backup;

sql> alter database begin backup; Will put the entire database in online

backup mode (note 1 below) 2

# symrdf –g <src_dg> establish –fullRDF source to target synchronization3

CommandExplanation

SRDF/S Setup Steps for Oracle Replication

Before any RDF replication activity can occur, the database should be placed into hot backup mode. From an Oracle DBA account with the proper privileges, run command set one and two (see slide). The “alter database begin and end backup” commands (Steps two and six) were introduced with Oracle release 9i.

Prior to version 9i, every tablespace name was required to place the database into hot backup. This was accomplished with a script, one for beginning the backup and one to end the backup.

Command sets three, four, and five are the RDF replication commands. Performing the consistent split (Step five) provides a “recoverable” point in time image on the R2 devices. With the RDF link split,the R2 volumes can be mounted to an alternate host. With a copy of the Oracle “Control” and parameter files on the target side, the replicated Oracle instance can be initiated.

It is important to understand the concept of “recoverable” vs. “restartable” database images. A recoverable database copy is a copy of the database in which transaction logs can be applied to the data files to roll forward the database content to a point in time after the copy was created. A restartable database is a copy of a running Oracle database created using EMC consistency technology without putting the database in hot backup mode.




SRDF/S Synchronous with TimeFinder/Clone

TimeFinder/Clone: point in time replica

Used for reporting

Used for testing

Used for development

Oracle (Clone) is “Up and Available”which represents a “point-in-time”copy

oradatavg

oraarchvg

Oracle isUp and

Available (R1)Oracle Not

Available (R2)

Clone

orasrcdg

oraarchdg

orasysvgoratrgdg

Production Host (1) Mount

Host

oradatadg

R2 Env.R1 Env.

R1 DMX R2 DMX

Source Target

The SRDF - R2 replicas are maintained to ensure that the production database can be recovered in the event of any disaster. A best practice is to maintain the RDF link between R1 and R2 at all times. Any transaction committed to the production database will be automatically replicated to the R2 volume, ensuring a database that is recoverable, up to and including the last committed transaction.

The TimeFinder/Clone set of volumes represent a point in time copy of the R2 devices. The end user now has a full point-in-time copy of the production database that can be used for decision support, testing, and application development.




AsynchronousSolutions such as SRDF/A

SynchronousRemote replication products such as SRDF/S

Zero Data Loss solution. Used to achieve a “Zero Data Loss” Recovery Point Objective (RPO)

Provides an extended distance restartable copy while ensuring no performance impact, when the RPO requirement does not demand a synchronous solution

Typically achieved with a disk-based or time-stamped / ordered write software product

SRDF/A Choices and Benefits for an Oracle Environment

Beginning with Solutions Enabler version 5.3 and Enginuity 5670, Symmetrix supports the SRDF/A or Asynchronous mode for RDF devices.

When Oracle hot backup is enabled, SRDF/A supports RDF replication, resulting in a point-in-time image on the target (R2) device that is “Recoverable”.

The SRDF/A session transfers data to the remote Symmetrix in pre-defined, timed cycles or delta sets, which eliminate the redundancy of same track changes being transferred over the link. SRDF/A provides a long-distance replication solution with minimal impact on performance.

This level of database application protection is intended for customers that require minimal host impact and a recoverable copy of the Oracle application on the R2 target site.




SRDF/A – “Asynchronous Architecture”

Source HostSide A

Target HostSide B

SRDF/ADevice Pair

ActiveSession

Source(R1)

Device

Target(R2)

Device

CycleN

CycleN-1

CycleN-1

CycleN-2

Capture New WriteCycle -(N)

Transmit to R2Cycle -(N-1)

Receive Writes on R2Cycle -(N-1)

Right Applied to R2Cycle -(N-2)

SRDF/A Delta Set Begins

SRDF/A Delta Set – “Checkpoint”

SRDF/A Delta Set

All commonly used database management systems are inherently dependent write consistent. For instance, a DBMS will not perform a log write, indicating that a transaction is complete, until it has received an acknowledgement from the storage subsystem that the log data pertaining to the transaction itself was completely written to disk. Symmetrix honors this logic by maintaining write-ordering within SRDF/A.

Dependent write consistency is achieved through the processing of ordered SRDF/A delta sets between the source (R1) and the target (R2). Dependent write consistency ensures that all writes to R2 are processed in sequential numbered sets to maintain a consistent copy of data between R1 and R2.




Source HostSide A

Target HostSide B

SRDF/ADevice Pair

ActiveSession

Source(R1)

Devices

Target(R2)

Devices

TargetClone

Devices

# sqlplus /nologSQL> connect /as sysdbaSQL> shutdown normalSQL> exit

# symrdf –g <xxxdga> checkpoint... Check-Point Passed

# symrdf –g <xxxdga> split

# sqlplus /nologSQL> connect /as sysdbaSQL> StartupSQL> exit

On the Target Host –1. Create and activate your clone

session.symclone –g <clone_session> create –precopysymclone –g <clone_session> activate

1. Mount the Clone device.2. Startup your Oracle Application.

SRDF/A Checkpoint Oracle Restart

This SRDF/A scenario creates a restartable Oracle point-in-time database on the target devices. The steps demonstrate EMC’s SRDF/A asynchronous application, creating a point-in-time Oracle restartable image.

A clone replica can be created off the R2 target devices. From the target host, the clone devices are mounted, giving end users a point-in-time database image. The clone devices now contain a consistent image—consistent as of the last SRDF/A Checkpoint timestamp.

From the source host, the database administrator can restart the SRDF/A asynchronous link. In the event of a disaster, resetting the SRDF/A link keeps the Oracle replication current and up-to-date.




EMC SRDF/A Oracle Solution

SRDF/A Device GroupData

Redo – ArchiveControl

Production

Recovery

= TimeFinder BCVOraData Group= SRDF/A Device Group

= TimeFinder BCVOraLog Group

1a1a

33

5

8b8b

9

266

44 8a

1b1b

Source HostTarget Host

These SRDF/A steps, performed in the correct order, help meet an Oracle extended replication requirement that reduces RPO from hours to minutes, provides a consistent, restartable Oracle environment on the target side, and improves bandwidth utilization.




Unlimited

Extended

-200KM

Max

Distance

LowSingle - HopSRDF/ARHoursFast

MediumAsynchronousSRDF/ASec/MinFast

HighSynchronousSRDF (Synchronous)Zero Data LostFast

BandwidthModeSolutionsRPORTO

1-200KM Sync 200KM -Unlimited High/LowMulti-HopSRDF/ARZero Data

ExposureFast

Advanced extended distance solutions with zero data exposure combination

EMC Remote Replication Product Positioning

When it comes to business continuity and remote mirroring, EMC offers many products to help meet both RTO (Recovery Time) and RPO (Recovery Point) business objectives.

If a customer running an Oracle 11g application cannot tolerate any data exposure, then SRDF/S is the solution that will support full synchronization from the source storage array to the target storage array.

EMC can also deliver solutions that combine SRDF with TimeFinder to create single and multi-hop environments for specialized business needs. This combination is referred to as SRDF/AR or Automated Replication.




Snapshot Consistency with “Enginuity Consistency Assist”(ECA)

Enables multiple volumes to be “snapped” as one logical unit

Ensures consistency across multiple volumes

I/O from host is temporarily held for all devices in the Symmetrix DMX

Dependent write ordering is maintained

Snapshots are activated

I/O resumes without application impact

Devices are consistent and restartable as a set

HostApplication

Consistent activation enables multiple volumes to be

snapped as “one,”ensuring consistency

OracleProduction Volumes

Oracle Snap

Volumes

Save Area

Here we are using ECA consistency to ensure a point-in-time image across multiple snap devices. It is imperative that the entire set of logical volumes be captured at the exact same time. One way to achieve this is to shut down, or totally quiesce, the Oracle database so no I/O occurs while you create the sessions. This is obviously a problem in today’s database environment, because of the 24/7 up-time requirements.

EMC has a solution to this problem called “Enginuity Consistency Assist”. When you create a set of snapshots and invoke Enginuity Consistency Assist, the Symmetrix aligns the I/Os of those devices, and halts all I/O to the host systems very briefly, while it creates the snapshot session. It then resumes normal operation without any application impact. This ensures write dependency across all devices within the snapshot session.




Consistent Split with PowerPath / ECA

PowerPath holds I/O during split- Read and write I/O

Executed from “Host” doing I/OAffects only one hostDoes not require independent access to a gatekeeper

symmir -instant –ppathsymmir -instant -rdb

Executed by any Symmetrix-attached host Multiple host supportRequires independent access to a gatekeeper

- Enginuity Consistent Assistsymclone activate -consistent

Host

STD

BCV Host

STD

Clone

Consistent splits can be implemented using either PowerPath connected devices or the ECA (Enginuity Consistency Assist) feature. ECA suspends the database device writes at the Symmetrix level rather than at the host level.

The TimeFinder/Clone -consistent flag creates an ECA point in time consistent image across all the devices within the TimeFinder clone device group, resulting in a restartable copy of an Oracle database within seconds, with no interruption to the production environment.




What is EMC Replication Manager?Software that simplifiesmanagement of disk-based replicas

Automates the creation, management, and usage of disk-based replicas for multiple purposes from the context of the application

Maps applications on the host to the underlying storage infrastructure

Enables storage managers to delegate replicationtasks to multiple human resources

Copy production database for test, development and

reporting

“Gold copy” of production

database for instant restore

Accelerate backup of production data without impacting

performance

Move copies of production

databases to lower cost storage

Replica #1 Replica #2

Replica #3 Replica #4

Replication Manager software can virtually eliminate backup windows and recover your data in minutes instead of hours to days when utilizing traditional methods. Replication Manager is designed to manage and automate snapshots and clones utilizing EMC’s Business Continuance technology.

The Replication Manager product can create point-in-time replicas of databases (such as Oracle) or file systems residing on supported storage arrays. Replicas can be stored on Symmetrix TimeFinder/Clones, Snapshots, or Mirror environments.

Replication Manager allows you to perform local and remote replications using TimeFinder, Symmetrix Remote Data Facility (SRDF).

These replicas can be mounted on other hosts and used for backup, reporting, or testing. Multiple replicas of the production data can exist at the same time. More importantly, replicas can be used for a disk-to-disk restore of critical production data. Restoring from disk is faster than restoring from tape.

With robust functionality options available in a single host-based product license, Replication Manager can grow with your business. The business can leverage the features and functionalities it needs for today, and take advantage of the advanced functionality it will need for tomorrow, without enduring costly product reinstallations.




Replication Manager Architecture

Replication Manager Agent

Mount host

TimeFinder family, SnapView, Celerra SnapSure iSCSI,

Invista clones, RecoverPoint CDP

RepositorySolid database

Replication Manager Server

Windows host

Replication Manager Console

Java

Replication Manager AgentProduct hosts:

Windows, UNIX, Linux, andVMware ESX Server

(both Windows and Linux guest OS)

R1R1

BCVBCV

BCVBCV

BCVBCV

R2R2

Oracle Production

HostOracle

Production Database11

22

33 22

Oracle Backup

Database

Replication Manager includes three different software components that work together to create replicas, mount replicas, restore replicas, and schedule replication and other tasks.

Shown here is an Oracle database environment within a typical Replication Manager architecture.

Replication Manager is made up of three major components:Replication Manager Server (1) consists of core software binaries, log files, and an embedded data repository containing configuration data that describes each replica created and the storage associated with that replica. The server component resides on the server host.Replication Manager Agent (2) consists of an interface to the applications, which is installed on each production host containing data that you want to replicate. Replication Manager includes different kinds of agents designed to create and manipulate replicas for each supported application such as Oracle or SQL Server.Replication Manager Console (3) consists of software that controls the Replication Manager system from any supported desktop machine or server.




RM Replication Options for Symmetrix Arrays

TimeFinder within Symmetrix array– TimeFinder/Clone– TimeFinder/Snap– TimeFinder/Mirror

Enginuity Consistency Assist (ECA)

Symmetrix Protected Restore

Supports –– Oracle Database Replication– SQL-Server Database Replication– Exchange Replication

Symmetrix-originating Replications

R1R1

BCVBCV

BCVBCV

BCVBCV

R2R2

Oracle Production Database

Oracle Backup

Database

Replication Manager supports the following replication technologies for Symmetrix environments: TimeFinder/Clone, TimeFinder/Snap, TimeFinder/Mirror, and San Copy.

Creating replicas within the frame or within the Symmetrix array, Replication Manager can create the following for production data:

TimeFinder/CloneTimeFinder/Clone (remote)TimeFinder/SnapTimeFinder/Snap (remote)TimeFinder/MirrorTimeFinder/Mirror (remote)

Replication Manager supports creating replicas outside the frame:Create replicas of production data on remote BCVs (from one Symmetrix array to another Symmetrix array) across a synchronous SRDF link.Create exact replicas of production data from a Symmetrix array to a CLARiiON array using EMC SAN Copy software.

EMC’s Replication Manager supports the creation of scheduled jobs. These jobs automate the replication process of database environments such as Oracle. A best practice is to create an Oracle Replication Job against a “Test” database environment. Then test the job to ensure its accuracy before placing the job into any production environment.




Course SummaryKey points covered in this course:

IT challenges and EMC solutions that best meet a set of business objectives EMC Consolidated Solution for an Oracle 11g databaseEMC replication solutions The planning and documentation process to set up an Oracle database environmentThe Oracle OFA compliant environmentThe advantage of spreading Oracle metavolumes across multiple back-end “Disk Directors”RAID configurations and their performance impact within an Oracle database environment An Oracle ASM environment and its integration with EMC’s TimeFinder applicationAn Oracle RAC and its integration with a DMX environmentOracle’s Flashback Technology and its integration with EMC’s TimeFinder applicationOracle offline and online backup scenario and its integration with EMC’s TimeFinder applicationTimeFinder Clone and Snap applications and their integration with an Oracle 11g applicationEMC’s SRDF/S and how it meets an “instant” RPO and an RTO of only a “few minutes”EMC SRDF/A replication solution for an Oracle database applicationEMC’s PowerPath and ECA Consistent Split technology EMC’s Replication Manager application within an Oracle 11g environment

These are the key points covered in this training. Please take a moment to review them.

This concludes the training. Please proceed to the Course Completion slide to take the assessment.

Symmetrix Integration w Oracle v52 - Srg

Documents

recoredo log

real application

sysdba sqlgt

replication

automatic

oracle 11g

database remains

automated