CASE STUDY: Oracle TimesTen In-Memory Database and Shared Disk HA Implementation at Instance level. -ORACLE TIMESTEN 11gR1

Transcription

1 CASE STUDY: Oracle TimesTen In-Memory Database and Shared Disk HA Implementation at Instance level -ORACLE TIMESTEN 11gR1

2 CASE STUDY Oracle TimesTen In-Memory Database and Shared Disk HA Implementation at Instance level Client Company Profile It is a leading brokerage and financial services firm. It provides both public and private sector clients with a variety of Equity Capital Markets and Debt Capital Markets services. It also provides investment advice and research over a wide range of areas. OVERVIEW: The company is a leading brokerage and financial services firm headquartered and regulated in Japan. It operates across Europe, Middle East, North America and Asia. They provide services like investment advice, Fixed Income operation to provide clients with a combination of best execution and innovative trade ideas, variety of Equity Capital Markets and Debt Capital Markets services. For such a company it is necessary to achieve extremely fast response time and very high throughput as required by many applications in a wide range of Industries. Oracle TimesTen In-Memory Database is a memory-optimized SQL database that provides applications with extremely fast response time and very high throughput as required by transaction processing applications and real-time analytics for purposes such as trading, detecting fraud, mitigating risk and managing portfolios. This case study describes how Simple Logic has deployed Oracle TimesTen In- Memory Database and implemented Shared Disk High Availability at instance level as a major component of its Business Continuity strategy. REQUIREMENTS: Business Continuity requirements for mission critical databases are: 1. Low Latency Data Access: Accurate and timely data is essential to the efficacy of modern financial networks and applications. Financial services professionals expect data to arrive correctly and services to be delivered quickly, while acceptable latency continues to shrink. 2. High Availability (HA): The data access requirements of financial systems are not limited to high performance with low and predictable latency. They also include maximum availability for a financial world that operates around the clock and cannot tolerate service outages. They also include zero data loss for financial transactions that cannot tolerate any inaccuracies. 2

3 ORACLE TIMESTEN IN-MEMORY DATABASE: Deployed in the application tier, TimesTen databases reside entirely In physical memory with persistence to disk storage for recoverability. Applications access the in-memory databases using standard SQL interfaces. High availability is provided through real-time transactional replication. KEY FEATURES Low latency Microsecond response time Multi-user concurrency Durability and Persistence Transactional parallel replication Supports SQL and PL/SQL via ODBC, JDBC, ODP.NET, OCI and Pro*C/C++ REAL-TIME PERFORMANCE: Oracle TimesTen In-Memory Database (TimesTen) delivers real-time performance by changing the assumptions around where data resides at runtime. By managing data in memory, and optimizing data structures and access algorithms accordingly, database operations execute with maximum efficiency, achieving dramatic gains in responsiveness and throughput, even compared to a fully cached disk-based RDBMS. In addition to using the conventional client/server connections to the database, applications may further improve on transaction response time by embedding the TimesTen database within the application, thus eliminating inter-process communication and network overheads. KEY BENEFITS Real time performance Consistent response time Automated database failover Zero data loss Supports OLTP and analytic workloads Figure 1. Oracle TimesTen In-Memory Database 3

4 SHARED DISK HA OVERVIEW: This document focuses on a configuration that has just 2 nodes. Initially, one node (Node A) is the active node; it contains a single TimesTen instance (Instance A) hosting a single datastore (Datastore A). The datastore is in memory and being used by applications on that node and the disk storage for the datastore is mounted and owned by that node. The other node (Node B) hosts its own instance of TimesTen (Instance B). Initially there is no actual datastore present in Instance B but the necessary ODBC.INI definitions exist in Instance B to allow it to access the datastore once it takes ownership of it after a failover. If Node A fails such that we decide to perform a failover, then the disk storage ownership is transferred to Node B. The disk storage is mounted at Node B, Instance B is instructed to take ownership of the physical datastore (represented by the checkpoint and log files present on the shared disk storage), the datastore is loaded into memory (which will include TimesTen disk based recovery being invoked) and is then available for application usage at Node B instead of Node A. Of course, this implies the ability to re-direct external access from Node A to Node B. This is outside the scope of TimesTen and is normally handled via a cluster manager and a virtual IP address. An important point here is that for this to work, Node A and Node B need to be of the same hardware architecture and running the same O/S and TimesTen version. 4

5 IMPLEMENTING INSTANCE LEVEL HA: With this configuration, there is actually only one installed instance of TimesTen. Initially this instance resides on Node A and in case of failover the entire instance, along with its datastore(s), is migrated to Node B. The TimesTen instance should be (non-root) installed in a directory located within a file system on the shared disk subsystem. The installation should use the default location for the DBI catalog files. The advantage of this setup is that there is just a single installed copy of TimesTen since all the necessary files are held within the same directory tree on the shared disk subsystem. All that is needed now is to ensure that the file system that contains the installed copy of TimesTen is part of the same group of shared disk volumes/file systems as the datastore checkpoints and logs. Then the cluster manager will ensure that all the associated disk storage is only ever owned by one or other of the systems at any one time and the disk storage is moved as a group between systems on failover. FAILOVER TESTING: Following are the steps performed to test Instance Level Failover for Oracle TimesTen 11gR2: On PRIMARY Server: 1) Created a DSN. 2) Started TimesTen daemon and connected to DSN. 3) Created user, table and inserted a row in it. 4) Rebooted the server. On SECONDARY Server: 1) Started TimesTen daemon and connected to DSN. 2) Verified the data is present on the Secondary server. CONCLUSION: Clients requirements for low latency, high-performance, and reliability were met using Oracle TimesTen and shared storage high availability. Oracle TimesTen has a successful track record. It s proven in the financial sector and other industries and is an essential component of solutions used by financial services professionals and hundreds of millions of consumers worldwide. Industry leaders today rely upon Oracle TimesTen to deliver low latency, data integrity and reliability in their most demanding systems today, with scalability built-in to handle the growth they expect and plan for. 5

6 REFERENCES : 1. Oracle TimesTen In-Memory Database Overview ten-imdb html 2.Oracle TimesTen In-Memory Database Documentation /index.html 3.Implementing Shared Disk High Availability with TimesTen[ID ] 6