Oracle Multitenant Customer Success Story Oracle OpenWorld 2014 Session ID: CON6379
Ramesh Venkatakrishnan - IT Principal
Jeff McCormick - IT Senior Principal
Contents Presenter Bios
3
The Challenge of Scaling Database Services
4-5
Database Consolidation Provides Relief
6-7
Oracle Database Consolidation
8-10
Consolidation Strategy
11-13
Cigna Drivers Key Phases
14 15-17
Estimated Outcome
18
Migration Approach
19
Issues to look for
20
Adapting to the change Conclusion
21-23 24
Presenter Bios Ramesh Venkatakrishnan is an IT Principal at a major health service company. Ramesh has worked in IT for about 20 years and with 15+ years of extensive experience in all aspects of Advanced Oracle Database Administration. He has a master's degree in business administration from New York institute of technology and a bachelor's degree in science from the University of Madras. He holds several certifications including Oracle Certified Professional, Microsoft Certified Professional and IBM UDB certifications.
Jeff McCormick is an IT Senior Principal at a major health service company. Jeff has worked in IT for over 20 years as an information systems administrator, architect and principal. He holds several certifications including Oracle Certified Professional, Microsoft Certified Professional and Certified Sybase Professional. Jeff is the former President of the Connecticut Oracle User Group. He is a frequent speaker and has authored several papers on information related topics.
3
The Challenge of Scaling Database Services The success of more than two decades of database deployments has created an IT dilemma A lot of databases and an increasing Total Cost of Ownership (TCO)
4
The Challenge of Scaling Database Services Proliferation of databases, referred to as database sprawl is expensive and difficult to manage Single tenant database deployments have you at a breaking point!
Tenant
Tenant
Tenant
Database
Database
Database
Infrastructure
Infrastructure
5
Database Consolidation Provides Relief Database consolidation is a process which reduces the total number of physical databases Effectively pooling and sharing database resources
6
Database Consolidation Provides Relief The major benefits are reduced cost, reduced complexity and increased efficiency For the majority of databases, multi-tenancy makes good sense
Tenant
Tenant Database Infrastructure
7
Tenant
Oracle Database Server A database server consists of at least one database instance and a database A multi-instance configuration is referred to as a Real Application Cluster (RAC)
8
Oracle Database Consolidation Database consolidation implies multi-tenancy Database Multi-Tenancy is an architecture in which a single instance of a database serves multiple customers. Each customer is called a tenant.
9
Oracle Multitenant Architecture A single multi-tenant container database (CDB) has many pluggable databases (PDBs) High Density Consolidation
From a client point of view, a virtual PDB is the database From an operating system point of view, a physical CDB is the database
10
Consolidation Strategy – Getting Started Start with guidelines and assumptions Guiding Principals Select a project large enough to be credible and small enough to be delivered in 2014 Take a conservative but extensible approach Minimize individual application risk Contain Line of Business LOB exposure and minimize coordination & prioritization Optimize licensing
Assumptions There isn’t just one deployment model to achieve database consolidation For the majority of databases, consolidation makes good sense Benefits realized by fewer physical databases, higher density and lower operational overhead Database service post consolidation should be same or better than the current state To maximize the benefits of consolidation, target databases should be hosted in “big” servers
11
Consolidation Strategy – Factors There are many factors which shape consolidation Each combination of selected levers and specifications will define a unique consolidation model
Platform & Operating System Database Version Database Options Database Character Set Database Service Tier Database Performance Line of Business Software Development Lifecycle (SDLC) Environment Application Workload Most database consolidation strategies will likely employ several different models The sum of the models will define your consolidation strategy
12
Consolidation Strategy – Steps Database consolidation is as much an art as it is a science 1.
Define consolidation models AAA Server, BBB SAN Storage and CCC Platform & Operating System (virtualized) AAAEnterprise Server, BBBOS SAN Storage and CCC Platform & Operating System Enterprise OS (virtualized) AAA Server, BBB SAN Storage and12.1.0.1 CCC Oracle Enterprise Edition Database Version Platform & Operating System Enterprise OS (virtualized) Oracle Enterprise Edition 12.1.0.1 Database Version All Database Options Oracle Enterprise Edition 12.1.0.1 Database Version All Database Options AL32UTF8 Database Character Set All Database Options AL32UTF8 Database Character Set DaaS Tier 2 (Business Essential) Database Service Tier AL32UTF8 Database Character Set DaaS Tier 2 (Business Essential) Database Service Tier Database Performance All DaaS Tier 2 (Business Essential) Database Service Tier Database Performance All Commercial Line of Business Database Performance All Commercial Line of Business Software Development Lifecycle Development Commercial LineSoftware of Business (SDLC)Development EnvironmentLifecycle Development (SDLC) Environment Lifecycle Software Development Application All Development (SDLC) Environment Application All Workload All Application All Workload All Workload All
For each Consolidation Model 2. Identify qualifying databases 3. Map qualifying databases to specific model containers - workload analysis 4. Ensure Quality of Service (QoS) for each container’s tenants (“pluggable” databases)
13
Consolidation Strategy – Cigna Drivers
Reduce server sprawl Reduce database sprawl Simplify upgrades Simplify patching Improve resource utilization Database standardization
Technology refresh
14
Implementation – Key Phases Infrastructure selection • Alignment to our Infrastructure Solution Group’s design principle
Identification of inscope servers and databases • Our two offerings: DaaS1 (RAC) and DaaS2 (Single instance) • Targeting DaaS2 first as a conservative approach
15
Implementation – Key Phases Continued… Mapping of Source to Target • Database profile • Work load analysis - 6 months of actual work load reviewed CPU allocation Memory allocation Boundaries for Memory, CPU , Disk and Network
16
Implementation – Key Phases Continued… Grouping of databases - initially based on the SDLC as given below CDB Name DNNNNYYC SNNNNYYC VNNNNYYC XNNNNYYC PNNNNYYC
Description
Development and Destruct System Test, Release Management, Integration Testing Performance Volume and Stress Testing Production Fix and Training Production
ZNNNNYYC: Z : Environment type NNNN: Server number YY : Database identifier i.e. N1, N2, etc. C : Database type (i.e. CDB)
•
PDBs will continue to follow existing ORACLE_SID naming standards
•
Replicated databases will be grouped under separate CDB(s)
•
One CDB per server
17
Estimated Outcome Expected results Post Consolidation Server Configurations
10x reduction
Servers
3x reduction
Oracle Versions
3x reduction
OS Versions
3x reduction
Hardware Type
1 Standard Version
HA Solution
1 Standard HA Solution
Physical Servers
2x reduction
Database Servers
7x reduction
DB Character Set
1 Standard Character Set
18
Migration Approach No single solution Approach depends on the database size and availability requirements
• Option 1 Data Pump • Option 2 Golden Gate • Option 3 Unplug and Plug
OEM 12c (12.1.0.4) can automate migration en masse
19
Issues to Look for
Virtualization constraints Oracle client installation on windows Archive log generation (only CDB) Temporary tablespace management Shutdown immediate at the CDB level will shutdown all the PDBs Know which PDB or container you are connected to
Automate the opening of all pluggable database after the CDB startup
20
Adapting to the Change No application changes, but some changes for DBA CDB
PDB
Background Processes
YES
No
Shared by ROOT and all PDBs
Control File
YES
NO
Only at the CDB level
REDO LOGs
YES
NO
Only at the CDB level
SGA and PGA
YES
NO
UNDO tablespace
YES
NO
Only at the CDB level.
SYSTEM
YES
YES
Both at the CDB and individual PDB
SYSAUX
YES
YES
Both at the CDB and individual PDB
TEMP
YES
YES
Character set
YES
NO
Per CDB
SPFILE
YES
No
Only at the CDB level
Yes (ALL)
YES (partial)
DB_BLOCK_SIZE
YES
NO
AWR Reports
YES
Yes
DB Parameters
21
Monitoring consumptions of SGA/PGA at the PDB level is possible
Multiple options possible: TEMP tablespace per CDB or per PDB or both;
select NAME from V$PARAMETER where ISPDB_MODIFIABLE=‘TRUE’ At the CDB level Both global and local possible. For PDB level reports, only using sqlplus
Adapting to the Change Continued… RMAN Backup RMAN from root container
rman target /
RMAN from PDB
rman target sys/
@PDB1 rman target /
Complete CDB backup
BACKUP DATABASE PLUS ARCHIVELOG ALL
DELETE INPUT; BACKUP PLUGGABLE DATABASE PDB1 TAG
Backup only PDB (from CDB connection)
'PDB1';
Backup partial PDB (From CDB connection)
BACKUP TABLESPACE PDB1:SYSTEM; % rman target sys/@t12ccdb RMAN> RESTORE PLUGGABLE DATABASE PDB1;
Recovering PDB
RMAN> RECOVER PLUGGABLE DATABASE PDB1; RMAN> ALTER PLUGGABLE DATABASE PDB1 open; RMAN Pluggable Database Point in Time Recovery
PDB Point in Time recovery
(Doc ID 1521075.1)
22
Adapting to the Change Continued... Resource Manager
Difference between a CDB resource plan and PDB resource plan
Types of Resources that can be managed by resource plans
CDB
PDB
A CDB resource plan allocates resources to its PDBs according to its set of resource plan directives
PDB resource plan determines how the resources allocated to a specific PDB are allocated to consumer groups within that PDB. A PDB resource plan is similar to a resource plan for a non-CDB.
CPU Parallel Execution Servers
CPU I/O (Exadata Only) Parallel Execution Servers Runaway Queries Active Session Pool with Queuing Undo Pool Idle Time Limit
23
Conclusion Database consolidation brings benefits to both your IT and business organizations
A database consolidation strategy will require creativity Don’t over think it! Keep it simple and attempt to standardize on a manageable set of models and containers If you need to make adjustments, simply unplug and plug your databases into a better container and/or model
24
