High Speed and High Availability with Oracle In...
Transcript of High Speed and High Availability with Oracle In...
High Speed and High Availabilitywith Oracle In-Memory Database Cache
Susan CheungDirector Product Management
<Insert Picture Here>
Agenda
• Overview of TimesTen and In-MemoryDatabase Cache
• Performance
• High Availability
• Achieving zero downtime
• Customer Use Cases
• Q & A
Tuning Application PerformanceGeneral Approaches Used
• Tune the database– Query optimization and database schema
• Get more hardware– Add or upgrade processors, disk storage
• Implement some ‘cache’ in the application
• Challenges for application specific ‘caches’– Limited functionality, typically not share-able with other application
– SQL query language typically not available
– Higher application maintenance cost
– No support for HA (high availability)
Speed without Reliability is simply UNACCEPTABLE
Oracle TimesTen In-Memory DatabaseMemory-Optimized RDBMS for Real-Time Applications
• Standard SQL interface
• Deployed as standalonedatabase in the middle-tier,close to the application
• Fast, consistent responsetimes– High transaction throughput
• Rock solid reliability– High performance replication
Application Application Application
Telco ServicesFinancial Services
CRM, Portal,SaaS,
Customer-facingApplications
Real-TimeBAM & BI
What is Oracle TimesTen In-Memory Database?
• In-memory RDBMS– Entire database in memory
– Standard SQL with JDBC,ODBC, OCI, Pro*C, PL/SQL
– Compatible with OracleDatabase
• Persistent and durable– Transactions with ACID
properties
• Extreme performance– Instantaneous response time
– Very high throughput
• Embeddable
Directly-LinkedApplication
TimesTenLibraries
Client-ServerApplication
TimesTenClient Lib
Memory-ResidentDatabase
Client/Server
JDBC / ODBC / OCI / PLSQL
CheckpointFiles
LogFiles
Fastdataaccess
TimesTen and In-Memory Database CacheApplication Development
New in 11g release
• PL/SQL, Oracle Call Interface (OCI) and Pro*C Support
Planned for CY2010
• ODP.NET data provider, PHP
Pro*C
PL/SQL
LanguageC/C++
ODBC
ttClasses
OCI
J2EE App Servers OR Mapping
IMDB CACHEIMDB CACHE
TimesTen In-Memory DatabasePersistent, Recoverable, and Highly Availability
• Persistent and durable– Database persisted to disk
– Transaction logs persisted todisk
• Highly-available viatransactional replication– Active-standby plus read-only
subscribers
– Asynchronous, Synchronous
– Online upgrade, cross versionsreplication
– Clusterware integration
Active Standby
In-MemoryDatabase
Tx Logs
Checkpoints
Direct-linkedApplications
C/S
Client-Server
* Direct-linked = In-process
Client-Server
TimesTenClient lib
Application
TimesTenClient lib
Application
TimesTenClient
Application
In-MemoryDatabase
Direct-linkedApplications
Tx Logs
Checkpoints
C/S
ApplicationApplication
Application
Read-onlySubscribers
What is Oracle In-Memory Database Cache?
• Built using Oracle TimesTen asa relational cache database
• Cache Oracle database tablesin the application-tier
– Lower response time and increasethroughput for Oracle Databaseapplications
• Read-only and updatable
• Automatic data synchronizationwith the Oracle Database
Directly-LinkedApplication
TimesTenLibraries
Client-ServerApplication
TimesTenClient Lib
Client/Server
JDBC / ODBC / OCI / PLSQLCheckpoint
Files
LogFiles
Mid-TierServer
DatabaseTier
Flexible Caching Definition
ApplicationTransactions
Root Table
ChildTable
ChildTable
ChildTable
Cache Groups • Cache Group describes thedata in the Oracle Database tocache
• Groups of related tables– All or subset of rows and columns
– Defined via SQL WHERE clauseCREATE CACHE GROUP
…
WHERE <predicate>
• Cached tables are regulardatabase tables in TimesTen– Joins/search, insert/update/delete
Updatable CacheWith Transactional Consistency
• TimesTen database is the‘master’
• Transactions executed inTimesTen
• Committed transactionswrite-through to Oracledatabase– Asynchronous write-through
yields better response time andthroughput
AutomaticSynchronization
3-node Cache Grid
InIn--MemoryMemoryCache TablesCache Tables
ApplicationTransactions
InIn--MemoryMemoryCache TablesCache Tables
ApplicationTransactions
InIn--MemoryMemoryCache TablesCache Tables
ApplicationTransactions
Read-only CacheFor Frequently Queried Data
• Oracle database is the‘master’
• Updates in Oracleautomatically refreshed to thein-memory cache tables– Refresh frequency (interval)
configurable
• Updates to read-only cachetables disallowed– May use pass-through to directly
update the Oracle databaseUpdates to
Oracle Server
AutomaticSynchronization
3-node Cache Grid
InIn--MemoryMemoryCache TablesCache Tables
ApplicationReads
InIn--MemoryMemoryCache TablesCache Tables
ApplicationReads
InIn--MemoryMemoryCache TablesCache Tables
ApplicationReads
Flexible Caching Options
• Different caches may all coexist
– Pre-loaded read-only cache
– Pre-loaded updatable cache
– Dynamic read / write cache
– Sliding window cache
• Flexible In-memory database caching– Locality optimized for consistent response time
– Globally shared across all nodes for application transparency
– Scale-out horizontally with processing capacity
• Transactional consistency across cache nodes andsynchronization with Oracle Database
In-Memory Database Cache GridScaling with Business Growth Peer-to-peer
communicationbetween grid
nodes
IncrementalscalabilityHigh
availability
In-MemoryDatabase
Cache
Application
In-MemoryDatabase
Cache
Application
In-MemoryDatabase
Cache
Application
In-MemoryDatabase
Cache
Application
Synchronizedwith Oracledatabase
Transactionalconsistency
In-MemoryDatabase
Cache
Application
Online addition(and removal)
of cache nodes
Lightning Fast Response Time
0
2
4
6
8
10
12
14
16
Read a Record Update Transaction
millionthsof
a second
44
millionthsof
a second
1414
Mic
roseco
nd
s
Oracle TimesTen In-Memory Database 11g - Intel Xeon 3.0 Ghz 64-bit Oracle Enterprise Linux
246,623
394,671
730,696
993,390
1,265,867
0
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
Rea
dO
pe
rati
on
sP
er
Se
co
nd
1 2 4 6 8
Concurrent Processes
Linear Throughput Scaling – Read ThroughputScale Up on Multi-Processor / Multi-Core Hardware
Oracle TimesTen In-Memory Database 11g AMD64 Dual-Core 1.8GHz, 4 Processors, 16GB RAM; OEL 4.0
Linear Throughput Scaling – Update ThroughputScale Up on Multi-Processor / Multi-Core Hardware
Oracle TimesTen In-Memory Database 11g AMD64 Dual-Core 1.8GHz, 4 Processors, 16GB RAM; OEL 4.0
56,179
86,782
141,093
184,126188,532
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
200000
Tra
nsacti
on
sp
er
Seco
nd
1 2 4 6 8
Concurrent Update Processes
Out of CPUresources
DEMO
Order Matching Application
• Three transaction types– Place market order
– Place limit order
– Process quote
• Java application
• Business logicimplemented in PL/SQL
• Demo – Execute 1,000transactions (one thread)– Place a market order or
limit order
– Process a quote
Presentation
TradingApplication
TradingApplication
In-MemoryDatabase
Cache
PL/SQLPL/SQLExecuted onExecuted onOracle DBOracle DB
PL/SQLPL/SQLExecuted inExecuted inIMDB CacheIMDB Cache
Start Demo Now
Accelerate Order Matching ApplicationLower Response Time and Higher Throughput
High Availability
Replication Options
• Asynchronous Replication– Commit call returns without blocking
– Transaction asynchronously transmitted to Standby database
– Great for throughput with small windows of vulnerability (less than200 millisecs)
• Synchronous 2-SAFE Replication– Commit call is blocked until both Standby and Active committed
the transaction in memory
– Guaranteed no-data-loss for single point of failure
– Much faster than using durable commits to disk
Updatable Cache Replication
• Execute transactions on Active
• Replicate transactions toStandby
• Propagates committedtransactions to Oracledatabase
• Standby available for reads
• Resilience to failures– Application transactions continue
even if connection to Oracledatabase is down
• Instant failover, no data loss
CacheWrite-through
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
Loss of Connection to the Oracle Database
• Application transactionscontinue
• Cache transactionscommitted and persisted ondisk
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
Network down
Loss of Connection to the Oracle Database
• Application transactionscontinue
• Cache transactionscommitted and persisted ondisk
• Propagation resumes whennetwork connection isrestored
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
CacheWrite-through
Loss of Active Server
• Automated failure detection– Oracle Clusterware integration
• Instant failover to Standby
• No interruptions to application
• Synchronization to Oracledatabase goes on
CacheWrite-through
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
Active
Recover Failed Active Server
• Recover failed node or use a‘Spare Node’– Standby node automatic re-
synchronized with the new Active
– Data propagation to OracleDatabase not affected
– New Standby available for reads
InIn--MemoryMemoryCache TablesCache Tables
ApplicationTransactions
Active
InIn--MemoryMemoryCache TablesCache Tables
Standby
Standbyavailable for
reads
CacheWrite-through
Loss of Standby Server
• Automated failure detection– Oracle Clusterware integration
CacheWrite-through
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
Loss of Standby Server
• Automated failure detection– Oracle Clusterware integration
• No interruptions to application
• Active node takes oversynchronization to Oracledatabase
Hot Standbyavailable for
readsApplication
Transactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
CacheWrite-through
Loss of Standby NodeNo Impact to Read-only Subscribers
• Automated failure detection– Oracle Clusterware integration
• No interruptions to application
• Active node takes oversynchronization to Oracledatabase
• Active node replicates to read-only subscribers (if applicable)
• No application down time
• No interruption to reader farm
CacheWrite-through
ApplicationTransactions
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Read-Only
Read-Only
Read-Only
In-MemoryDatabase
Cache
In-MemoryDatabase
Cache
In-MemoryDatabase
Cache
Read-only Cache Replication
• Incremental cache refreshfrom Oracle database
• Replicate cache updates toStandby
• Active/Standby available forreads
• Resilience to failures– When connection to Oracle
database is down
• Instant failover withoutreloading the entire cache
Cacherefresh
Hot Standbyalso
available forreads
Queries onread-only
cache
Tx logs
on disk
Active
InIn--MemoryMemoryCache TablesCache Tables
Tx logs
on disk
Standby
InIn--MemoryMemoryCache TablesCache Tables
Automatic Client Connection Failover
• Available for Client / Serverconnections– Configurable by the application
• Automatic connection failover– When TimesTen/IMDB Cache
server failover to the Standbyserver
• Automatic re-connect to thenew Active server– Connection handle is preserved
• Connection failover notification(like TAF)– Available if subscribed
In-MemoryDatabase
Cache
Active
In-MemoryDatabase
Cache
Active
IMDB CacheClient Library
Application
Integration with Oracle ClusterwareAutomated Management, Monitoring and Failover
Oracle Clusterware
• Manages TimesTen / IMDBCache processes
• Monitors and detects failure of
– Nodes
– TimesTen / IMDB Cacheprocesses
– Applications
• Manages automatic failoverand assignment of new roles
• Recovers automatically,including provisioning of sparenodes
In-MemoryDatabase
CacheIn-MemoryDatabase
CacheIn-MemoryDatabase
Cache
Read-OnlySubscribers
In-MemoryDatabase
Cache
Application
In-MemoryDatabase
Cache
Application
Active Standby
SharedStorage
Spare Nodes
ForClusterware
Integration with Oracle RACCross-tier High Availability
• Automatic recovery fromOracle Database RACnode failures using TAFand FAN– Automatic reconnection to the
cluster
– Automatic resumption of datarefresh from Oracle toTimesTen
– Automatic resumptiontransaction propagation fromTimesTen to Oracle
– No loss of transactions
ApplicationTransactions
Hot Standbyfor reads
In-MemoryCache Tables
Active Standby
In-MemoryCache Tables
Integration with Oracle Data GuardOracle Maximum Availability Architecture
Real Application ClustersReal Application Clusters Standby Oracle DatabaseStandby Oracle Database
Data Guard
• Support Data Guardsynchronousphysical standby– Failover
– Switchover
– Rolling upgrade
InIn--Memory Database CacheMemory Database Cache
Cachetables
BusinessApplications
Cachetables
BusinessApplications
Loss of Primary Oracle DatabaseZero Downtime
Real Application ClustersReal Application Clusters Standby Oracle DatabaseStandby Oracle Database
• Switchover / failoverto standby OracleDatabase
– Zero downtime
– No data loss
– Transparent to theapplicationsconnected to IMDBCache
InIn--Memory Database CacheMemory Database Cache
Cachetables
BusinessApplications
Cachetables
BusinessApplications
Customer UseCases
Proven in Real-Time DeploymentsDeployed by Thousands of Companies
Order Matching Market Place
OrderRepository
ServiceDesk App
InIn--MemoryMemoryCache TablesCache Tables
Application
Dispatcher
ACTIVE
Dispatcher
InIn--MemoryMemoryCache TablesCache Tables
Application
STANDBY
Message Bus
Clients
Orders
SUBSCRIBER onDR Site
RemoteData Center
Performance• Low latency
• High throughput
• Scalable
Reliability• Guaranteed
transaction model
• High availability
• Fast failover
• No data loss
Dispatcher
InIn--MemoryMemoryCache TablesCache Tables
Application
DR Subscriber
Database Requirements• Data access latency < 10ms• Ease of administration• Geo-redundancy• High Availability
Solution• IMDB Cache for real time queries,
local and central administration• Data Guard for Geo-Redundancy• RAC for high availability
Results• Exceeds Site latency requirement• Site query time ~2.2 ms• WAN to RAC query time ~150 ms
Reduce Call Connection TimePerformance + Site Availability + Geo Redundancy
Primary connections to IMDB CacheBackup connections to IMDB CacheOracle Data Guard
Site
Site
Site
Site
Site
Site
DC #1
RAC
DC #2
RAC
Site Requirements
• Fast data access
• High Availability
Solution• Application connects to local
data source for fast responsetime
• Active and Standby for HA
• 2 read-only subscribers foradditional data capacity andsite redundancy
Site AvailabilityLow Latency + Local Redundancy
IMDBCache
Active
IMDBCache
Standby
IMDBCache
Subscriber
IMDBCache
Subscriber
App
Site Configuration
The preceding is intended to outline our generalproduct direction. It is intended for informationpurposes only, and may not be incorporated into anycontract. It is not a commitment to deliver anymaterial, code, or functionality, and should not berelied upon in making purchasing decisions.The development, release, and timing of anyfeatures or functionality described for Oracle’sproducts remains at the sole discretion of Oracle.
For More Information
Oracle TimesTen Product Center on OTN:
http://oracle.com/technology/products/timesten
• Technology white papers
• Quick Start Guide and tutorials
• Discussion Forum
• And more..