Oracle International Corporation

Numerify, Inc.

Rohan Aranha

Tirthankar Lahiri

Sourav Ghosh

Andrey Gusev

Marie-Anne Neimat

Chih-Ping Wang

Juan Tellez

John William Miller

Paul Tuck

Ashish Motivala

Charles Hoch

Ben Fulton

Rahul Kapoor

Mark L McAuliffe

Gaurav Rewari

Sadanand Sahasrabudhe

Dina Thomas

Nagender Bandi

Susan Sokeng Cheung

Approaches for a persistent data store that may be used to service data queries originating from data warehousing applications, operational reporting applications, or data archiving and data feed applications. At periodic intervals, data may be extracted from one or more disparate data sources. The extracted data may be stored in the persistent data store in a tabular format. A backward delta data set is generated. The backward delta data set identifies what additions, deletions, and modifications need to be made to the data stored in the persistent data store to return the data to a most recent version. Backward delta data sets are stored and maintained in accordance with a policy that instructs two or more backward delta data sets, associated with a continuous interval of time, be combined into a single backward delta data set after the expiration of a specified amount of time.

Common extract store

A cluster manager manages copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node's virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Automated integrated high availability of the in-memory database cache and the backend enterprise database

A system includes an active node and a standby node and zero or more replica nodes. Each of the nodes includes a database system, such as an in-memory database system. Client updates applied to the active node are written through to the standby node, and the standby node writes the updates through to a primary database and updates the replica nodes. Commit ticket numbers tag entries in transaction logs and are used to facilitate recovery if either of the active node or the standby node fails. Updates applied to the primary database are autorefreshed to the active node and written through by the active node to the standby node which propagates the updates to the replica nodes. Bookmarks are used to track updated records of the primary database and are used to facilitate recovery if either of the active node or the standby node fails.

Database system with active standby and nodes

A replication track is a designated group of transactions that are to be replicated at a destination database in a way that, with respect to any other transaction in the replication track, preserves transactional dependency. Further, transactions in a replication track can be replicated at the destination database without regard to transactional dependency of other transactions in another track. This facilitates concurrent parallel replication of transactions of different tracks. Replicating data in this manner is referred to herein as track replication. An application may request execution of transactions and designate different tracks for transactions.

User-defined parallelization in transactional replication of in-memory database

A cluster manager is configured to manage a plurality of copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node's virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager to behave in this fashion during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Growing community of inventors

Redwood City, CA, United States of America

Rohan Aranha