Oracle Maximum Availability Architecture Best Practices for Oracle Multitenant

Oracle Maximum Availability Architecture Best Practices for Oracle Multitenant Joseph Meeks, Oracle Frank Kobylanski, Oracle Kalyan Kallepally, Wellcome Trust Sanger Institute

Program Agenda High Availability and Oracle Multitenant Migration Strategies Managing Resources Unplanned Outages and Planned Maintenance Wellcome Trust Sanger Institute 2

The Promise of Multitenant The Better Approach to Database Consolidation Best system utilization Most efficient management Greatest cost savings 3

Oracle Database Architecture Requires Memory, Processes and Database Files System Resources 4

New Multitenant Architecture Memory and Processes Required at Multitenant Container Level Only System Resources 5

New Multitenant Architecture Memory and Processes Required at Multitenant Container Level Only System Resources 6

Multitenant vs Separate Databases Highly Efficient: 6x Less H/W Resource, 5x more Scalable OLTP benchmark comparison Only 3GB of memory vs. 20GB memory used for 50 databases Oracle Multitenant pluggable databases scaled to over 250 while separate database instances maxed at 50 7

Consolidation from an HA Perspective High Availability is Even More Important in a Consolidated Environment CRM HCM DW ERP BI 8

Oracle Maximum Availability Architecture Production Site RAC Scalability Server HA Flashback Human error correction Enterprise Manager Cloud Control Coordinated Site Failover Application Continuity Application HA Global Data Services Service Failover / Load Balancing Active Replica Active Data Guard Data Protection, DR Query Offload GoldenGate Active-active Heterogeneous Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate Minimal downtime maintenance, upgrades, migrations RMAN, Oracle Secure Backup Backup to disk, tape or cloud 9

Single Tenant CDB with a PDB Services Server CDB CDB Instance Unplug/Plug Ready Future platform migration Patching Oracle versions Future consolidation Completely compatible with non-cdb No functional difference Same performance No extra license cost 10

Oracle RAC Best for consolidation when used with Oracle Multitenant Single SGA and single set of background processes per CDB instance More efficient, more scalable Resource Manager prevents contention Between different user groups and PDB s competing for resources 11

Oracle Recovery Manager RMAN backup and restore CDB or PDB Tablespaces and datafiles within PDB Point-in-time recovery at PDB level 12

Active Data Guard Non CDB Oracle Multitenant VS nprimaries nstandbys One Data Guard standby database One Broker/Enterprise Manager configuration One failover/switchover command 13

GoldenGate Granular replication at the level of a PDB Consolidate, migrate and maintain Oracle or cross-platform Bi-directional replication enables phased user migration and zero downtime Non- Oracle ERP Oracle 11.2 CRM Oracle 10.2 DW 14

Multitenant Consolidation Strategy Step 1 Step 2 Step 3 Consolidate test and development databases Group production databases by HA service level Consolidate production databases with like service levels 15

Oracle MAA Availability Tiers Availability Service Levels for Unplanned and Planned Outages PLATINUM GOLD SILVER BRONZE Zero Outage for Platinum Ready Applications Zero data loss Comprehensive HA and Disaster Protection Zero or Near-zero data loss High Availability (HA) Data protected as of last backup Single Instance Database Data protected as of last backup 16

Migration Strategies 17

Adopting Oracle Multitenant How Do I Migrate a Traditional Oracle Database to a CDB? Non-CDBs 11g 01001011001001001 00101110010010101 00100101010100110 10100101010010010 0 Data Pump TTS Non-CDBs of version 11.2.0.4 or earlier. Ideal for direct migration of departmental databases Downtime is a function of the number of database objects CDB 12c 11g 12c 01001011001001001 00101110010010101 00100101010100110 10100101010010010 0 01001011001001001 00101110010010101 00100101010100110 10100101010010010 0 GoldenGate Plug as a PDB Least downtime Heterogeneous platforms Non-CDBs of version DB 12.1 or later. Faster than Data Pump, simpler than GoldenGate PDBs 18

Data Pump and TTS Ideal for Migrating Departmental Databases to Oracle Database 12c Change version and architecture in one step Data Pump/TTS tradeoffs Big bang approach changes version and architecture in one step Scripted incremental TTS (My Oracle Support 1389592.1) May have additional clean up steps after import Additional manual steps if there is a Data Guard standby and using ASM 19

Upgrade First, then Plug in as PDB Simplest way to Minimize Downtime when Migrating to PDB Incremental change is a more conservative approach Full database migration vs selected tablespaces Benefit from Oracle 12c RMAN enhancements available for PDB migration RMAN Active Database Duplication minimal downtime with greatest simplicity Backups and incrementals are taken while source is open read-write No staging area required for backups or incrementals RMAN Cross Endian TTS simplifies cross-platform migration Backups and incrementals are taken while source is open read-write All operations are self-contained within RMAN, no external scripts required 20

For Non-CDBs Already at Oracle Database 12c Options for Migrating to Oracle Multitenant Migrate In Place Process: source set read-only, create manifest, plug in using existing files, run PDB conversion script Source files have been modified, fallback requires recovery No incremental apply required reduces total downtime Space efficient, no copy required Copy Files Then Plug In Process: copy files, source set read-only, create manifest, apply final incremental, plug in using new files, run PDB conversion script Source files unchanged easy fallback Slightly more downtime due to final incremental apply Requires additional storage until original source database is dropped 21

My Oracle Support (Note 1576755.1) Detailed Migration Steps for Various Use-Cases Direct migration from Oracle 11.2.0.3 to PDB using Data Pump/TTS Migration from Oracle Database 12c non-cdb to PDB using RMAN Active Database Duplication Migrating a PDB from one container to another using RMAN Active Database Duplication Additional examples will be added over time 22

Migration Example: from Oracle Database 11g Upgrade to Oracle Database 12c then Plug In 1 2 3 4 5 6 Upgrade to Oracle Database 12.1 in place Choose/create a target CDB RMAN Active Database Duplication to duplicate files to target CDB system Iterations of RECOVER DATABASE FROM SERVICE until ready to migrate Place the non-cdb into read-only mode Generate a description file (manifest) on the non-cdb 23

Migration Example: from Oracle Database 11g Upgrade to Oracle Database 12c then Plug In X 7 8 9 10 Perform final RECOVER DATABASE FROM SERVICE Shutdown the non-cdb Plug in non-cdb to CDB Post-plug script to remove redundant metadata for the Oracle system objects 24

Demonstration Migration Walk-Through Start with single instance non-cdb at Oracle Database 12c Migrate to CDB as PDB with Oracle RAC and Active Standby Database Source and destination run on ASM Go to www.oracle.com/goto/maa 25

Managing Resources 26

Managing Resources Between PDBs PDBs vie for shared resources CPU Parallel execution servers Sessions I/O Resource Manager enables policies that prioritize/manage shared resources Set hard limits in consolidated environment get what you pay for 27

An Example - Managing CPU Container Database Utilization limits are used to enforce a hard limit on the CPU usage for a PDB Sales 50% min 100% max Marketing Support 25% min 25% min 75% max 75% max Shares are used to specify how CPU is distributed between PDBs CDB Resource Plan PDB Shares Utilization Limit Guaranteed CPU (share) Sales 2 2/4 = 50% 100% Marketing 1 75% 1/4 = 25% 75% Support 1 75% 1/4 = 25% 75% Maximum CPU (limit) 28

An Example - Managing CPU With a utilization limit of 75%, SUPPORT is throttled, even though CPU is available. Container Database With Support and Marketing active, each gets an equal share CPU Utilization 100 90 80 70 60 50 40 30 When all workloads are active, they again share the CPU based on their ratio of shares. Support (1 share) Marketing (1 share) Sales (2 shares) Sales 50% min 100% max Marketing Support 25% min 25% min 75% max 75% max 20 10 0 Utilization Limits provide clients consistent performance. They also restrict their resource usage, based on what the client paid 29

An Example - Managing CPU Container Database Configure a default directive that automatically applies share and utilization limits for subsequent PDBs. Sales Marketing Support Future PDB CDB Resource Plan PDB Shares Utilization Limit Guaranteed CPU Maximum CPU (Default directive) 1 50% 1/n 50% Sales 2 2/4 = 50% 100% Marketing 1 75% 1/4 = 25% 75% Support 1 75% 1/4 = 25% 75% 30

Enterprise Manager 12c and Oracle Multitenant 120% 100% 80% 60% 40% 20% 0% Self-Service IT Consolidation Management Quality of Service Database as a Service, Rapid Cloning Planning, Testing, Migration Life Cycle Management Proactive and Real-Time QoS Management 31

Unplanned Outages and Planned Maintenance 32

Unplanned Events Proactively Minimize or Eliminate Downtime Event Site failure Instance or server failure Storage failure Data corruption Human error Performance Primary Solutions Data Guard Oracle RAC Automatic Storage Management (ASM), RMAN Oracle Database parameters, Active Data Guard Flashback (CDB), RMAN point in time recovery (CDB or PDB) Database Resource Manager 34

What Happens if a PDB is in Trouble And the CDB and all Other PDBs are Healthy Use Resource Management to limit impact to other PDBs while problems are resolved If unable to resolve or the solution has the potential to impact other PDBs then: Unplug and plug into its own CDB and resolve Once resolved unplug and plug back into the original CDB 35

If Database Needs Recovery RMAN and Multitenant Backup/restore Entire CDB PDB in isolation of other PDBs Point in time recovery CDB all PDBs move back to same point in time Individual PDB no impact to other running PDBs Clone CDB and a subset of PDB Demonstration Point in time recovery for PDB at www.oracle.com/goto/maa 36

Planned Maintenance Minimize or Eliminate Scheduled Downtime Event Migrations Data reorganization Patching and upgrades Application upgrades Primary Solutions UnPlug/Plug, Data Pump/TTS, GoldenGate Online Reorganization and Redefinition Online Patching, UnPlug/Plug, Rolling Upgrades Edition-Based Redefinition, GoldenGate 37

Manage as One: Upgrade in Place Apply Changes Once, All Pluggable Databases Updated Upgrade in-place 38

Flexible Upgrade of Individual PDBs Unplug/Plug 39

Manage as One - Minimal Downtime Upgrades Active Data Guard Database Rolling Upgrade Step 1: Defer redo transport Data Guard 40

Manage as One - Minimal Downtime Upgrades Active Data Guard Database Rolling Upgrade Step 2: Upgrade standby and resync with primary Data Guard 41

Manage as One - Minimal Downtime Upgrades Active Data Guard Database Rolling Upgrade Step 3: Switch production to new version only downtime 42

Manage as One - Minimal Downtime Upgrades Active Data Guard Database Rolling Upgrade Finish: Mount original primary in new home and resync Data Guard Data Guard 43

Flexible Zero Downtime Upgrade for a PDB Oracle GoldenGate GoldenGate bi-directional replication across versions 44

Summary Multitenant and Oracle MAA High Availability and Data Protection Flexible migration strategies Policy-driven resource management HA and data protection optimized for Oracle Reduced complexity while retaining flexibility Manage as one at a CDB level Operate on an individual PDB where it makes sense to do so 45

Oracle Database 12c at Wellcome Trust Sanger Institute (WTSI) Oracle Open World - 2013 Kalyan Kallepally Principal Database Administrator

About Me Working as Principal Database Administrator at Wellcome Trust Sanger Institute 12 years of experience in Oracle (8-11gr2) 6 years of experience in MySQL, SQL Server & PostgreSQL Active member in 12C beta testing program Recently started blogging www.dbakalyan.wordpress.com You can reach me on dba_kkk@yahoo.co.uk

Wellcome Trust Sanger Institute One of the leading and most published genome institutions in the world Located in Hinxton, south of Cambridge, UK Founded in 1993 by the Wellcome Trust and the UK Medical Research Council (MRC) Primarily funded by the Wellcome Trust The institute is named after Dr Fred Sanger The double Nobel prize-winning biochemist Main aim is to ensure scientific data is freely available Responsible for the completion of 1/3 of the human genome

Data Centre at WTSI 1000m2 of Datacentre space split into 4 quadrants Current computational capacity - 16.5K cores and 20PB of storage 24/7 reliability with DR setup Going Green initiative Implemented Virtualization, MAID storage, data compression using algorithms and storage solutions Power consumption constant at 1.2MW since May 2009 despite 20 fold data storage increase

WTSI Oracle Grid Infrastructure - 11gR2 Primary Site 2 X 4 Node RAC clusters 2 Node RAC Cluster Oracle Restart Nodes DR Site 4 Node RAC cluster Oracle Restart

Read Write Clients 11.2.0.2 Read Only Clients Sync or Async Redo shipping 11.2.0.2 Redo Logs Redo apply Local Site Physical Standby Database ASM Primary Database Backup ASM Oracle Home (11.1.0.6) (11.2.0.2) Online Redo Logs Broker Sync or Async Redo shipping Oracle Oracle Home Home (11.2.0.2) (11.1.0.6) 11.2.0.2 Redo apply DR Site Physical Standby Database ASM WTSI Data Guard Layout Redo Logs Oracle Home (11.2.0.2) (11.1.0.6)

Current Projects Cancer Genome Project (CGP) Sanger Institute is a world leader in using DNA sequencing to identify mutations that causes cancer. Make the scientific data available to the world via our websites 24x7 Multiple database deployments to support both laboratory and research websites Laboratory Information Management System (LIMS) 24x7 multi-user laboratory information system designed to track and manage the efficient genotyping, phenotyping and production of model organisms for the purpose of scientific study Backend databases play a vital role In supporting the system We provide DaaS & SaaS to scientific collaborators around the world

Clients Cancer Genome Project - Current RAC/GRID Layout (11gR2) WAN TRAFFIC Data Guard Dedicated Network +ASM1 +ASM2 +ASM3 +ASM4 +ASM1 +ASM2 +ASM3 +ASM4 4 Node Primary Site 4 Node DR Site

LIMS Current Virtualization One-to-One Standby Layout (11gR2) Primary Site VMware Active Data Guard VMware DR Site DB9 DBn DB9 DBn DB7 DB8 DB7 DB8 DB5 DB6 DB5 DB6 DB3 DB4 DB3 DB4 DB1 DB2 DB1 DB2 Host O/S Host O/S Fire wall WAN

Current Challenges Databases in consolidated environments compete for shared computing resources CPU, memory, sessions, parallel execution servers, I/O Provisioning and management of many discrete databases Cloning Managing a large number of virtual environments Managing large number of standbys for HA Backups Patching and upgrading Oracle database/software binaries Many dependencies

2c Optimal Solution to Current Challenges Multitenant Architecture

LIMS Today - Virtualization and One-to-One Standby Layout (11gR2) Primary Site VMware Active Data Guard VMware DR Site DB9 DB10 DB9 DB10 DB7 DB8 DB7 DB8 DB5 DB6 DB5 DB6 DB3 DB4 DB3 DB4 DB1 DB2 DB1 DB2 Host O/S Host O/S Fire wall WAN

LIMS Using Oracle Multitenant with Oracle Database 12c Primary Site Oracle Multitenant Oracle Multitenant DR Site PDB9 PDB10 PDB9 PDB10 PDB7 PDB8 PDB7 PDB8 PDB5 PDB6 Active Data Guard PDB5 PDB6 PDB3 PDB4 PDB3 PDB4 PDB1 PDB2 PDB1 PDB2 Container Database Host O/S Container Database Host O/S Fire wall WAN

CGP Current RAC/GRID Layout (11gR2) Clients WAN TRAFFIC Active Data Guard Dedicated Network +ASM1 +ASM2 +ASM3 +ASM4 +ASM1 +ASM2 +ASM3 +ASM4 4 Node Primary Site 4 Node DR Site

CGP Oracle Multitenant (12C) with RAC Clients WAN TRAFFIC Global Data Services Application continuity Only two container databases More efficient resource utilization Same RAC Advantages Manage as one Backups and standbys New PDBs replicated automatically Move, Upgrade & Patch Active Data Guard Dedicated Network +ASM1 +ASM2 +ASM3 +ASM4 +ASM1 +ASM2 +ASM3 +ASM4 4 Node Primary Site 4 Node DR Site

A Smarter way to Consolidate More efficient resource utilization Higher density and greater scalability Manage many databases as one Manage, upgrade & patch Backups are done at the container level Backed up as one, flexibility to restore & recover at PDB level Standby is configured at CDB level All PDB s with in CDB are automatically replicated

Summary Looking forward to life with Oracle Database 12c at WTSI

Resources 63

Links www.oracle.com/goto/maa http://www.oracle.com/us/products/database/options/multitenant/ overview/index.html @OracleMAA 64

Multitenant Migration Options - Summary Source Version Migration Method Considerations If Data Guard Standby Downtime Estimate 12c same endian migration of non- CDB RMAN Active Duplication Requires no staging area for backups Incremental method (only downtime is the final incremental apply) Copy files to standby using same RMAN Active Duplication functionality MRP continues <1hr impacted by time for last incremental and time required for noncdb_to_pdb.sql execution 12c same endian unplug/plug of PDB RMAN Active Duplication Requires no staging area for backups Incremental method Copy files to standby using same RMAN Active Duplication functionality MRP continues 15m, impacted by time for last incremental and time required for dbms_pdb.sync_pdb execution 12c cross endian migration of non- CDB or PDB 12c RMAN Incremental XTTS Requires a seed PDB to be precreated prior to datapump import Requires staging area for backups Incremental method Copy files to standby using same functionality Follow Data Guard documentation for handling the datafiles 30m, impacted by time for last incremental and time required for datapump metadata import 65

Multitenant Migration Options - Summary Source Version 11.2.0.3 Any endian Other 11g and 10g Any endian Other 11g and 10g Any endian Any version, Any endian Migration Method Data Pump Full Database TTS/XTTS Data Pump TTS/XTTS Data Pump TTS/XTTS GoldenGate Considerations If Data guard standby Downtime Estimate Datapump import to plug in tablespaces Requires a seed PDB to be precreated prior to Data Pump import Incremental method available Datapump import to plug in tablespaces Requires a seed PDB to be precreated prior to Data Pump import Incremental method available Datapump import to plug in tablespaces Requires a seed PDB to be precreated prior to Data Pump import Incremental method available Requires a seed PDB to be precreated prior to GoldenGate instantiation Zero downtime migration requires bidirectional replication Copy files to standby using ASMCMD cp or host based copy command Follow Data Guard documentation for handling the datafiles Copy files to standby using ASMCMD cp or host based copy command Follow Data Guard documentation for handling the datafiles Copy files to standby using ASMCMD cp or host based copy command Follow Data Guard documentation for handling the datafiles Instantiation of GoldenGate objects on primary may require additional steps to maintain standby Impacted by time for last incremetnal and time required for Data Pump metadata import Impacted by time for last incremetnal and time required for Data Pump metadata import Impacted by time for last incremetnal and time required for Data Pump metadata import Minimal or Zero 66

Graphic Section Divider 67