Symmetrix Integration W Oracle v52 - SRG

Copyright 2009 EMC Corporation. Do not Copy - All Rights Reserved.
Symmetrix Integration with Oracle
2009 EMC Corporation. All rights reserved.
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.
Symmetrix Integration with Oracle - 1
Course Objectives
Upon 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 database Identify a list of EMC replication solutions Describe the planning and documentation process to set up an Oracle database environment Describe an Oracle OFA compliant environment Describe 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 EMCs TimeFinder application Describe an Oracle RAC (Real Application Clusters) and its integration with a DMX environment Describe Oracles Flashback Technology and its integration with EMCs TimeFinder application Describe an Oracle offline and online backup scenario and its integration with EMCs TimeFinder application Describe TimeFinder clone and snap applications and their integration with an Oracle 11g application Describe EMCs SRDF/S application and how it best meets an instant RPO and a RTO of minutes Describe EMC SRDF/A replication solution for an Oracle database application Describe EMCs PowerPath and ECA Consistent Split technology Describe EMCs 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
Growth
Complexity and cost growth directly with capacity Not flexible; difficult to change
IT Challenges
Performance
Impact on business processes Lost productivity and revenue opportunities Customer satisfaction tied to performance
Availability
Poor architecture and inefficient processes Information access is critical Information protection is costly
Business challenges create IT challenges

2009 EMC Corporation. All rights reserved. Symmetrix Integration with Oracle - 4
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
Upgrades and Migrations
Developing comprehensive project plans Ensuring on-time completion Achieving seamless transition
Performance
Meeting service levels Adding more users Adding more applications Finding and resolving bottlenecks
IT Resources and Budget

Increasing IT responsibilities Managing limited budget Expanding skill sets
EMC Solutions to help meet IT Challenges
Operations
Preparing for data and information growth Reducing availability threats Ensuring scalability of IT service delivery
Complex Technology Choices

Designing and deploying comprehensive solutions
EMC has solutions to meet both business and 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)
RPO
Business Needs Drive the Technology Choice
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

Oracle E-Business Suite Web PeopleSoft applications WAN SAP Custom JD Edwards applications
Backup
Backup
Characteristics
Islands of storage inaccessible by other servers and applications Individual backups on every server Low fault tolerance Multiple Oracle Database applications scattered throughout the enterprise Limited growth and scalability Low resource utilization
Issues
Remote replication and disaster recovery are too time-consuming, complex, and costly Time-consuming backup/restore Inadequate protection; excessive unplanned downtime Dispersed management is difficult and costly Unacceptable amount of planned downtime for operations such as increasing capacity and backup Limited flexibility, costly to scale, additional server overhead
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

Oracle E-Business Suite PeopleSoft Web applications SAP JD Edwards Custom applications
WAN
Backup
Backup
EMC Storage
EMC Storage
Features
Storage consolidation on EMC Consolidated backup and restore Robust fault-tolerant storage Server consolidation Centralized replication Improved scalability
Benefits
Improved storage utilization; reduced acquisition costs Improved mean time to recovery Increased information availability, reduced downtime Reduced management cost, increased flexibility Improved recovery point and recovery time for disaster recovery Reduced planned downtime
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.
Planning and Documenting the Oracle Environment

Oracle Environment Integration / Layout Project
Where do the Data Control Redo and Archive files reside? Document the following:
tati Documen on
Disk Groups IP Host Address Volume Groups Host Names Devices Groups Root logon passwords ASM Groups Oracle DBA Accounts info Clone Devices Oracle User Accounts info Snap Device Standard and BCV Devices RDF Configurations
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)

EMC
ESX 4.0 (Source Host)

Oracle 11g Binaries
ESX 4.0 (Target Host)

Oracle 11g Binaries
Target (R2) Backup Mount Host
Target Mount Points
Master (R1) Controlling Oracle 11g Host
A A
Oracle Data (A)
B B
RDF Data
TimeFinder/Clone Data Device Groups Oracle Data (C)
Source Mount Points
/vol1/db1 /vol2/db2 /vol3/db3 /vol4/Rd1 /vol5/Rd2 D
D
RDF Redo
D R R
/vol1/db1 /vol2/db2 /vol3/db3 /vol4/Rd1 /vol5/Rd2
R
RDF Arch
RM Sym Devices
/vol6/Ar1
A
RDF Flashback
A A
/vol6/Ar1
C C ERM 5.2 Server
/vol7/Fl1 F
F F
/vol7/Fl1
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 application Describe the benefits of auto-provisioning within an Oracle environment Identify 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: Oracles Optimal Flexible Architecture

Oracle 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 11g Release 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 EMCs technical architect should incorporate Oracles OFA (Oracle Flexible Architecture) standards. Using Oracles 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.
Symmetrix DMX Direct System Overview

RF
Dir 16 1 0 D Dir 1 0 C 8 1 0 B HA 1 0 A
Dir D 16 C B HA A
Global Cache
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
Processor / Instance
Port Symm Device Meta Vol
Global Cache
Dir D 15 C B HA A Dir D 2 C B HA A
RF
1 0 1 0 1 0 1 0
Dir 1 D Dir C 7 B A HA
Global Cache
RF
Dir D ( Direct Matrix ) 1 C B HA A
Global Cache
DMX Disk ID 1A01 0 1
Target Array
Its 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?
Symmetrix V-Max Virtual System Overview

1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
H D C G F HA Global Cache DA B Director 10 A E H RF G F HA E H G F HA E H RF G F HA E D C DA B Global Cache Director 9 A D C DA B Global Cache Director 8 A D C DA B Global Cache Director 7 A
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
Processor / Instance
Symm Device Meta Vol
RF
Port
V-Max Disk ID 7A01 0 1
Target Array
( Virtual Matrix )
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

Metavolume Hyper Volumes Split into 4 4.2GB each
Cache
0079 0069 0059
Front End System Adaptor
DMX Array
007A 006A 005A
007B
006B
005B
Back End Disk Directors

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
Previously: DMX
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
Easier to manage Fewer actions to commit Adds simplicity
Enginuity 5874: Auto-provisioning 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
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 todays 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-Provisioning
Symmetrix V-Max System
Fabric-A Fabric-A
0 1
8B 7B 8A 7A
Host-A
0 1
Fabric-B Fabric-B
0 1
0 1
Host-B
Initiator Group Port Group Storage Group
Masking View
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; and Symmetrix 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 / Benefits

All 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 EMCs 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.
Oracle with EFD Technology

With the introduction of the DMX-4 running Enginuity 5773, EMC supports enterprise class flash drives also known as EFD drives
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 missioncritical 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 EFDs
Indexes Lookup tables High transaction rate tables/indexes or their more current partitions
Database components not recommended for EFDs drives

Redo 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 EMCs and Oracles 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

Allowed
RAID 5
RAID 5 (7+1) on data devices TDEVs bound to RAID 5 pool
TimeFinder/Snap SRDF
(Thin Devices)
Thin Devices
Enginuity 5773 from To Enginuity 5874
DSE on TDEVs
Prohibited
Thin to non-thin replication
TimeFinder/Emulation TimeFinder/Snap TimeFinder/Clone SRDF
TDEVs as R11, R21, or R22 Multi-virtual Snap

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 devicesno 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
7200 RPM
7200 RPM
Tier 3 Tier 2
10K RPM 10K RPM
Engine 6 Engine 5 Engine 4 Engine 3
Flash Flash Tier 0 Tier 1

15K RPM
Flash Flash
15K RPM
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.
The New SRDF Device Migration Feature

symrdf migrate symrdf migrate
Current and new Challenges

Migrate an application to a new Symmetrix array Solutions Enabler and Symmetrix Management Console symrdf migrate Replace R1 or R2 device Create new RDF pairs Plan to modify existing scripts RDF group attributes will not be migrated Consistency exempt devices can be migrated Consistency exempt state will not be transferred Select existing RDF pair and new device FBA and CKD
R1 R1
R2 R2
Adaptive Copy Disk R1 R1 The New Array
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 symrdf commands 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 symrdf migrated 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 newlypopulated 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 1
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) group No separate parity drive, parity blocks rotate among the group members
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
Host Writes
Block 00 Block Block 11 Block Block 22 Block Block 33 Block
SP Front End Write Cache Write Cache Back End
Raid Group
Block 0 Block 1 Block 2 Block 3 Block 0 Block 1 Block 2 Block 3
Note RAID 1 requires a minimum of 2 drives to implement

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

Block 00 Block Block 11 Block Block 22 Block Block 33 Block
Host Writes
SP Front End Write Cache Write Cache Back End
Raid Group
Block 11 Block 11 Stripe 00 Stripe Stripe 22 Stripe Block 0 Block 3 Block 6 Parity Block 1 Block 4 Parity Block 9 Block 2 Parity Block 7 Block 10 Parity Block 5 Block 8 Block 11
Stripe 11 Stripe Stripe 33 Stripe
Note RAID 5 requires a minimum of 3 drives to implement

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 balanced
Front-end ports and back-end adaptors and disks are evenly loaded
Using RAID 5 / 3+1 or 7+1 configuration

7+1 can perform twice as many reads as a 3+1 Write 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 EMCs 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 Striping Consideration for Performance

Mirror Disks
Tablespace 1 System Tablespace 2 Undo Segments Tablespace 3 Temp Tablespace 4 Data
Primary Disks
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, tablespace placement 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 tablespace on the same spindle as the Temp tablespace. Other considerations come into play that may be specific across different RDBMS applications.
Database Redo Log Layout

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
Outer Hypervolumes for Redo Logs 0 4 hyper 4 hyper 0
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

Volume Management Control
PowerPath Oracle Sys Tablespace Ora_Sys_Vg Production Host
PathSet_1 PathSet_1
PathSet_2 PathSet_2
Ora_Data_Vg Oracle Data Oracle Instance Tablespace
PathSet_3 PathSet_3
RedoVg
Oracle 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
Standards System Device Group Clone
Ora_Sys_Vg
Source Host
Ora_Data_Vg
Oracle Instance
RedoVg
Redo Device Group
Once the clone session is activated Clone devices can be mounted to a secondary Host Can be used for reporting / development / or testing Can be used to create point in time backups to tape or disk
Oracle Point in time Instance
Target Host
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 Archive RAID 1 Symmetrix Storage Array
Oracle 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.
Best Practices
Best performance when all subsystems are evenly balanced Use RAID 1 or RAID 5 configurations Use striped metavolumes or concatenated metavolumes Placing 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
Reference:
Engineering White Paper Oracle Database Layout on Symmetrix DMX Oracle Database on EMC Symmetrix Storage Systems Solutions Guide
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 Oracles Flashback Technology and its integration with EMCs TimeFinder application
The Oracle Instance

SMON SMON PMON PMON RECO RECO
SGA
Data Buffer Cache
The Oracle Instance
Shared Pool
Library Cache Data Dictionary Cache
Redo Log Buffer
DBW0 DBW0
CKPT CKPT
LGWR LGWR
ARC0 ARC0
The Database
Data Files
Control Files
Redo Files
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.
Oracle Memory Structures

SMON
Data Buffer Cache
PMON
SGA
Shared Pool
Library Cache Data Dic Cache
RECO
Redo Log Buffer
DBW0
CKPT
LGWR
Control Files
ARC0
Redo Files
Data Files
Memory Structures for the Instance Data Buffer Cache Shared Pool - Library Cache The SGA - Data Dictionary Redo Log Buffer
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.
Oracle System Processes
SMON SMON
Data Buffer Cache
PMON PMON
SGA
Shared Pool
RECO RECO
Redo Log Buffer
DBW0
CKPT
LGWR
Control Files
ARC0
Redo Files
Data Files
SMON PMON RECO
- The System Monitor - The Process Monitor - The Recover Process
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 (MultiSystem) 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.
Oracle Processes
SMON
Data Buffer Cache
PMON
SGA
Shared Pool
RECO
Redo Log Buffer
DBW0 DBW0
CKPT CKPT
LGWR LGWR
Control Files
ARC0 ARC0
Redo Files
Data Files
Oracle Processes DBW0 CKPT LGWR ARC0 - Database Writer Process - Checkpoint Process - Log Writer Process - Archive Process
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: Oracles 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 Oracle ASM Disk Group
The Oracle Database Kernel The ASM File System The ASM File System
Oracle database files are spread across the ASM disk group
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.
Oracle RAC (Real Application Clusters)

Also referred to as Oracle Grid
Users
The Network The RAC Application Cluster Pool
Oracle RAC Memory and System Processes The Storage Network
The Database
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 databasethe 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.
Oracle RAC Interconnects
Users The Network
1 1
The Computer System Layer
2 2
The Application Server Layer
Oracle Clusterware Services Oracle Cluster File System (OCFS)
3 3
The Database Server Layer
4 4
The Storage Layer The Database
Oracle ASM Disk Groups

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 Oracles ASM application is recommended to help control volume utilization within a RAC cluster environment.
Oracle RAC Shared Everything

User
In Memory / Data Buffer Cache
A A
User C C The Network
The RAC Application Cluster Pool A A C C

Shared Cache
Oracle RAC Memory and System Processes The Storage Network
The Database
Oracle RAC ensures that any data that has been modified becomes the most current to all the RAC users. Lets 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 Cs 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.
Oracle RAC / Storage Solution

Users
The Network The RAC Application Cluster Pool

Shared Cache
Oracle RAC Memory and System Processes
ASM DG1 Data

ASM DG2 Redo The Database
ASM DG3 Archive

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.
Oracle RAC / Storage Solution
S.A.M.E. Stripe and Mirror Everything

D D D D D D P D P DD P DP P D D D D D D DD D D D P
ASM DG1 Data Raid 5
ASM DG2 Redo Raid 1
ASM DG3 Archive Raid 1
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.
Oracle RAC / Storage Solution (Cont)

Global Solutions Oracle 11g RAC Case Study Configuration 2 2 1 1 1 Dell 6850 Clients 1 2 Dell 2950 RAC Servers 2 3 Symm DMX 3 4500 3 Data /Raid 5 Redo / Raid 1 Archive / Raid 1 3 ASM Disk Groups Data Redo Archive 3 3
EMC Symmetrix DMX3 4500 Cisco 35686 LAN Switch Oracle 11g RAC Servers Brocade 4900 SAN Switch
Clients (6)
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.
Oracle 11g Flashback Technology (Cont)

Oracle Production Host
The Oracle The Oracle Instance Instance

T1 T2
Data
At timestamp T2 the test_table was accidentally dropped

Table Dropped
Flashback
T3
Recovery Area
At timestamp T3 the table test_table was Flashbacked or recovered.
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 Oracles 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;
Oracle Source Host

The Oracle Instance (Prod) The Oracle Instance (Prod)
Std01 Std02
SQL> flashback table inventory to before drop;

Dropped
Std03 Std04
Control
Data
Redo
Arch
Flashback Enabled
1 after the drop table command 1
Contents of the Recycle Bin
Recovered
Customer Inventory Tables Flashback Recycle bin

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 EMCs TimeFinder application Describe an Oracle ASM / RAC and Flashback integration with EMCs TimeFinder application Describe TimeFinder clone and snap applications and their integration with an Oracle 11g application environment Describe EMCs SRDF/S and how it best meets an instant RPO and a RTO of only a few minutes Describe EMC SRDF/A solution for an Oracle database application Describe EMCs PowerPath and ECA Consistent Split technology Describe EMCs Replication Manager application within an Oracle 11g environment
EMC Solutions
TimeFinder Clone TimeFinder Snap TimeFinder Mirror (Note 1)
STD STD STD Snap Clone copy used to create a point in time copy Snap: disk saving point in time copy
STD BCV
Clone Emulation with 5874 /SE 7.0
Local Remote
BCV mirror copy can be mounted to the Target host
SRDF Synchronous
Source will always equal Target
SRDF/A Asynchronous
Remote Target database is restartable

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
Backup Host
Source Host
Standards BCVs
oratrgdg
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 backup The database remains open or online Extra archived log files during the backup Additional archived logs can be applied to update the database Why Hot Backup?
A recoverable copy of the database is required Zero business down time
Source Host
Backup Host
Standards System oratrgdg Data BCVs
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 Oracle Database Kernel
The ASM File System The ASM File System

Source Host
The Oracle database files spread across the ASM disk group EMCs TimeFinder Device Group
DEV01 DEV01
DEV02 DEV02
DEV03 DEV03
ASM Disk Group
BCV01 BCV01
BCV02 BCV02
BCV03 BCV03
Can be used for Disk-based backup Database replicas Decision support Problem resolution
Target Host
EMCs 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. Whats 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.
Oracle RAC / EMC Integration
TimeFinder Device Group
Standard Devices ASM DG1 Data ASM DG2 Redo ASM DG3 Archive
The Production Database TimeFinder / BCV Devices
TimeFinder Point In Time Copy
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.
Oracle Flashback: Integration with EMC TimeFinder/Mirror

1. 2. 3. 4. 5. 6. 7. 8. 9. Shutdown the Target database Un-Mount the target file system Put the production database in backup mode Flush the source redo Establish (TimeFinder) Source to Target Split (-Consistent) the device group End backup mode Mount the target file system Startup the target database
1 BCV01 BCV02 BCV03 BCV04
Oracle Source Host

The Oracle Instance (Production) The Oracle Instance (Production)
Std01 Std02 Std03 Std04
Control
Data
Redo
Arch
Flashback Enabled
Control
Data
Redo
Arch The Oracle Instance (Backup) The Oracle Instance (Backup)
Flashback Enabled TimeFinder Device Group flash_dg

Oracle Target Host

This scenario represents an Oracle Flashback environment integrated with EMCs TimeFinder application. 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.
Oracle Flashback: Integration with EMC TimeFinder/Mirror
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
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 / SRDF Replication Concepts

TimeFinder
Symm
Mirror Copy
Source Device Target Device Backup or Target Host
Production or Source Host
SRDF
Symm 1
Symm 2
RDF Link
Source Device Production or Source Host
Target Device Backup or Target Host

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.
EMC TimeFinder Integration / OFA

The Source Oracle Instance The Source Oracle Instance
/u01/app/oracle/product/10.1.1
= TimeFinder Device Groups
Production
/u02/data1
Dev# ora_sys_vg
ora_sys_dg
ora_sys_vg
/u03/data2
ora_data1_vg
ora_data1_vg
ora_data_dg
/u04/redo ora_data2_vg ora_data2_vg
ora_redo_dg
ora_redo_vg ora_redo_vg
Backup
The Target Oracle Instance The Target Oracle Instance

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.
SRDF TimeFinder Clone / Snap Environment

Clone Copy Production Host (1) R1 DMX orasysvg orasrcdg R1 Env. oradatavg oradatadg oraarchvg oraarchdg oratrgdg R2 Env. Target Host (2) R2 DMX Mount Host (3)
Clone Snap Host Snap Session
= Veritas Volume Groups = SRDF Device Groups = TimeFinder Clone Mounted to the third Host (Clone/Snap Host) = TimeFinder Snap Session Mounted to the third Host
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
Controlling Host Target Host Source Source Dev001 Dev001 symclone command set
TimeFinder/Clone is an instant point-in-time copy of a Symmetrix standard device or a TimeFinder BCV
Target Target Dev005 Dev005
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

The Point-In-Time is established - When the Clone Session is Activated
Production Host Write to Track Source Device Clone Device Backup Host Original Track
Oracle 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
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

Step
1 2 3 4 5 6
Explanation
Create a Clone device pair file. Create a clone session Perform a query on the clone session. Activate the clone session
Command
Use an editor to create this file. # symclone sid <remote_sid> create file <file> -precopy diff # symclone sid <remote_sid> create file <file> # symclone sid <remote_sid> file <file> activate -consistent
On the target host, import the disk # vxdg import <dg_name> (Veritas) group. On the target host start the Oracle instance. Re-Create the clone session. Re-Establish a new point in time clone session.
% sqlplus /nolog sql> connect / as sysdba sql> startup pfile = <$ORACLE_HOME/...>
Shut down the Oracle application (target). Deport the Veritas dg # vxdg deport <dg_name> # symclone sid <remote_sid> file <file> recreate # symclone sid <remote_sid> file <file> activate consistent
Activate the new clone session
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 I/O Standard Dev Device Target Virtual Dev Device Pointers from Virtual to Original Data
Controlling Host I/O
Target Host Pointers to Sav Devs

Sav Dev
Original Data Copied to Sav-Devs CopyOnFirstWrite
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-intime database snaps. TimeFinder/Snap is best for an Oracle environment that requires multiple pointin-time images against a database environment that has minimal track changes.
Point-In-Time Snaps
Oracle Point in time 3:00 pm
Host A Source Device Group(1) Ora_300 Std# DEV## Controlling Host Source VDEV VDEV## Host B Target VDEV VDEV##
DEFAULT_POOL
Oracle Point in time 6:00 pm
Device Group(2) Ora_600 Std# DEV## Device Group(3) Ora_900 Std# DEV##
Ora_600_POOL
Oracle Point in time 9:00 pm Host C Target VDEV VDEV##

Ora_900_POOL
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.
Activating an Oracle Hot Backup Environment for an Active Snap Point in Time Copy Session
1. 2. 3. 4. 5. 6. 7. 8. 9. Create a Copy session that includes all the Oracle Data files Create a second Copy session that include archive redo logs and a backup of the control file Enable Archive Log Mode Place all Tablespaces (those that you want to backup) into Hot Backup Mode Activate Snap session for the Data File Copy Take all the Tablespaces out of Hot Backup Mode Archive the current online redo log Save a copy of the backup control file Activate the archive log copy session, which makes a point-in-time image of the archive redo log and the backup control file available
Ref Notes for Snap / Oracle SQL command lines.
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
Production Host(1) R1 DMX orasysvg orasrcdg R1 Env. oradatavg oradatadg oraarchvg oraarchdg oratrgdg R2 Env. Target Host(2) R2 DMX
RPO recovery point is instant RTO recovery time may be only a few minutes Production transaction committed only when the target acknowledges the transaction
SRDF/S (Synchronous) is used when the configuration requires that the source and target must be equal at all times. When a customers 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
Production Host(1) R1 DMX orasysvg orasrcdg R1 Env. oradatavg oradatadg oraarchvg oraarchdg oratrgdg R2 Env. Target Host(2) R2 DMX
Add your devices to the device groups R1 synchronized with R2 Production Oracle Available Target Oracle Not Available
Oracle is Up and Available

Oracle Not Available
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

Explanation
1 2 3 4 Commands to gather physical device names on both the Source and Target hosts SRDF Commands to create Source and Target (Type RDF1 and RDF2) device groups Adding devices to a specific device group Display the device group and all of its associated devices To check the status of a device group To suspend / resume the RDF link between the source and target RDF Device Group split consistent
# syminq # vxdisk list # symdg type RDF1 create <src_dg> # symdg type RDF2 create <trg_dg> # symld g <src_dg> add dev ### # symld g <trg_dg> add pd C#t#d# # symdg show <src_dg>
Command
5 6 7 8 9
# symrdf g <src_dg> query # symrdf suspend # symrdf resume # symrdf g <src_dg> split consistent
Establish command, replicates tracks from # symrdf g <src_dg> establish full the Source to the Target Restore command, replicate tracks from the # symrdf g <src_dg> restore -full Target to the Source
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 symrdf split 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.
SRDF/S Setup Steps for Oracle Replication

Explanation
1
Command
Will archive the current log file sql> alter system archive log current; ensuring the redo necessary for recovery Will put the entire database in online sql> alter <tablespace_name> begin backup; sql> alter database begin backup; backup mode (note 1 below) RDF source to target synchronization # symrdf g <src_dg> establish full SRDF query to check for # symrdf g <src_dg> query synchronization across the RDF link RDF split -consistent
# symrdf g <src_dg> split consistent
3 4 5
Will take the entire database out of sql> alter <tablespace_name> end backup; online backup mode (note 2 below) sql> alter database end backup;
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
Target
Source
Production Host (1) R1 DMX orasysvg orasrcdg R1 Env. oradatavg oradatadg oraarchvg oraarchdg oratrgdg R2 Env. R2 DMX
Mount Host Clone
Used for reporting Used for testing Used for development Oracle (Clone) is Up and Available which represents a point-in-time copy
Oracle is Up and Available (R1)
Oracle Not Available (R2)
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.
SRDF/A Choices and Benefits for an Oracle Environment
Synchronous
Remote 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 diskbased or time-stamped / ordered write software product
Asynchronous
Solutions such as SRDF/A
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
SRDF/A Delta Set Begins

Source (R1) Device
SRDF/A Delta Set
Cycle N
Capture New Write Cycle -(N)
Cycle N-1
Transmit to R2 Cycle -(N-1)
Source Host Side A
SRDF/A Device Pair Active Session Target (R2) Device
Cycle N-2
Cycle N-1
Target Host Side B
Right Applied to R2 Receive Writes on R2 Cycle -(N-1) Cycle -(N-2) SRDF/A Delta Set Checkpoint
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 writeordering 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.
SRDF/A Checkpoint Oracle Restart
# sqlplus /nolog SQL> connect /as sysdba SQL> shutdown normal SQL> exit # symrdf g <xxxdga> checkpoint ... Check-Point Passed # symrdf g <xxxdga> split # sqlplus /nolog SQL> connect /as sysdba SQL> Startup SQL> exit
Source (R1) Devices SRDF/A Device Pair Active Session Target (R2) Devices
Source Host Side A
Target Host Side B
On the Target Host 1. Create and activate your clone session. symclone g <clone_session> create precopy symclone g <clone_session> activate 1. Mount the Clone device. 2. Startup your Oracle Application.
Target Clone Devices
This SRDF/A scenario creates a restartable Oracle point-in-time database on the target devices. The steps demonstrate EMCs 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 imageconsistent 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

44 8a SRDF/A Device Group
Data
33 66 1a 1a
Redo Archive Control Production

1b 1b 5
Source Host Target Host

= SRDF/A Device Group = TimeFinder BCVOraData Group = TimeFinder BCVOraLog Group
8b 8b
Recovery
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.
EMC Remote Replication Product Positioning
RTO Fast Fast Fast
RPO Zero Data Lost Sec/Min Hours
Solutions
Mode
Max Distance -200KM Extended Unlimited
Bandwidth High Medium Low
SRDF Synchronous (Synchronous) SRDF/A Asynchronous SRDF/AR Single - Hop
Advanced extended distance solutions with zero data exposure combination Fast Zero Data Exposure SRDF/AR Multi-Hop 1-200KM Sync 200KM -Unlimited High/Low
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) Oracle

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
Production Volumes
Host Application Oracle Snap Volumes
Consistent activation enables multiple volumes to be snapped as one, ensuring consistency
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 todays 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

symmir -instant ppath symmir -instant -rdb
- Enginuity Consistent Assist

symclone activate -consistent
STD
STD
Host
BCV
Host
Clone
PowerPath holds I/O during split - Read and write I/O Executed from Host doing I/O Affects only one host Does not require independent access to a gatekeeper
Executed by any Symmetrix-attached host Multiple host support Requires independent access to a gatekeeper
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 simplifies management 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 replication tasks to multiple human resources
Gold copy of production database for instant restore Replica #1
Accelerate backup of production data without impacting performance Replica #2
Copy production database for test, development and reporting Replica #3
Move copies of production databases to lower cost storage 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 EMCs 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 Console
Java
Replication Manager Agent

Mount host
33
22
11
Oracle Production Host
22
TimeFinder family, SnapView, Celerra SnapSure iSCSI, Invista clones, RecoverPoint CDP
Oracle Production Database
Oracle Backup Database
R1 R1
Replication Manager Server
Windows host
R2 R2 BCV BCV
Replication Manager Agent

Product hosts: Windows, UNIX, Linux, and VMware ESX Server (both Windows and Linux guest OS)
BCV BCV BCV BCV
Repository
Solid 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

Symmetrix-originating Replications
TimeFinder within Symmetrix array

TimeFinder/Clone TimeFinder/Snap TimeFinder/Mirror
Oracle Production Database Oracle Backup Database
Enginuity Consistency Assist (ECA) Symmetrix Protected Restore Supports

Oracle Database Replication SQL-Server Database Replication Exchange Replication
R1 R1 BCV BCV BCV BCV
R2 R2 BCV BCV
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/Clone TimeFinder/Clone (remote) TimeFinder/Snap TimeFinder/Snap (remote) TimeFinder/Mirror TimeFinder/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. EMCs 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 Summary
Key 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 database EMC replication solutions The planning and documentation process to set up an Oracle database environment The Oracle OFA compliant environment The 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 EMCs TimeFinder application An Oracle RAC and its integration with a DMX environment Oracles Flashback Technology and its integration with EMCs TimeFinder application Oracle offline and online backup scenario and its integration with EMCs TimeFinder application TimeFinder Clone and Snap applications and their integration with an Oracle 11g application EMCs 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 application EMCs PowerPath and ECA Consistent Split technology EMCs 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

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Symmetrix Integration W Oracle v52 - SRG

Загружено:

Авторское право:

Доступные форматы

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

Symmetrix Integration with Oracle

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 1

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

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 2

Symmetrix Integration with Oracle - 2

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

Information Technologies / Business Challenges

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 3

Symmetrix Integration with Oracle - 3

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

Business challenges create IT challenges

Symmetrix Integration with Oracle - 4

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

IT Resources and Budget

EMC Solutions to help meet IT Challenges

Complex Technology Choices

EMC has solutions to meet both business and IT challenges

Symmetrix Integration with Oracle - 5

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

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

Business Needs Drive the Technology Choice

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 6

Symmetrix Integration with Oracle - 6

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

Before: Every Server a Management Headache

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 7

Symmetrix Integration with Oracle - 7

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

After: Efficient Utilization, Recovery, and Management

Symmetrix Integration with Oracle - 8

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

Planning and Documenting the Oracle Environment

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 9

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

Planning and Documenting the Oracle Environment (Cont)

ESX 4.0 (Source Host)

ESX 4.0 (Target Host)

Target (R2) Backup Mount Host

Target Mount Points

Master (R1) Controlling Oracle 11g Host

TimeFinder/Clone Data Device Groups Oracle Data (C)

Source Mount Points

/vol1/db1 /vol2/db2 /vol3/db3 /vol4/Rd1 /vol5/Rd2 D

/vol1/db1 /vol2/db2 /vol3/db3 /vol4/Rd1 /vol5/Rd2

C C ERM 5.2 Server

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 10

Symmetrix Integration with Oracle - 10

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

Symmetrix Integration with Oracle - 11

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

OFA: Oracles Optimal Flexible Architecture

From /u01: create an app (application directory)

2009 EMC Corporation. All rights reserved.

Symmetrix Integration with Oracle - 12