Safe Harbor Statement - Amazon S3 · Lessons Learned from Application Validations •Do not create...

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Safe Harbor Statement

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 Oracle’s products remains at the sole discretion of Oracle.

Oracle Confidential – Internal 2


Oracle Database12cBest Practices in Migrating Applicationsto an Oracle Multitenant Database

Sean StaceyDirector PTS, Server TechnologiesDatabase Product Management


2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

2025

Oracle 11.1 (GA: Aug 2007)

Oracle 11.2 (GA: Sep 2009)

Oracle 12.1 (GA: Jun 2013)

Release Roadmap

Sustaining Support

AUG 2015 AUG 2012

JAN 2018 JAN 2015

JUN 2021 JUN 2018

Waived Extended Extended Support Premier Support

1

Today

Oracle Database 12c Release 2 Targeted for Release 1HCY2016

(MyOracle Support Note 742060.1 )

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=742060.1






Non-CDB Architecture Deprecation

2

http://docs.oracle.com/database/121/DBLIC/editions.htm#DBLIC116


Licensing the Multitenant Option

3

http://docs.oracle.com/database/121/DBLIC/editions.htm#DBLIC116


Continuous Oracle Database Innovations Preserving customer’s investment though each new Computing Era

Stored Procedures Partitioning

Parallel Query Unstructured Data

Resource Management Real Application Clusters

Data Guard XML

Exadata Multitenant In-Memory

JSON

Big Data & Cloud Internet Client-Server


Journey to Database as a Service

Silos

Complex

Standardized

Simple

Consolidated

Efficient

Cloud

Agile


Co

nso

lidat

ion

Den

sity

Database Consolidation on Clouds Traditional consolidation methods

6

Share Servers Share Servers & OS Share Servers, OS, & Database

Virtual Machines Dedicated Databases Schema Consolidation


Co

nso

lidat

ion

Den

sity

Oracle Multitenant High consolidation density, transparent to existing applications

7

Share Servers Share Servers & OS Share Servers, OS, & Database

Virtual Machines Dedicated Databases Pluggable Databases


AP OE GL

New Multitenant Architecture Memory and processes required at container level only

8

System Resources

GL OE AP


GL OE AP

Oracle Database Architecture More efficient utilization of system resources

9

System Resources


Pluggable versus 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

• Pluggable databases scaled to over 250 while separate database instances maxed at 50

Public 10


Oracle Multitenant on SuperCluster T5-8 Consolidation Tests of PDBs vs. non-CDBs

0

20,000

40,000

60,000

80,000

100,000

120,000

140,000

SIDBs PDBs

Performance (Total Throughput) 252 PDBs vs. non-CDBs

0

50

100

150

200

250

300

SIDBs PDBs

Number of supported Databases (same Throughput per Database)

0

50

100

150

200

SIDBs PDBs

Number of Cores required to support 252 Databases

0

500

1000

1500

2000

SIDBs PDBs

Memory Footprint per Database (not including Buffer Cache)

80% higher aggregate

throughput

50% more databases

consolidated

8x reduction in memory footprint

MB

tps databases

cores

0

50000

100000

150000

200000

250000

300000

350000

400000

SIDBs PDBs

Storage IOPS required to support 252 Databases

3x reduction in storage IOPS 64 fewer cores needed

IOPS


Multitenant Improves Consolidation Density Tests comparing 252 single instance and pluggable databases

0

20000

40000

60000

80000

100000

120000

140000

SIDB PDB

Throughput (TPS)

0

200

400

600

800

1000

1200

1400

1600

1800

SIDB PDB

Memory Utilized (MBs)


Managing Shared Resources Resource management in a multitenant environment

13

GL OE AP

High Priority Medium Priority Low Priority


Database as a Service Patching & Upgrades Apply changes once, all pluggable databases updated

14

GL OE AP

Upgrade in-place

12.X 12.X 12.X 12.1 12.1 12.1


Database as a Service Patching & Upgrades Flexible choice when patching & upgrading databases

15

Original Container Database 12.1

GL OE AP GL OE

Upgraded Container Database 12.x


Manage Many Databases as One Backup databases as one; recover at pluggable database Level

Public 16

GL OE AP

Point-in-time recovery at pluggable database level

One Backup


Development in the Cloud

Database as a Service on the Cloud

17

Development and deployment agility

Development On Premise


Fast Provisioning, Snapshot Clones

0

5

10

15

20

25

Non CDB PDB Clone PDB using Copy-on-Write File System

Time Taken to Provision New Database

Database as a Service for Development

18

Development Container

Original PDB Clone

of PDB Snapshot Clone of PDB


Traditional File System Full copy duplicates all data blocks

my_file

my_file_copy File is collection of data blocks And headers Copy duplicates header & data blocks

Effective & simple, but expensive!

cp my_file my_file_copy


Copy-on-Write Basics Much more efficient storage of substantially similar files

my_file

my_file_copy

File is collection of data blocks And headers Copy file requires only copy of header

Much more efficient storage Minimal IO to create copy



Copy-on-Write Basics Much more efficient storage of substantially similar files

my_file

my_file_copy

File is collection of data blocks And headers Copy file requires only copy of header

Much more efficient storage Minimal IO to create copy

Copy block only when change needed



Multitenancy implemented by the Database, not the Application

22

Multitenant for Software as a Service

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6 Customer 7


✔ SILVERSILVER

BRONZEBRONZE

GOLDGOLD

✔

✔

Oracle Multitenant for Database as a Service Different service levels for different requirements

23

RAC, Data Guard

RAC

Backups Test and Development

Production

Mission Critical


Lessons Learned from Application Validations

24

1

2

3

4

5

Oracle Multitenant Database Restrictions Upgrading and Patching Application considerations when Connecting to Pluggable databases Sharing data across multiple Pluggable Databases Security considerations and Common users



25

Oracle Multitenant Database Restrictions Upgrading and Patching Application considerations when Connecting to Pluggable Databases Sharing data across multiple Pluggable Databases Security considerations and Common users

1

4

5

3

2



26

http://docs.oracle.com/database/121/READM/chapter12102.htm#BABGHDGB

1 Oracle Multitenant Database Restrictions


• Upgrading to Multitenant 1. Upgrade to 12c non-CDB

2. Startup the 12c non-CDB in read only mode

3. Exec procedure dbms_pdb.describe() to generate manifest

4. Backup the manifest (.xml) and data files together

5. On the CDB, using the manifest, exec function dbms_pdb.check_plug_compatibility()

6. In CDB$ROOT query pdb_plug_in_violations view for ERRORS and/or WARNINGs

7. Using the manifest, execute

Create pluggable database …. using ‘<manifest file path’> ….

- No copy or copy of storage

8. Run noncdb_to_pdb.sql in the new PDB

• Applying Patches

– Now use catctl.pl NOT catalog.sql

– Upgrade multiple PDBs simultaneously

• Follow Upgrade Documentation!

– run preupgrd.sql

– Run describe and check violations

– Open the pdb with the `…open upgrade…` flag

• Schema Consolidation Migrations

– Use PDB Subset Cloning for converting non-CDB multi schemas to separate PDBs

– Create pluggable database USER_TABLESPACES clause

Lessons Learned from Application Validations 2 Upgrading and Patching


• Use Services

– Default service in single instance

– Managed service in RAC


• USE_SID_AS_SERVICE_listenername=ON

– Only for legacy SID connect strings

– Opportunity to identify laggards

• Check client library versions for 12c

compatibility

– Specifically for third party applications

– Third party monitoring tools

Connectivity Implications

• Client Authentication

– Start using the SQL Easy Connect syntax: scott@//hostname:1521/pdb1 jdbc:oracle:thin:@//hostname:1521/pdb1

– For OS Authentication use the new parameter: common_user_prefix

– SQLNET.ALLOWED_LOGON_VERSION_CLIENT

– Avoid ‘ORA-28040: No matching authentication protocol’

• Set TWO_TASK for legacy management scripts

– Update these scripts ASAP

3 Connectivity Implications

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 29


• Do not Oversize the Pool

– Degrades performance

– Size 10 to 20 times the number of cores

– Use setMinPoolSize() and setMaxPoolSize()

– Use connection labeling in UCP to map a tenant with a PDB

• Use an Oracle Connection Pool

– UCP, Active GridLink in WLS

• Release Connections as soon as possible in to the pool

– Don’t leave connections checked out for too long.

3 Connectivity Implications – Connection Pools



• Querying across multiple PDBs-

– Database links can be used for accessing the data between PDBs

– Can span across different CDBs

– In Database 12.1.0.2 there is a new CONTAINERS clause:

SQL> SELECT ename

FROM CONTAINERS(scott.emp)

WHERE CON_ID IN (5, 8, 12) ;

– jj

• Data can be shared between multiple Pluggable Databases by the use of External tables

• DDL operations can be performed across multiple PDBs in parallel by using:

– catcon.pl

– -c to include Container

– -C to exclude Container

4 Sharing Data Between Pluggable Databases


• Define and Generalize your common user local user policies

– Define the role separation between local and common users

– Avoid GRANT session to common user globally

• New PDBs plugged in inherit common user

• Enforce local grant session to the common user

• Use the common user to lock down accounts across PDBs

• Standardize on common user prefix and suffix

– Avoids plug in violations if the common user is unknown to the CDB


• Do not create objects in the common users schema

• Do not change privileges on Oracle supplied common users

– Grant the privilege within the targeted PDBs

• Validate impact of common users prior to unplug/plug operations

– ‘conflicts’ are not captured in PDB compatibility checks

5 Security Implications and Common Users


• Implement Security features where appropriate

– Consolidate PDBs of common security features

– Use Oracle Security products

• Fully integrated with Multitenant

• DB Vault, Label Security, TDE, Masking, Redaction

• Follow Standard Oracle Security Best Practices to

minimize exposure to vulnerabilities

– Monitor database role and privilege usage

• Privilege Analysis – DBMS_PRIVILEGE_CAPTURE

– Use the 12c Unified Auditing

– Simplify the privilege model

– Leverage the separation of duties

• SYSBACKUP, SYSDG, SYSKM

• Implement Security features with post clone trigger

Lessons Learned from Application Validations 5 Security Implications and Common Users


Development in the Cloud

Database as a Service on the Cloud

1

Development and deployment agility

Development On Premise


Oracle MultitenantNew Oracle Database architecture for the Cloud

Virtualize the database into PDBs– Applications run unchanged

Lower OPEX– Manage many as one

• Patch, upgrade, backup, standby

– Granular control when appropriate

– Easy to provision, move, clone

Lower CAPEX– More databases per server

– Shared memory and background processes

2

ERP CRM

DW

Complementary to VMs


Achieve Database as a Service Today

Silos Standardized Consolidated Cloud

With a Two-Prong approach

1 Stand up DBaaS platform today to show immediate value for new projects

2 In parallel, consolidate/optimize with long term goal to move to strategic DBaaS

New Project


Partners who support Oracle Multitenant today

Oracle Technology Network Multitenant Community Page:http://www.oracle.com/technetwork/database/multitenant/overview/index.html

Safe Harbor Statement - Amazon S3 · Lessons Learned from Application Validations •Do not create...

Documents

Transcript of Safe Harbor Statement - Amazon S3 · Lessons Learned from Application Validations •Do not create...