Oracle OpenWorld

San Francisco
September 1923, 2010

<Insert Picture Here>

S317131: Maximum Availability Architecture Best Practices: Oracle E-Business Suite R12.1 Ray Dutcher
PMTS, MAA Group Oracle Server Technologies

Lyn Pratt
CMTS, MAA Group Oracle Server Technologies

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracles products remains at the sole discretion of Oracle.

Agenda

<Insert Picture Here> Maximum Availability Architecture (MAA) E-Business Suite MAA E-Business Suite Disaster Recovery New Database Features and E-Business Suite

<Insert Picture Here>

Maximum Availability Architecture (MAA)

Maximum Availability Architecture (MAA)

Maximum Availability = Unbreakable Architecture + Best Practices Oracle's best practices blueprint based on proven Oracle high availability technologies and recommendations
Technology + Configuration + Operational Practices Applications, Enterprise Manager, Application Server, Collaboration Suite and Database Constantly validated and enhanced as new products and features become available Focused on reducing unplanned and planned downtime Focused on making our customers successful

Papers published to the Oracle Technology Network (OTN)

http://www.oracle.com/goto/maa

Presentation Focus

This presentation is on Oracle E-Business Suite Release 12.1 MAA with RDBMS 11.2
Please see the MAA home page for detailed papers covering Oracle E-Business Suite 11i and R12 MAA
http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html

<Insert Picture Here>

E-Business Suite MAA

E-Business Suite MAA Oracle Database MAA

E-Business Suite MAA Application HA Features

10

E-Business Suite MAA Target Architecture

11

E-Business Suite
MAA on Exadata
Primary Site Secondary Site

Application Tier

Oracle V2 Exadata Database Machine

Exadata DB Servers

Oracle V2 Exadata Database Machine

MAA Integration High Availability Scalability

Oracle Data Guard

Exadata Storage Servers

MAA Integration High Availability Scalability

12

E-Business Suite MAA Install and Transition, Sun Oracle Database Machine
Fresh Install
Standard Installation with Rapid Install Upgrade the database to 11.2.0.1 Using rconfig: convert database to RAC and move the database files to ASM Paper available soon

Migration (see Support Note 1133355.1)

Data Guard Physical Standby
11.1 (see Note 1055938.1 Case #2) or 11.2 Database 32-bit or 64-bit Windows, 32-bit or 64-bit Linux, Solaris x86-64

Transportable Database
same endian format same Oracle software version and patches installed

Oracle E-Business Suite Rapid Clone Data Pump

http://www.oracle.com/technetwork/database/features/availability/maa-ebs-dbm-datapump-167285.pdf

13

<Insert Picture Here>

E-Business Suite Disaster Recovery

14

E-Business Suite Disaster Recovery

How to set up and operate an E-Business Suite disaster recovery site Detailed papers for 11i and R12 are on the MAA Best Practices home page
http://www.oracle.com/technetwork/database/features/availability/maa-best-practices155366.html

Use the Rapid Clone process; see Support note 1070033.1, Business Continuity for Oracle E-Business Release 12 Using Oracle 11g Physical Standby Database
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070033.1

15

E-Business Suite Disaster Recovery Creating the Standby Site

16

E-Business Suite Disaster Recovery Creating the Standby Site Establish Standby Hardware and System Software
Install the standby site middle tier and database hardware, networks, etc. Think carefully about the performance and HA requirements - best to mimic production Plan also for all required external services Install System Software

Establish Oracle Clusterware

Required for ASM and RAC

Establish ASM

17

E-Business Suite Disaster Recovery Preparation on the Primary Prepare for Data Guard operation
Enable archive log mode Enable forced logging Create database password files Configure Oracle*NET communication between sites Set database parameters for Data Guard Create standby redo logs Add primary role-based service

See MAA paper:

Data Guard 11g Installation and Configuration Best Practices on Oracle RAC
http://www.oracle.com/technetwork/database/features/availability/dataguard11g-rac-maa-1-134639.pdf

18

E-Business Suite Disaster Recovery Clone and Configure Database Software

Run the E-Business Suite pre-clone utility on a primary database node Copy the database home to the standby database servers [RAC Only] Run adclonectx.pl on each standby database server
Adjust the context file for the appropriate settings to cluster_database_instances, instance_number, instance_thread, undotablespace

Run clone steps on each standby database server Configure standby database Data Guard parameters Configure Oracle*NET Communication on standby site [RAC Only] Restart the listeners

19

E-Business Suite Disaster Recovery Clone Application Tier To Standby Site

Run the pre-clone utility on a primary applications tier node Copy the software to the standby Run adcfgclone.pl on each standby middle tier server connecting to the primary database Update the connect string on each standby application tier to include the primary and standby database hosts (one-time autoconfig) [RAC Only] Edit the context file to point Tools OH TWO_TASK, iAS OH TWO_TASK, and Apps JDBC Connect Alias to the appropriate load balancing services (Optional) Establish log and out file synchronization
Use your favorite tool for this, for example rsync

20

E-Business Suite Disaster Recovery Create the Physical Standby Database

Establish the standby database
Use RMAN Network Duplicate to create the standby database OR Back up the production database including archive logs, and the production control file for standby Restore the database to the DR site using (one of) the configured instance(s)

Start managed recovery MAA papers for tuning best practices:

Active Data Guard 11g Best Practices (includes best practices for Redo Apply)
http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr1-activedataguard1-128199.pdf

Data Guard Redo Transport & Network Configuration

http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2dataguardnetworkbestpr-134557.pdf

[RAC Only] Register the standby database with Oracle Clusterware and create11.2 role-based service

21

E-Business Suite Disaster Recovery Operational Procedures - Switchover

Be sure you are up to date with redo apply
see Support Note 751600.1 for a procedural template

Shut down the app and all but one database instance on each site Execute the database switchover Remove the applications topology from the database
EXEC FND_CONC_CLONE.SETUP_CLEAN; commit;

Run AutoConfig on database tier (twice for RAC) then middle tiers to configure the application for DR operation Adjust the load balancer to the active application tier nodes Start the Apps

22

E-Business Suite Disaster Recovery Operational Procedures - Failover

Execute the database failover Remove the application topology from the database Run AutoConfig on database tier (twice for RAC) then on middle tiers to configure the application for the DR site Adjust the load balancer to the active application tier nodes Start the Apps Restore the original primary as a standby
Primary site becomes available - flashback the old primary database Primary site permanently lost re-create a new standby

23

E-Business Suite Disaster Recovery Operational Procedures Snapshot Standby

For testing, convert a standby to a Snapshot Standby
http://download.oracle.com/docs/cd/E11882_01/server.112/e10700/manage_ps.htm#BACIEJJI

Stop redo apply and shut down all but one RAC instance Ensure the database is mounted, but not open Requires the fast recovery area to be configured
It is not necessary for flashback database to be enabled

Convert to a snapshot standby:

SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

Activate the standby database and configure EBS

Take care with external interfaces such as Workflow - disable them before starting EBS

Perform testing at the standby site Convert the database back to a physical standby

24

E-Business Suite Disaster Recovery Automating Switchover and Failover Use the Data Guard Broker to automate Data Guard operations
Configure Data Guard Fast Start Failover
automatically detect a database failure automatically initiate failover

Create a script to automate role transitions

Database autoconfig configuration Adjusting the load balancer

Create a DB_ROLE_CHANGE trigger that will execute the script on switchover and failover Create a role-based service
25

<Insert Picture Here>

New Features and the E-Business Suite

26

New Database Features

Named Database Listener Coordinated recovery in an integrated architecture Active Data Guard for E-Business Suite reporting Roadmap: Edition-Based Redefinition

27

New Database Features

Named Database Listener

Same listener name on all RAC database nodes Autoconfig supports this as of:
11i - 9535311 12.0 R12.TXK.A.delta.7 [9386653] or higher 12.1 R12.TXK.B.delta 3 [8919489] or higher
<DB_LISTENER oa_var="s_db_listener">LISTENER_VISMIG</DB_LISTENER>

Add IFILE line to each database node listener.ora

Note: 11.2 RAC the listener.ora and tnsnames.ora in the Grid ORACLE_HOME should be used IFILE=<EBS DB ORACLE_HOME>/network/admin/<CONTEXT_NAME>/listener.ora

Do the same IFILE setup for tnsnames.ora

IFILE=<EBS DB ORACLE_HOME>/network/admin/<CONTEXT_NAME>/tnsnames.ora

Set TNS_ADMIN for the listener and database in OCR

srvctl setenv listener -l <listener_name> T TNS_ADMIN=<Grid HOME>/network/admin srvctl setenv database -d <db_name> -T TNS_ADMIN=<Grid HOME>/network/admin

28

E-Business Suite in an Integrated Architecture How do I handle disaster recovery?

29

Coordinated Recovery When do I need it?

Cloning multiple databases to create test systems, without taking them down Disaster recovery failover, where at least one database incurs incomplete recovery Incomplete recovery required due to logical corruption at primary site Where data loss is incurred, recover all databases to the oldest SCN of databases with data loss.

30

Coordinated Recovery Whats the procedure? Recover or halt all impacted databases Determine if a database has data loss Identify lowest SCN of databases with data loss. This is the target recovery SCN. Flash back all databases with SCNs greater than the target SCN, to the target SCN
Challenges:
Inactive / quiet database SCNs lag behind Any application that doesnt use 2PC/XA leaves a gap

31

Synchronizing the Farm Support Note 1096993.1

Solution: Lightweight heartbeat transaction executed at frequent intervals
Keep the SCNs in sync on all participating databases Keep the laggards active, without weighing down the active databases

32

E-Business Suite and Active Data Guard Further Utilizing Standby The basic challenge to offloading EBS reporting:
An Active Data Guard standby is read-only Logging into EBS, managing concurrent requests both require writes

The core of the solution:

New ADG database triggers to redirect minimal required read/write activity back to the primary FND layer to enable the solution Parallel Concurrent Processing to configure and manage the report executions

33

E-Business Suite and Active Data Guard Further Utilizing Standby The starting point:
Available as a patch on top of R12.1.3 Oracle Database 11.2 Only ReportWriter programs will be supported Reports must have been run previously on primary, and marked as runnable on standby

34

E-Business Suite MAA Roadmap the final piece of the HA jigsaw puzzle
High Availability Make planned changes to software Survive hardware failure

Change applications database objects

Change infrastructure: Operating system Oracle Database

Change objects meaning: patching and upgrading

Change objects physical characteristics

35

E-Business Suite MAA Roadmap Edition-based Redefinition 11.2 brings these revolutionary new features: the edition, the editioning view, and the crossedition trigger
Code changes are installed in the privacy of a new edition Data changes are made safely by writing only to new columns or new tables not seen by the old edition

An editioning view exposes a different projection of a table into each edition to allow each to see just its own columns
A crossedition trigger propagates data changes made by the old edition into the new editions columns, or (in hotrollover) vice-versa

36

References
MAA Best Practices home page
http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html

1133355.1 - Migrating an Oracle E-Business Suite Database to Sun Oracle Database Machine 1070033.1 - Business Continuity for Oracle E-Business Release 12 Using Oracle 11g Physical Standby Database

406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone

751600.1 - 10.2 Data Guard Physical Standby Switchover 380489.1 - Using Load-Balancers with Oracle E-Business Suite Release 12Load balancer configuration is vendor specific Deploying F5 With Oracle E-business Suite 12
http://www.f5.com/pdf/deployment-guides/f5-oracle-ebusiness-suite-dg.pdf

OpenWorld 2010 Session S316297 - Oracle Development Tips: Seamless Application Failover with Oracle Data Guard

37

Key HA Sessions, Labs, & Demos by Oracle Development

Monday, 20 Sep Moscone South * 3:30p Extreme Consolidation with RAC One Node, Rm 308 4:00p Edition-Based Redefinition, Hotel Nikko, Monterey I / II Wednesday, 22 Sep Moscone South * 11:30a RMAN Best Practices, Rm 103 11:30a Database & Exadata Smart Flash Cache, Rm 307 11:30a Configure Oracle Grid Infrastructure, Rm 308 1:00p Top HA Best Practices, Rm 103 1:00p Exadata Backup/Recovery Best Practices, Rm 103 4:45p GoldenGate Architecture, Hotel Nikko, Peninsula

5:00p Five Key HA Innovations, Rm 103 5:00p GoldenGate Strategy & Roadmap, Moscone West, Rm 3020
Tuesday, 21 Sep Moscone South * 11:00a App Failover with Data Guard, Rm 300 12:30p Oracle Data Centers & Oracle Secure Backup, Rm 300

2:00p ASM Cluster File System, Rm 308 2:00p Exadata: OLTP, Warehousing, Consolidation, Rm 103 3:30p Deep Dive into OLTP Table Compression, Rm 104 3:30p MAA for E-Business Suite R12.1, Moscone West, Rm 2020 5:00p Instant DR by Deploying on Amazon Cloud, Rm 300

Thursday, 23 Sep Moscone South * 10:30a Active Data Guard Under the Hood, Rm 103 1:30p Minimal Downtime Upgrades, Rm 306 3:00p DR for Database Machine, Rm 103

Demos Moscone West DEMOGrounds

Mon & Tue 9:45a - 5:30p; Wed 9:00a - 4:00p
Maximum Availability Architecture (MAA)

Hands-on Labs Marriott Marquis, Salon 10 / 11

Monday, Sep 20, 12:30 pm - 1:30 pm Oracle Active Data Guard Tuesday, Sep 21, 5:00 pm - 6:00 pm Oracle Active Data Guard * All session rooms are at Moscone South unless otherwise noted * After Oracle OpenWorld, visit http://www.oracle.com/goto/availability

Oracle Active Data Guard

Oracle Secure Backup Oracle Recovery Manager & Flashback Oracle GoldenGate Oracle Real Application Clusters Oracle Automatic Storage Management

38

For More Information

search.oracle.com
Maximum availability architecture

or oracle.com

39

40

41