TimesTen Technology For Epoch Well

1. TimesTenTechnology For Epoch Well March 16, 2006

2. TimesTen In-Memory Database History and Technology Background

3. Application RDBMS Application When You Think “Database…” SQL Results RDBMS + client/server connectivity NOT fast enough for a new category of performance-intensive applications

4. Application RDBMS Application RDBMS with Home-Grown Cache SQL Results For very demanding applications: Build a home-grown, application-specific, in-memory “cache”.

5. SQL Application Application Combine the cache and the database into ONE product … SQL RDBMS SQL Results + Full capabilities of a relational database + Memory-optimized speed & latency + Optimized for embedded architecture + Persistent, recoverable, highly available

6. History of TimesTen • Early 1990’s “Smallbase” project at HP Labs • Embedded into HP Opencall in 1995 • HP Spinoff into TimesTen, Inc. in 1996 • First customer revenue and shipments in 1998 • Profitable and cash-positive before acquisition • Acquisition by Oracle Corporation in June, 2005

7. 1,500+ Customers Run TimesTen • 7 of the top 9 NEPs build products with TimesTen • The world’s most popular telecom BILLING SYSTEMS use TimesTen • 4 of the top 5 WIRELESS OPERATORS in Europe use TimesTen • The largest CALL CENTERS in the world run on TimesTen • Over 40 OEM and ISV solutions are built on TimesTen In Networks In Telecom On Wall Street In the Enterprise

8. Active Active Standby Standby Trader Alerts TimesTen TimesTen TimesTen TimesTen Real-Time Program Trading of Equities Lehman Brothers Fixed-Income Trading System Internal Trading Desks( different geographyor class of instrument ) TimesTen Usage • Event capture (trade orders) • Order processing (trade matching) • Event publishing (trader alerts and closed orders) Performance Metrics • 1,000 fixed-income trades/hr (30/sec peak) • 20 trader alerts/sec Configuration • 4-CPU Server (plus hot-standby) per location • Linux with C++ applications • 2 Gigabyte TimesTen Value of TimesTen • Fast order execution • Trader alerting Orders, Inquiries, Notifications Trader Alerts XLA Application XLA Application Closed Order Data Tibco Messaging AggregatedReporting Global Order Repository

9. TimesTen In-Memory Database Technology Introduction

10. TimesTen Technology Basics • High-performance in-memory database software • Optimized memory layout and algorithms • Flexible options for data persistence to disk • Applications access the database via standard APIs (SQL,ODBC, JDBC) • Protect, Extend, Evolve your existing investment in RDBMS TimesTen Disk Persistence/ Recovery

11. How Big a Database Can I Build? • Database must fit into RAM • 32-bit operating systems • 2 GB on most platforms • 1 GB on Windows and HP • 64-bit operating systems • Limit is available RAM • For larger databases, use TimesTen to cache Oracle data One Shared Memory Segment Disk Persistence

12. TimesTen Platforms • Linux on x86, Opteron (64 bit), EM64T (64), Itanium (64) • Sun Solaris 8, 9, 10 (32 bit & 64 bit) • HP/UX on PA-RISC and Itanium (32&64) • HP Tru64 (64 bit) • IBM AIX 5.3 POWER (32 bit and 64 bit) • Windows 2000, XP, Server 2003 (32 only)

13. TimesTen Architecture

14. TimesTen Architecture TimesTen Main Daemon Directly Connected Applications TimesTen Subdaemon TimesTen Subdaemon TimesTen Subdaemon TimesTen Subdaemons Engine (ODBC Driver) Database I/O Data in Shared Memory Disk Persistence

15. Client/Server Connections to a Data Store Direct Connect Application TimesTen Server Client Application TimesTen Engine (ODBC Driver) TimesTen Client Driver(ODBC or JDBC Driver) TCP/IP Data Store in Shared Memory

16. MicroLogging™ - Resilience to Application Failures • TimesTen Daemon monitors application health • If an application aborts, an in-progress transaction is rolled back • Database remains fully available • Shared Memory is NOT corrupted TimesTen Main Daemon Directly Connected Applications

17. Architecture Comparison

18. Why Is TimesTen So Fast? • TimesTen needs fewer CPU instructions to accomplish the same work as a disk RDBMS • Physical memory addresses are used inside the engine • No lookups of logical addresses to physical addresses • No buffer cache management overhead

19. TimesTen Performance

20. TimesTen Throughput 12-CPU IBM AIX POWER 1.2 GHz Sun Solaris 9, 1.6 GHz Sparc, C with ODBC 300,000 Reads Per Second 100,000 Writes Per Second

21. Lightning Fast Response Average Response Times TimesTen/DataServer 5.1 Sun Solaris 9, 1.6 GHz Sparc 45 37µs 36µs 40 35 Updatea Record Inserta Record 30 15µs 25 Microseconds INSERT UPDATE 20 Capture or update data in 40 millionths of a second 15 Retrieve a Record SELECT 10 5 0 Database Operation

22. ODBC, JDBC, Client/Server 100% Read, 4-CPU Xenon x86 3/0 GHz, Linux 4-CPU 2.8 GHz Linux 271,000 Direct Client/Server 171,000 Transactions Per Second 51,000 35,000 ODBC with C++ or C JDBC

23. Data Durability & Recovery

24. ACID Properties • Full support for transactions (COMMIT/ROLLBACK) • Row-Level Locking • Versioning • Writes do not block reads • Reads do not block writes

25. Applications TimesTen Data Store Engine (ODBC Driver) Durability: Disk Storage Hard Disk Non-blocking Checkpoint Datastore.ds0 Datastore.ds1 {CALL ttCkpt} TimesTen Subdaemon Datastore.log1 Datastore.log2 Logging Datastore.log3 Checkpoints are performed automatically ONLY in TimesTen 6.0 and above

26. Three Logging Types Dynamically configurable with SQL statements LOG BUFFER ….. Tx …... ……Tx …… …...Tx…… Hard Disk TimesTen Data Store In-Memory Logging Datastore.ds0 Buffered Logging LOG BUFFER ….. Tx …... ……Tx …… …...Tx…… TimesTen Data Store Datastore.ds1 Datastore.log1 Datastore.log2 LOG BUFFER COMMIT COMMIT COMMIT Datastore.log3 TimesTen Data Store Durable Commit

27. TimesTen Data Store Recovery Datastore.ds0 Datastore.ds1 Datastore.log1 TimesTen Subdaemon TimesTen Data Store Datastore.log2 Datastore.log3 2. Transaction Log Rollforward

28. TimesTen Advanced Features and Functionality

29. TimesTen APIs • SQL and Relational at the database core • No proprietary API • JDBC driver provided for Java • ODBC (Open Database Connectivity) provided for C and other languages • C++ API (“TTClasses”) included with TimesTen • TTClasses calls ODBC underneath • Compatible with 3rd party ODBC and JDBC tools

30. Memory-Optimized Indexes • Hash Indexes • Extremely fast exact matches and equi-joins • Created automatically when a primary key is specified • T-Tree Indexes • Memory-optimized index technology • Use SQL “CREATE INDEX” like other databases • Very fast exact matches, range searches • Cost-Based Optimizer • Explains and Hints

31. Transaction Log Monitoring and Event Notification (XLA) • Track changes to tables and materialized views • Support multiple, concurrent XLA applications per data store • Maintain log positions via Bookmarks • Supported with C++ in TTClasses • New Java/JMS API in TimesTen 6.0

32. Example XLA Applications • Trigger-like functionality • Any INSERT, UPDATE, DELETE in the database can be monitored • For UPDATEs, the old and new copy of the data is visible • 1000s of transactions per second – much faster than triggers • Custom replication agents • Replicate data to relational or non-relational databases • Actions based on events • When the price of ORCL increases by $1.00, notify other applications to re-price options • When a new subscriber is added, notify the billing and provisioning systems

33. TimesTen Replication

34. TimesTen-to-TimesTen Replication • Replicate entire databases or individual tables • Dynamic configuration with SQL • Automatic recovery and catch-up of down systems • Asynchronous or synchronous (dynamic configuration with SQL) • Does not include a cluster manager (no automatic failover) Master - Subscriber Master - Master N-Way

35. Transaction Bookmarks Replication – How It Works (7) (2) Bookmark (1) TimesTen Log File Rep. Agent Data Store Disk Image (3) Ack. Sender TCP/IP (6) changes Receiver (5) TimesTen Log File Rep. Agent Data Store Disk Image (4) changes

36. TimesTen Cache Connect to Oracle

37. What you can do with Cache Connect Client • Load data from Oracle into TimesTen • Bulk load with LOAD CACHE GROUP, or … • AUTOREFRESH replication • Save data from TimesTen to Oracle • Using a “FLUSH CACHE GROUP” command in TimesTen SQL • Once the data is loaded, your application connects to TimesTen • SQL Operations are executed on TimesTen tables • Performance is greatly improved App ODBC/JDBC Application Server Tier Async Writethrough AUTO- REFRESH Hot Data Subset Database Server Tier ORACLE

38. Web-based GUI Administrator

39. Example SQL Statement CREATE TABLE CMS_FLEET ( CMS_FLEET_TYPE CHAR(10) NOT NULL, MAX_CREW_CNT NUMBER(3) NULL, ODS_CREATE_TMSTMP CHAR(26) NULL, PRIMARY KEY (CMS_FLEET_TYPE) ); Oracle table schema CREATE READONLY CACHE GROUP CG_CMS_FLEET AUTOREFRESH MODE INCREMENTAL INTERVAL 60 SECONDS FROM SCOTT.CMS_FLEET ( CMS_FLEET_TYPE CHAR(10) NOT NULL, MAX_CREW_CNT SMALLINT, PRIMARY KEY (CMS_FLEET_TYPE)) WHERE FLEET_TYPE = ‘BOEING’; SELECT MAX_CREW_CNT FROM SCOTT.CMS_FLEET WHERE CMS_FLEET_TYPE = ‘767’; TimesTen Cache Group A table called CMS_FLEET now exists in both TimesTen and Oracle:

40. Asynchronous Writethrough Memory and Disk Buffers App TimesTen acts as a “write cache” Good for applications with sudden, high write demand spikes TimesTen Oracle Agent Oracle Application SELECT Oracle Tables

41. Main TimesTen Benefits • Response Time in Microseconds • Predictable and Consistent Response Time • Throughput up to 100,000 Transactions Per Second and Beyond • Familiar Relational Model – Existing Developers are Immediately Productive • Unattended operation – DBA tasks are automated with applications • High Availability through Replication

42. Q Q U E S T I O N S & A N S W E R S A

43. Higher Customer Satisfaction through Personalization Dynamic Personalization • User preferences are loaded from Oracle RAC into Oracle In-Memory Database upon login • Preference information is now looked up in Oracle In-Memory Database • HA through replication • One API for both databases (JDBC) • Fast response time means a better user experience • Users now see personalized pages suited to their needs • User experience is now noticeably better than their competitors Worldwide Corporate Subscribers NA Application Servers EMEA / APAC Application Servers JDBC Load Balancer Load Balancer 4-CPU Servers, Linux, 2 GB databases Standby Active Active Standby Master Database Master Database Oracle

44. Model #1 Model #2 Model #N Hedge Fund: Unprofitable Architecture Hedge-Fund Traders Should I make this trade? … • Only the first trade makes a profit • Customer could not analyze data fast enough to make the trade first • Real-time ticker data could not be combined with historic data fast enough • Enterprise RDBMS was not fast enough • Home-grown in-memory data structures lacked SQL functionality and were expensive to maintain Real-time Modeling of Current Market vs. History Home-Grown In-Memory Database INFLEXIBLE … Real-time Market Data Updates Enterprise RDBMS Historic Market Data TOO SLOW

45. Model #1 Model #2 Model #N Profitable, Faster, Real-Time Decisions Hedge-Fund Traders … • Oracle In-Memory Database provides a flexible SQL interface allows for easy aggregations of data • Combining real-time ticker data with historic data is FAST and EASY • Analysis of market data in sub-seconds, not minutes • The customer can make the trade first, before their competitors • Therefore, they make a profit … and their competitor loses! Real-time Modeling of Current Market vs. History … Real-time Market Data Updates Enterprise RDBMS Historic Market Data On-demand load of selected data

46. Oracle TimesTen Comparison