CASE STUDY: Oracle TimesTen In-Memory Database and Shared Disk HA Implementation at Instance level

-ORACLE TIMESTEN 11gR1

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. detecting fraud. Middle East. 2 © SIMPLE LOGIC IT PVT.LTD. 2. REQUIREMENTS: Business Continuity requirements for mission critical databases are: 1. 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. Low Latency Data Access: Accurate and timely data is essential to the efficacy of modern financial networks and applications. while acceptable latency continues to shrink. It provides both public and private sector clients with a variety of Equity Capital Markets and Debt Capital Markets services. variety of Equity Capital Markets and Debt Capital Markets services. High Availability (HA): The data access requirements of financial systems are not limited to high performance with low and predictable latency. This case study describes how Simple Logic has deployed Oracle TimesTen InMemory Database and implemented Shared Disk High Availability at instance level as a major component of its Business Continuity strategy. They provide services like investment advice. It operates across Europe. 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. mitigating risk and managing portfolios. North America and Asia. They also include zero data loss for financial transactions that cannot tolerate any inaccuracies. All rights reserved. Financial services professionals expect data to arrive correctly and services to be delivered quickly. . They also include maximum availability for a financial world that operates around the clock and cannot tolerate service outages. OVERVIEW: The company is a leading brokerage and financial services firm headquartered and regulated in Japan. It also provides investment advice and research over a wide range of areas. Fixed Income operation to provide clients with a combination of best execution and innovative trade ideas.

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

Initially there is no actual datastore present in Instance B but the necessary ODBC. it contains a single TimesTen instance (Instance A) hosting a single datastore (Datastore A). 4 © SIMPLE LOGIC IT PVT. All rights reserved. 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.LTD. The other node (Node B) hosts its own instance of TimesTen (Instance B). one node (Node A) is the active node. 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. 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 disk storage is mounted at Node B. Initially. this implies the ability to re-direct external access from Node A to Node B. Of course. .INI definitions exist in Instance B to allow it to access the datastore once it ‘takes ownership’ of it after a failover.SHARED DISK HA OVERVIEW: This document focuses on a configuration that has just 2 nodes. If Node A fails such that we decide to perform a failover. then the disk storage ‘ownership’ is transferred to Node B. Node A and Node B need to be of the same hardware architecture and running the same O/S and TimesTen version. Instance B is instructed to ‘take ownership’ of the physical datastore (represented by the checkpoint and log files present on the shared disk storage).

2) Verified the data is present on the Secondary server. . CONCLUSION: Clients’ requirements for low latency. with scalability built-in to handle the growth they expect and plan for. 4) Rebooted the server. along with its datastore(s).IMPLEMENTING INSTANCE LEVEL HA: With this configuration. 3) Created user. FAILOVER TESTING: Following are the steps performed to test Instance Level Failover for Oracle TimesTen 11gR2: On PRIMARY Server: 1) Created a DSN. 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. there is actually only one installed instance of TimesTen. 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. On SECONDARY Server: 1) Started TimesTen daemon and connected to DSN. high-performance. All rights reserved. Industry leaders today rely upon Oracle TimesTen to deliver low latency.LTD. is migrated to Node B. The installation should use the default location for the DBI catalog files. 2) Started TimesTen daemon and connected to DSN. Oracle TimesTen has a successful track record. 5 © SIMPLE LOGIC IT PVT. The TimesTen instance should be (non-root) installed in a directory located within a file system on the shared disk subsystem. table and inserted a row in it. data integrity and reliability in their most demanding systems today. 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. 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. and reliability were met using Oracle TimesTen and shared storage high availability. Initially this instance resides on Node A and in case of failover the entire instance.

1] https://support.html 2.oracle.html 3.Implementing Shared Disk High Availability with TimesTen[ID 556063.com/technetwork/products/timesten/overview/times ten-imdb-086887.oracle.com/technetwork/products/timesten/documentation /index. All rights reserved.LTD. .REFERENCES : 1.Oracle TimesTen In-Memory Database Documentation http://www.oracle.com/ 6 © SIMPLE LOGIC IT PVT. Oracle TimesTen In-Memory Database Overview http://www.

Sign up to vote on this title
UsefulNot useful