Oracle Maximum Availability Architecture Best Practices for Oracle Multitenant

Transcription

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

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

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

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

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

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

7 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

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

9 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

10 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

11 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

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

13 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

14 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

15 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

16 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

17 Migration Strategies 17

18 Adopting Oracle Multitenant How Do I Migrate a Traditional Oracle Database to a CDB? Non-CDBs 11g Data Pump TTS Non-CDBs of version or earlier. Ideal for direct migration of departmental databases Downtime is a function of the number of database objects CDB 12c 11g 12c 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

19 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 ) May have additional clean up steps after import Additional manual steps if there is a Data Guard standby and using ASM 19

20 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

21 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

22 My Oracle Support (Note ) Detailed Migration Steps for Various Use-Cases Direct migration from Oracle 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

23 Migration Example: from Oracle Database 11g Upgrade to Oracle Database 12c then Plug In 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

24 Migration Example: from Oracle Database 11g Upgrade to Oracle Database 12c then Plug In X 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

25 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 25

26 Managing Resources 26

27 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

28 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

29 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 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 Utilization Limits provide clients consistent performance. They also restrict their resource usage, based on what the client paid 29

30 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

31 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

32 Unplanned Outages and Planned Maintenance 32

33 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 33

34 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

35 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

36 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 36

37 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

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

39 Flexible Upgrade of Individual PDBs Unplug/Plug 39

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

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

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

43 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

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

45 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

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

47 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 You can reach me on dba_kkk@yahoo.co.uk

48 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

49 Data Centre at WTSI 1000m2 of Datacentre space split into 4 quadrants Current computational capacity K 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

50 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

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

52 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

53 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

54 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

55 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

56 2c Optimal Solution to Current Challenges Multitenant Architecture

57 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

58 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

59 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

60 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

61 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

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

63 Resources 63

64 Links

65 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

66 Multitenant Migration Options - Summary Source Version 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

67 Graphic Section Divider 67