OracleDB12 Integration With OracleWL12c

Copyright 2013, Oracle and/or its affiliates. All rights reserved. 1

CUSTOMER LOGO

This slide format serves to call attention to a quote from a prominent customer, executive, or thought leader in regards to a particular topic.

Name

Title, Company Name

blogs.oracle.com/IMC

Oracle WebLogic Server 12c & Oracle Database 12c Integration

Emin Askerov,

Valery Yourinsky

Oracle ISV Migration Center

[email protected]

[email protected]

blogs.oracle.com/imc


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.


Program Agenda

Oracle WebLogic Server and Oracle Database 12c

Database 12c: New Key Features For Business

Applications

WebLogic 12c (12.1.2) Integration: Together We Stronger

Demo: Application Continuity

Summary - Q & A


Program Agenda



Applications



Summary - Q & A


#1 Across Conventional and Cloud Environments Oracle WebLogic Server

Optimized for Engineered Systems

Foundation for Fusion Middleware & Applications

Market-leading Products

Oracle Business Applications

Cloud Application Foundation

Fusion Middleware

High Availability, Density, Performance

#1 HIGH PRODUCTIVITY

Java EE

Java SE

HTML5

Mobile, Developer

Productivity


Complete

Open

Integrated

Best in Class

On Premise and Cloud

User Engagement

Identity Management

Business Process

Management

Content Management

Business Intelligence

Service Integration Data Integration

Development Tools


Enterprise Management

Web Social Mobile

Next Generation, Mission-Critical Cloud Platform Oracle Cloud Application Foundation


Traffic Director/Web Tier

WebLogic Server

Coherence Tuxedo

Virtual Assembly Builder

Oracle Cloud

Exalogic Elastic Cloud


WebLogic Server 12c (12.1.2) Feature Snapshot!

Development with

WebLogic Server 12c

Maven Repository

HTML5 and WebSockets

TopLink Data Services

JDeveloper 12c

ADF 12c

Enterprise Pack for Eclipse 12c

Java EE/Java SE

Java SE 7

JSP 2.1, JSF 2.0, EJB 3.1, JPA 2.0

Restful Web Services

JRockit/Hotspot Convergence

Database 12c

Active GridLink for RAC

Web and Transaction Affinity

Multitenant Database Integration

Application Continuity with Transaction Guard

Fast Connection Failover

Database Resident Connection Pools

Global Data Services

WebLogic 12c Performance

SPECjEnterprise World Records EjOPS Overall, EjOPS/Processor

Enterprise Scale with

WebLogic Server 12c

Dynamic Clusters

Elastic JMS

Database Tlogs

Enterprise Manager 12c R3

Cloud Management

JVM Diagnostics

Incident and Problem Management

Patch Automation

Coherence 12c

Managed Coherence Servers

Goldengate Hotcache

Live Events

Cloud

Optimized WebLogic Virtual Appliances

Coherence Exalogic Exabus

WebLogic Elastic Messaging

Coherence Elastic Data

Exalogic HTTP, JMS and Web Service

Performance

TopLink Multi-Tenancy

WebLogic 12c Security

New Certification Validation

SPNEGO Update

RSA Update

JSSE Support


Security & Compliance

Big Data & Data Warehousing

Consolidation

Database as a Service

Application Development

High Availability

In-Memory

Performance & Scalability

Data Optimization

Released on June 25th 2013


Program Agenda



Applications



Summary - Q & A

Database 12c: New Key Features For Business Applications


Real Application Clusters (RAC)


The New Oracle RAC 12c Overview of Oracle RAC

Noncluster Oracle databases have a

one-to-one relationship between the

Oracle database and the instance.

Oracle RAC environments have a one-

to-many relationship between the

database and instances.

An Oracle RAC database can have up

to 100 instances, all of which access

one database.

All database instances must use the

same interconnect, which can also

be used by Oracle Clusterware. Utility Computer

Oracle EM 12

Cloud Control


The New Oracle RAC 12c Oracle RAC provides:

- a single system image for multiple servers to

access one Oracle database. In Oracle

RAC, each Oracle instance must run on a

separate server.

Oracle RAC 12c provides: - Better Business Continuity

and High Availability (HA)

- Agility and Scalability

- Cost-effective Workload Management

Using:

A standardized and improved

deployment and management

A familiar and matured high availability

(HA) stack

Utility Computer

Oracle EM 12

Cloud Control


ASM Overview Oracle Database 11.2 or earlier

ASM Cluster Pool of Storage

Node2

Disk Group B Disk Group A

Node3 Node5 Node4

Shared Disk

Groups

Wide File Striping

One to One

Mapping of ASM

Instances to

Servers

Node1

ASM Instance

Database Instance

ASM Disk

RAC Cluster

DBA DBA DBB DBB DBC DBB

ASM ASM ASM ASM ASM


Oracle ASM 12c Overview Oracle ASM 12c Standard Deployment


Disk Group B Disk Group A Shared Disk

Groups

Wide File Striping

One to One

Mapping of ASM

Instances to

Servers

ASM Instance

Database Instance

ASM Disk

RAC Cluster

Node4 Node3 Node2 Node1 Node5 ASM ASM ASM ASM ASM

ASM Instance

Database Instance

DBA DBA DBC DBB DBB DBB


Introducing Oracle Flex ASM Removal of One to One Mapping and HA



Groups

Wide File Striping

Databases share

ASM instances ASM Instance

Database Instance

ASM Disk

RAC Cluster

Node5 Node4 Node3 Node2 Node1

Node5

runs as

ASM

Client to

Node4

Node1

runs as

ASM

Client to

Node2

Node1

runs as

ASM

Client to

Node4

Node2

runs as

ASM

Client to

Node3

ASM ASM ASM

ASM Instance

DBA DBA DBC DBB DBB DBB


Flex ASM

In previous versions, ASM clients use OS-authentication to connect to ASM

This works because ASM clients and servers are always on the same server

With Oracle Database 12c,

ASM clients and ASM servers can be on different servers

A default configuration is created when the ASM cluster is configured

Benefits of providing a shared password file in ASM Disk Group

Remote Access


Supporting Pre-Oracle 12c Databases Pre-Oracle 12c Databases require a local ASM instance



Groups

Wide File Striping

Databases share

ASM instances ASM Instance

Database Instance

ASM Disk

RAC Cluster

Node5 Node4 Node3 Node2 Node1 ASM ASM ASM

DBA DBA DBC

ASM ASM

11g

DB

11g

DB DBB DBB DBB


Global Data Services


Global Data Services Cluster Services in a Global Scale

Cluster services (introduced in Oracle Database 10g) enables

dynamic load balancing and workload management in a clustered

environment

HR SALES ERP


Global Data Services (GDS) Next-generation Architecture

A Global Data Services configuration looks like a

virtual multi-instance database to database clients.

It provides client access through global services,

which are functionally similar to the local database

services provided by single-instance or Oracle Real

Application Clusters (Oracle RAC) databases.

Local and global services both provide load

balancing, high availability, resource management.

The essential difference between global services

and local services is that global services span the

instances of multiple databases, whereas local

services span the instances of a single database.

Active Data Guard

Reporting Service

Call Center Service

GoldenGate



Global Data Services (GDS) enables

administrators to automatically and transparently

manage client workloads across replicated

databases that offer common services.

A database service is a named representation of

one or more database instances. Services enable

you to group database workloads and route a

particular work request to an appropriate instance.

A global service is a service provided by multiple

databases synchronized through data replication

Active Data Guard

Reporting Service

Call Center Service

GoldenGate


Global Data Services Built on Active Data Guard

Active Data Guard (introduced in Oracle Database 11g) enables high-

performance reader farms

Active Data Guard Standby Databases

Real-time query with no data type limitations

Production

Database

Updates

Queries

Queries

Queries

Queries


Global Data Services Built on GoldenGate

GoldenGate enables data replication in an active-active multi-master

environment

Database A

Database B Database C

GoldenGate

Multi-Master Configuration



Global Data Services (GDS) is an Oracle Database 12c component

Provides load balancing in a global scale

Extends RAC-like connect time & run time load balancing globally

Enables optimal resource utilization

Dynamically migrates services based on load and availability

Provides global scalability and availability

Supports seamless failover

Supports dynamic addition of databases

Provides capability to centrally manage global resources

Easier management for globally distributed multi-database configurations


GDS Configuration

Global Service: Database Service provided by multiple

databases with replicated data

Local service + {region affinity, replication lag, database

cardinality, load balancing goals}

Global Service Manager (GSM): Provides main GDS

functionality: service management and load balancing

Regional listener to the incoming database connections

At least one GSM per region or multiple GSMs for High

Availability

All databases/services register to all GSM Listeners

GDS Catalog: stores all metadata, enables centralized

global monitoring & management

Global service configuration stored in GDS Catalog

GDS Region: Group of databases and clients in close

network proximity, e.g., East, West

GDS Pool: Databases that offer a common set of global

services, e.g., HR, Sales

GDSCTL: Command-line Interface to administer GDS

*GUI support of GDS in EMCC12.1.0.5

GDS Framework

Data Center #2

EMEA Region Data Center #1

APAC Region

Clients (Users) Clients (Users)

App/Middleware App/Middleware

Replication

GDSCTL

and EMCC

GDS

Catalog

Primary

GDS

Catalog

Standby

Global Service

Managers

Global Service

Managers

SALES POOL (sales_report_srvc, sales_entry_srvc)

SALES Databases HR POOL(hr_apac_srvc, hr_emea_srvc)

Replication

HR Databases


Multitenant Database Architecture


Oracle Database Architecture Requires memory, processes and database files

System Resources


New Multitenant Architecture Memory and processes required at container level only

System Resources


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

Pluggable vs Separate Databases Highly Efficient: 6x Less H/W Resource, 5x more Scalable


Managing Shared Resources Resource management for consolidated databases

High Priority

Medium Priority

Low Priority


Simplified Patching Apply changes once, all pluggable databases updated

Upgrade

in-place


Simplified Upgrades Flexible choice when patching & upgrading databases


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

One Backup

Point-in-time recovery

at pluggable database level


Manage Many Databases as One One standby database covers all pluggable databases


GOLD

SILVER

BRONZE

RAC, Data Guard, Daily Incrementals

Data Guard, Daily Incrementals

Weekly Full Backups

Managing Database Service Level Tiers Change tiers as databases become more mission critical


Fast Provisioning Pluggable databases can be quickly provisioned from seed

0

5

10

15

20

25

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

System

Time Taken to Provision New Database


Creating Databases for Test and Development Fast, flexible copy and snapshot of pluggable databases


Perfect for ISVs. Packaged apps and reference data are easily distributed


Consolidating Databases Step1: Upgrade databases in-place

Upgrade in Place


Consolidating Databases Step2: Plug-in upgraded databases


Getting to Multitenant Real Application Testing with Consolidated Replay

Capture workload

Capture workload

Capture workload

Transport

captured

workload


ERP

CRM

DW

Time

Consolidated Database Replays For manually consolidated and Pluggable Databases

Pro

cessor

Utiliz

ation

Replay Consolidated Workloads


Oracle Multitenant

Feature Customer Benefit

Simplified, dense consolidation Reduce capital expenditures

Manage many databases as one Reduce operational expenses

Rapid provisioning Reduce operational expenses

Rapid unplug/plug Reduce operational expenses

Security Isolation Secure multitenancy

Resource Isolation Tenants get fair share of computing resources

RAC compatibility Greater scalability & resource utilization

No application changes Easy to adopt for customers and ISVs

Customer Benefits


Application Continuity and Transaction Guard


Dealing with Unknown Transaction State Pre-Oracle Database 12c

Database outages can cause

in-flight work to be lost, leaving

users and applications in doubt

Often leads to

User pains

Duplicate submissions

Rebooting mid-tiers

Developer pains


Tackling In-Flight Work for Unplanned Outages

Transaction Guard

A Reliable protocol and API that returns the outcome of the last transaction

Application Continuity

Safely attempts to replay in-flight work following outages and planned

operations.

Two New Features


Tackling In-Flight Work for Unplanned Outages Transaction Guard

a protocol and developer API supported for JDBC Type 4 (Oracle Thin),

OCI, OCCI, and ODP.Net drivers.

introduces the concept of at-most once transaction semantics, also

referred to as transaction idempotence. When an application opens a

connection to the database using this service, the logical transaction ID

(LTXID) is generated at authentication and stored in the session handle at

the database and a copy at the client driver. This is a globally unique ID

that identifies the database transaction from the application perspective.

When there is an outage, an application using Transaction Guard can

retrieve the LTXID from the previous failed session's handle and use it to

determine the outcome of the transaction that was active prior to the

session failure.


Tackling In-Flight Work for Unplanned Outages Transaction Guard

When there is an outage, an application using Transaction Guard can

retrieve the LTXID from the previous failed session's handle and use it to

determine the outcome of the transaction that was active prior to the

session failure.

The only procedure in package DBMS_APP_CONT

DBMS_APP_CONT.GET_LTXID_OUTCOME (

client_ltxid IN RAW,

committed OUT BOOLEAN,

user_call_completed OUT BOOLEAN)


Tackling In-Flight Work for Unplanned Outages Application Continuity for Java

Masks planned or unplanned outages (that cause database session

unavailability) by attempting to rebuild the database session transactional

and nontransactional states, so the outage appears to the user as no more

than a delayed execution.

Application Continuity for Java works with the Oracle Database Release

12c Release 1 (12.1) server to determine if the database session can be

replayed.

Prepares replay by using Transaction Guard to determine the outcome of

the last operation submitted by the session that received the error.


Application Continuity Masks Unplanned & Planned Outages

Replays in-flight (DML)

work on recoverable errors

Masks many hardware, software,

network, storage errors and

outages when successful

Improves end-user experience and

productivity without requiring

custom application development


Application Continuity Example

Application Servers

Database Servers

End User

A reliable replay of in flight work

Network Switches

User selects product from

application and purchases it

from the web checkout

User transaction arrives at

application infrastructure. It

makes its way through the application tiers and results in a

database transaction being

created



Application Servers

Database Servers

End User


Network Switches The infrastructure hosting the

database fails just before the

transaction is committed to the

database.



Application Servers

Database Servers

End User


Network Switches

The jdbc driver detects the

failure and checks with an

available node in the cluster,

using Transaction Guard, whether the transaction

committed or needs to be

replayed

If the transaction needs to be

replayed, Application Continuity will submit all of the inflight work to a surviving node

in the cluster and perform a

commit. This all happens

transparently to the application



Application Servers

Database Servers

End User


Network Switches

The user receives confirmation

that his order has been

successfully completed.


When is Application Continuity for Java transparent

If the Application

Uses J2EE or JPA that uses the standard JDBC API

Uses UCP or WebLogic Server and return connections to

pool

Does not have external actions that cannot be replayed.


Database Resident Connection Pooling



Database Resident Connection Pooling (DRCP) provides a connection

pool of dedicated servers for typical Web application scenarios. A Web

application typically makes a database connection, uses the

connection briefly, and then releases it. Through DRCP, the database

can scale to tens of thousands of simultaneous connections.

DRCP uses a pooled server, which is the equivalent of a dedicated

server process (not a shared server process) and a database session

combined. The pooled server model avoids the overhead of dedicating

a server for every connection that requires the server for a short

period.



A database instance is communicating

with middle-tier processes running in a

middle-tier client.

A middle-tier process requests a

connection from the connection broker.

The broker hands off the request to the

server process, which communicates

directly with the middle-tier process.



DRCP provides the following advantages:

Complements middle-tier connection pools that share connections between

threads in a middle-tier process.

Enables database connections to be shared across multiple middle-tier

processes. These middle-tier processes may belong to the same or different

middle-tier host.

Enables a significant reduction in key database resources required to support

many client connections. For example, DRCP reduces the memory required for

the database and boosts the scalability of the database and middle tier. The

pool of available servers also reduces the cost of re-creating client

connections.

Provides pooling for architectures with multi-process, single-threaded

application servers, such as PHP and Apache, that cannot do middle-tier

connection pooling.



To enable database resident connection pooling:

Start the database resident connection pool

EXECUTE DBMS_CONNECTION_POOL.START_POOL();

Route the client connection requests to a database resident connection pool

Using Easy Connect string:

dbserver.company.com:1521/sales_db:POOLED

Using TNS connect descriptor:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbserver.company.com)

(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales_db)(SERVER=POOLED)))



Dedicated Server Shared Server Database Resident Connection

Pooling

When a client request

is received, a new

server process and a

session are created

for the client.

When the first request is

received from a client, the

Dispatcher process places this

request on a common queue.

The request is picked up by an

available shared server

process. The Dispatcher

process then manages the

communication between the

client and the shared server

process.

When the first request is received

from a client, the Connection Broker

picks an available pooled server and

hands off the client connection to the

pooled server.

If no pooled servers are available, the

Connection Broker creates one. If the

pool has reached its maximum size,

the client request is placed on the

wait queue until a pooled server is

available.

Comparison



Dedicated Server Shared Server Database Resident

Connection Pooling

Releasing database resources

involves terminating the session

and server process.

Releasing database

resources involves

terminating the session.

Releasing database

resources involves releasing

the pooled server to the pool.

Memory requirement is

proportional to the number of

server processes and sessions.

There is one server and one

session for each client.


proportional to the sum of the

shared servers and sessions.

There is one session for each

client.


proportional to the number of

pooled servers and their

sessions. There is one

session for each pooled

server.

Session memory is allocated

from the PGA


from the SGA.


from the PGA.

Comparison with others



Dedicated Server Shared Server Database Resident Connection

Pooling

Memory used

= 5000 X (400 KB + 4 MB)

= 22 GB

Memory used

= 5000 X 400 KB + 100 X 4 MB

= 2.5 GB

Memory used

= 100 X (400 KB + 4 MB) + (5000 X

35KB) = 615 MB

Out of the 2.5 GB, 2 GB is

allocated from the SGA.

The cost of each connection to the

broker is approximately 35 KB.

Example of Memory Usage

Consider an application in which the memory required for each session is 400 KB

for each server process is 4 MB.

The pool size is 100 and the number of shared servers used is 100.

If there are 5000 client connections, the memory used by each configuration is as follows:


Program Agenda



Applications



Summary - Q & A


GridLink

WebLogic

GridLink

WebLogic

WebLogic Integration with Oracle RAC Up to 3X Better Performance with Active GridLink for RAC

Integrated WebLogic and Database RAC clusters

Dynamic load balancing of requests to RAC nodes

RAC node transaction affinity for data locality

Continuous connection availability regardless of RAC changes

80% 20%

RAC Node Load Aware Connection Requests

GridLink

WebLogic

GridLink

WebLogic

RAC Node Affinity For Transactions

XA

GridLink

WebLogic

GridLink

WebLogic

Continuous Connections Regardless of RAC Changes


Active GridLink For RAC - Configurability Old: Multi Data Source

Enables load balancing with XA

on old RAC versions but.

Data source (DS) per RAC

node

Map DS to RAC nodes

Grouped DS into MDS

Configuration scaling issues

New: GridLink Data Source Leverages RAC technology

Single data source per cluster

SCAN address

Simpler

More scalable

Machine 1

RAC

Node 1

RAC Cluster

Oracle Database Service

GridLink Data Source

Local

Listener

ONS

Machine 2

RAC

Node 2

Local

Listener

ONS

WebLogic Cluster

Machine 2

Managed

Server 2

RAC SCAN

Machine 1

Managed

Server 1

Machine 1

RAC

Node 1

RAC Cluster


Multi Data Source

Local

Listener

ONS

Machine 2

RAC

Node 2

Local

Listener

ONS

WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Data

Source 1

Data

Source 2

Single

Data Source

Multiple

Data Sources


Active GridLink For RAC - Manageability

GridLink isolates WebLogic

from RAC changes

Consider adding RAC node

1. Multi Data Source (MDS) Undeploy MDS

Add data source 3 on all servers

Update MDS list

Redeploy MDS

Coordinate across servers

2. GridLink Automatically detects RAC node

No WebLogic config changes

Simpler

More reliable, no downtime RAC Cluster



WebLogic Cluster

Machine 2

Managed

Server 2

RAC SCAN

Machine 1

Managed

Server 1

Machine 1

RAC

Node 1

RAC Cluster


Multi Data Source

Listener

ONS

WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Data

Source 1

Data

Source 2

Machine 3

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Data

Source 3

Machine 1

RAC

Node 1

Listener

ONS

Machine 3

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Configuration

changes

No

changes


Active GridLink For RAC - Performance Runtime Connection Load

Balancing (RCLB) RAC workload aware Avoid busy RAC nodes

Multiple apps, backups

Multi Data Source (MDS) Round-robin load balancing

New connections to busy node

Bottlenecks, performance impact

GridLink RCLB distributes runtime

connections to least busy nodes

Up to 2-3x performance

More predictable performance

RAC Cluster


WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Machine 1

RAC

Node 1

RAC Cluster

Multi Data Source

Listener

ONS

WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Data

Source 1

Data

Source 2

Machine 3

BUSY

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Data

Source 3

Machine 1

RAC

Node 1

Listener

ONS

Machine 3

BUSY

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Uneven

workload

Balanced

workload


Active GridLink For RAC - Availability Fast Connection Failover

Faster failure detection and

failover

Multi Data Source (MDS) Periodic polling for node failure

Latency in failure detection

No awareness of planned

shutdown

GridLink Failure notification via ONS

New connections to surviving

nodes (no WebLogic polling)

Recovery notifications

Graceful RAC node shutdown

RAC Cluster


WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Machine 1

RAC

Node 1

RAC Cluster

Multi Data Source

Listener

ONS

WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Data

Source 1

Data

Source 2

Machine 3

DOWN

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Data

Source 3

Machine 1

RAC

Node 1

Listener

ONS

Machine 3

Down

RAC

Node 3

Listener

ONS

Machine 2

RAC

Node 2

Listener

ONS

Polling and

delayed

detection

Rapid

notification

via ONS

Available? Available? Available?

Node 3

Down


Application Continuity JDBC Replay Improved Resiliency for Better User Experience

RAC Cluster


WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Machine 1 RAC

Node 1

Listener

ONS

Machine

3 Down

RAC

Node 3

Listener

ONS

Machine 2 RAC

Node 2

Listener

ONS

1. FAN Down Event:

Node 3 Down

2. Create Connection to

Surviving Node;

Replay if safe

Leverage feature supported in DB 12c

Generic and GridLink datasources

DB exceptions captured at datasource layer

Examples: RAC node failure, transient DB

problem

Automatically replay requests

Transparent to application

Read and write requests supported

No XA Transaction support

Benefit: Better end user experience


Application Continuity Notes Active Gridlink and Generic datasources, 12c driver

only

Leverages JDBC replay, re-implemented in 12c DB

Enabled with use of oracle.jdbc.replay.OracleDataSourceImpl driver class

When connection is taken from pool, begin is called

JDBC calls are remembered through commit

When connection is put back in pool, end is called

On failure, new connection is automatically created

Transparent to application!

Replay is already complete when connection is given to

app

How it Works in WebLogic

Limitations :cannot use with XA, PLSQL, proxy

authentication, DRCP



Database Resident Connection

Pooling

Database connections/sessions are

pooled at the database

Enables better sharing of DB

resources, DB and application

scalability

WebLogic Integration with DRCP

Active GridLink and Generic Data

Sources

Data sources pool connection

placeholders and attach/detach

connections internally

Virtualization of DB Connections for Improved System Scalability

DRCP

WebLogic WebLogic

WebLogic WebLogic

12c Database


Scaling Without DRCP

DB Sessions (fixed capacity)

12c Database

WebLogic WebLogic


12c Database

WebLogic WebLogic


12c Database

WebLogic WebLogic

Scaling at the middle tier can

require additional scaling at

the database tier

Application servers hold connections, even if not in use.


Scaling With DRCP

12c Database

DRCP

WebLogic WebLogic

WebLogic WebLogic

WebLogic

WebLogic

WebLogic

DRCP enables sharing of

connections for more

efficient use of resources


DRCP Integration Notes

DRCP must be enabled on the database

Generic and Gridlink datasources, requires

12c DB and driver

Enabled with a datasource connection

property and URL

DRCPConnectionClass group/subgroup of connections

jdbc:oracle:thin:@//:/[:POOLED]

Pooled connections in WebLogic are

unattached When connection is given to app,

attachConnection() is called

When connection is returned to the pool,

detachConnection() is called

How it Works in WebLogic

DRCP

WebLogic

12c Database


WebLogic Integration with Pluggable Database

Pluggable Database One of multiple virtual databases hosted in a

single Container Database

Provides tenant isolation, while leveraging the benefits of a single unified Container Database

Better efficiency (CPU, Disk) Unified security management Simplified upgrade

WebLogic Server Integration with Pluggable Databases

Seamless integration

Support of MultiTenancy by automatically connecting to PDB (tenant) using Set

Container

Requires Oracle 12c Database

Increased Density and Scalability, Multi-Tenancy

Get Connection

Tenant1

Set Container

PDB1

Set Container

PDB2

Data Source

WebLogic Cluster

Mgd Svr 2 Mgd Svr 1

App 1

App 2

App 1

App 2 Get Connection

Tenant2

Container Database

PDB1

Tenant

1

PDB2

Tenant

2


WebLogic Domain 2 WebLogic Domain 1

Container Database

PDB

1

PDB

2

PDB

3

PDB

6

PDB

4

PDB

5

DS1 DS2 DS3 DS6 DS4 DS5

WebLogic Integration with PDB 1 Datasource per PDB/Tenant

Pluggable databases appear as

regular databases to WebLogic

In WebLogic, configure a

datasource per PDB/Tenant

Most benefits recognized at the

data tier

Increased Density and Scalability at the Data Tier


WebLogic Domain 1

Container Database

PDB

1

PDB

2

PDB

3

PDB

6

PDB

4

PDB

5

Datasource

WebLogic Integration with PDB Connection Switching Across PDBs

In WebLogic, configure a single data

source to pool connections to all tenant

database

Create a connection label callback

handler to call setContainer on

connections

Enables multi-tenancy at the middle and

data tiers

Enables density and scalability at middle

and data tiers

Better resource utilization

Increased Density and Scalability,

Support for Multi-tenancy Application 1: getConnection(Tenant5)

1

1

1

2

2 2

4 4 5

Connection

Label

Callback

Handler

setContainer()


WebLogic Integration with Global Data Services

Global Data Services in Database 12c Central management of database services

across distributed database cloud

Dynamic migration of services based on load and availability

Scalability by adding RAC clusters

Restart failed services on an available DB

WebLogic Server Integration with DB Cloud

GridLink datasources support GDS

GridLink datasource configuration specifies a primary region to access a global service

(locally), and the addresses to each region.

Reconnection to migrated services based on FAN events RAC-like failover for the DB cloud

Improved Performance, Scalability, Availability for WebLogic and Database Cloud


WebLogic Cluster

Machine 2 Machine 1

Managed

Server 1

RAC

Cluster

DataGuard,

GoldenGate

Region: MADRID

RAC

Cluster

RAC

Cluster

RAC

Cluster

Service1

Service2

FAN Events

Service2

Service1

Service2 under heavy load

GDS

Region: BARCELONA

Managed

Server 2


Feature

WLS 10.3.6/12.1.1/12.1.2 WLS 10.3.6/12.1.1 WLS 12.1.2 WLS 10.3.6/12.1.1 WLS 12.1.2

with 11g

drivers

with 11gR2 DB

with 11g drivers

with 12c DB with 12c drivers

with 11gR2 DB

with 12c

drivers

with 11gR2

DB

with 12c drivers

with 12c DB with 12c drivers

with 12c DB

JDBC replay (read/write) No No No No

Yes ; (RW with

Active GridLink

only, no XA

transactions)

Yes; (RW with Active

GridLink and Generic

Data source, no XA)

Pluggable Database

(PDB) No

Yes (Except Set

Container) No No Yes Yes

Dynamic switching

between PDBs No No No No No Yes

Database Resident

Connection pooling

(DRCP)

No No No Yes No Yes

Oracle Notification

Service (ONS) auto

configuration

No No No No No Yes; (Active

GridLink only)

Global Database

Services (GDS) No

Yes; (Active

GridLink only) No No

Yes; (Active

GridLink only)

Yes ; (Active

GridLink only)

JDBC 4.1 (using

ojdbc7.jar files & JDK 7) No No Yes Yes Yes Yes

WebLogic Oracle DB features matrix


Application Continuity with WebLogic Server Integration Demonstration


WEBLOGIC, DATABASE INTEGRATION

Integration with Oracle RAC

Application Continuity & Transaction Guard out of the box

Support for Multi-Tenant Database

Scalability with Connection Pooling

Support for Global Data Services

Application

Continuity

Database

Resident

Connection

Pool

Global

Data

Services

Multi-

Tenant

Database

WebLogic Server

Recap: Availability, Multi-Tenancy, Scalability Oracle WebLogic Server 12c, Oracle Database 12c


Next steps

White Papers

Maximize Availability with Oracle Database 12c

Oracle WebLogic Server Integration with Oracle Database 12c

Oracle WebLogic Server 12c Active GridLink for Oracle Real Application

Clusters

Oracle WebLogic Server 12c on Microsoft Windows Azure

Oracle WebLogic Server Multi-Data Sources & Oracle RAC

Presentations

Maximum Application Availability with Oracle Database 12c

Demos

Application Continuity Standalone

Application Continuity with WebLogic Server Integration


Next steps

Learn more on Oracle Learning Library

http://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P2

4_PREV_PAGE:8429,29

Blogs

https://blogs.oracle.com/WebLogicServer

https://blogs.oracle.com/databaseinsider/entry/oracle_database_12c

Podcasts

https://blogs.oracle.com/WebLogicServer/entry/part_i_weblogic_database_inte

gration

https://blogs.oracle.com/WebLogicServer/entry/part_ii_weblogic_database_inte

gration


Adopt & Implement the latest by Oracle

JOIN US

CONTACT US

[email protected]


twitter.com/oracleimc

youtube.com/OracleIMCTeam

facebook.com/oracleimc

ORACLE.COM/PARTNERS/GOTO/HUB-ECEMEA


CUSTOMER LOGO

This slide format serves to call attention to a quote from a prominent customer, executive, or thought leader in regards to a particular topic.

Name

Title, Company Name


twitter.com/oracleimc

youtube.com/OracleIMCTeam

facebook.com/OracleIMC

OracleDB12 Integration With OracleWL12c

Documents

Transcript of OracleDB12 Integration With OracleWL12c