Oracle International Corporation

Silicon Graphics, Incorporated

Wei-Ming Hu

Mark Dilman

Juan R Loaiza

Leonid Novak

J William Lee

Michael James Stewart

Adam Y Lee

Kothanda Umamageswaran

Neil J S MacNaughton

Ilya Taranov

Lik Wong

Sampanna Shahaji Salunke

Mahesh Baburao Girkar

Kiran Badrinarain Goyal

Hubert Ken Sun

Zheng Zeng

Yunrui Li

William Havinden Bridge, Jr

Vinay H Srihari

Selcuk Aya

Balasubrahmanyam Kuchibhotla

Jia Shi

Jean De Lavarene

Kevin S Neel

Alexander Tsukerman

Kant C Patel

Feroz Alam Khan

Bharat Chandra Baddepudi

Bhaskar Mathur

Vidya Hegde

Roger J Hansen

Tirthankar Lahiri

Sashikanth Chandrasekaran

Garret Frederick Swart

James William Stamos

Carol L Colrain

Kumar Rajamani

Niloy Mukherjee

Alex Tsukerman

Jaebock Lee

Margaret Susairaj

Neil MacNaughton

Alok Pareek

Ghazi Nourdine Benadjaoud

Vipin Gokhale

Jingling William Lee

Boris Erlikhman

Stephen Ball

Eugene Reddy Ho

Bharat C V Baddepudi

Amrish Srivastava

Adrian Ng

Sachin Vijakumar Sonawane

Lakshminaray Chidambaran

Saravanakumar Ramasubramanian

Muthu Olagappan

Hochak Hung

Denny McKinney

Ankur Kemkar

Sachin Vijaykumar Sonawane

Harvey Eneman

Carlos Ruiz

Mark Rakhmilevich

Darshan Maniyani

Sachin Rathod

Wumengjian Zhu

Lawrence HinLuen To, Jr

Marilyn Anne Pratt

Margaret Susairai

Vishvesh Mohanarangam Selvakumaar

Sivaram Prasad Soma

Jingling Lee

Jr William H Bridge

Neil JS Macnaughton

Juan R Loiza

Kiran B Goyal

Aya Selcuk

Bharat CV Baddepudi

Roger Hansen

Hubert Sun

Feroz A Khan

Michael J Stewart

Replication is improved in a globally distributed database, such as a replicated sharded database, which uses raft-based asynchronous database replication. Improvements include Raft log persistence, coordination of followers' processing speed, transaction outcome determination, and column name compression, and improved failover time through heartbeat consolidation and keeping apply processes of followers running across failovers.

Performance optimization in raft-based asynchronous database transaction replication

Techniques are described herein for an integrated in-front database cache ('IIDC') providing an in-memory, consistent, and automatically managed cache for primary database data. An IIDC comprises a database server instance that (a) caches data blocks from a source database managed by a second database server instance, and (b) performs recovery on the cached data using redo records for the database data. The IIDC instance implements relational algebra and is configured to run any complexity of query over the cached database data. Any cache miss results in the IIDC instance fetching the needed block(s) from a second database server instance managing the source database that provides the IIDC instance with the latest version of the requested data block(s) that is available to the second instance. Because redo records are used to continuously update the data blocks in an IIDC cache, the IIDC guarantees consistency of query results.

Diskless active data guard as cache

A consensus protocol-based replication approach is provided. Chunks are grouped into replication units (RUs) to optimize replication efficiency. Chunks may be assigned to RUs based on load and replication throughput. Splitting and merging RUs do not interrupt concurrent user workload or require routing changes. Transactions spanning chunks within an RU do not require distributed transaction processing. Each replication unit has a replication factor (RF), which refers to the number of copies/replicas of the replication unit, and an associated distribution factor (DF), which refers to the number of servers taking over the workload from a failed leader server. RUs may be placed in rings of servers, where the number of servers in a ring is equal to the replication factor, and quiescing the workload can be restricted to a ring of servers instead of the entire database.

Configuration and management of replication units for asynchronous database transaction replication

A lead-sync log record is used to synchronize the replication logs of follower shards to the leader shard. In response to a failure to determine that there is a consensus for a database transaction commit operation after a shard server becomes a new leader, the new leader shard performs a sync operation using the lead-sync log record to synchronize replication logs of the follower shards to the replication log of the new leader. A shard server identifies a first transaction having a first log record but not a post-commit log record in the replication log, defines a recovery window in the replication log starting at the first log record of the identified first transaction and ending at the lead-sync log record, identifies a set of transactions to be recovered, and performs a recovery action on the set of transactions to be recovered.

Recovery from loss of leader during asynchronous database transaction replication

A consensus protocol-based replication approach is provided. For each change operation performed by a leader server on a copy of the database, the leader server creates a replication log record and returns a result to the client. The leader does not wait for consensus for the change operation from the followers. For a commit, the leader creates a commit log record and waits for consensus. Thus, the leader executes database transactions asynchronously, performs replication of change operations asynchronously, and performs replication of transaction commits synchronously.

Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full SQL support and horizontal scalability

A blockchain object stores multiple user blockchains, each blockchain comprising an ordered set of records in the blockchain object. The records of a user blockchain have the same blockchain key value. Users can create multiple blockchains by establishing respective blockchain key values for the blockchains. Like blocks in a blockchain, the records in a user blockchain are ordered by a sequence of numbers that is specific to the user blockchain; each user blockchain has its own sequence of numbers. Each record in a user blockchain holds a sequence number in a field of the blockchain object. An efficient mechanism maintains and assigns a sequence number to a record when appended to a user blockchain.

User-specified chains and row versions in a blockchain table

In Secure-Asynchronous Signing, when a record is inserted into a collection of records by a user, the user specifies a registered digital certificate to associate with the record. The digital certificate was previously registered by the user. To subsequently sign a record, the user provides a digital signature. The digital signature is validated using data in the record and a public key of the digital certificate that was associated with the row. Invalid digital signatures are detected and rejected regardless of how long afterward the attempt to sign the row occurs after inserting the row.

Deferred and secure data signing

Techniques are described herein for routing queries to particular nodes of a multi-node database system based on the query. A database table is partitioned into a plurality of affinity groups. Each affinity group is assigned a particular node as the master node of the affinity group. A mapping is sent to a query router indicating the master node for each affinity group of the plurality of affinity groups. The query router determines, for a particular query, a target node to which to send the particular query based on the mapping and the particular query.

Routing requests in shared-storage database systems

Techniques herein store database blocks (DBBs) in byte-addressable persistent memory (PMEM) and prevent tearing without deadlocking or waiting. In an embodiment, a computer hosts a DBMS. A reader process of the DBMS obtains, without locking and from metadata in PMEM, a first memory address for directly accessing a current version, which is a particular version, of a DBB in PMEM. Concurrently and without locking: a) the reader process reads the particular version of the DBB in PMEM, and b) a writer process of the DBMS replaces, in the metadata in PMEM, the first memory address with a second memory address for directly accessing a new version of the DBB in PMEM. In an embodiment, a computer performs without locking: a) storing, in PMEM, a DBB, b) copying into volatile memory, or reading, an image of the DBB, and c) detecting whether the image of the DBB is torn.

Persistent memory file store for directly mapped persistent memory database

Herein are high throughput techniques for incorporating cryptographic blockchains into relational data. In an embodiment, a computer indicates, in a database dictionary in a database, that a relational table is for blockchain storage. The relational table contains application column(s). In response to that indication, the relational table is associated with system column(s) that are unmodifiable by administrators and clients of the database. The system column(s) include a cryptographic hash column. A request to store a particular value in a particular application column is received from a client. In response to receiving the request, a cryptographic hash value is calculated for a new row for the relational table. In the relational table, the computer stores the new row that contains: the particular value in the particular application column, and the cryptographic hash value in the cryptographic hash column.

Supporting blockchain collections in a database

A method and an apparatus for implementing a buffer cache for a persistent file system in a non-volatile memory is provided. A set of data is maintained in one or more extents in a non-volatile random-access memory (NVRAM) of a computing device. At least one buffer header is allocated in a dynamic random-access memory (DRAM) of the computing device. In response to a read request by a first process executing on the computing device to access one or more first data blocks in a first extent of the one or more extents, the first process is granted direct read access of the first extent in the NVRAM. A reference to the first extent in the NVRAM is stored in a first buffer header. The first buffer header is associated with the first process. The first process uses the first buffer header to directly access the one or more first data blocks in the NVRAM.

Directly mapped buffer cache on non-volatile memory

Techniques are provided for creating, organizing, and maintaining a sharded database. A sharded database can be created using user-defined sharding, system-managed sharding, or composite sharding. The sharded database is implemented with relational database techniques. The techniques described can be used to route database requests and process queries in a sharded database.

Request routing and query processing in a sharded database

Techniques described herein create a sharding environment from existing independent databases, use the sharding environment to issue cross shard queries, create 'on all shards' new objects, and create and 'on all shards' new users that will have permission to access the data across all database shards.

Integration of existing databases into a sharding environment

Techniques are provided for creating, organizing, and maintaining a sharded database. A sharded database can be created using user-defined sharding, system-managed sharding, or composite sharding. The sharded database is implemented with relational database techniques. The techniques described provide improvements to load distribution, organization, query processing, and schema propagation in a sharded database.

Relational database organization for sharding

A method and apparatus for implementing a buffer cache for a persistent file system in non-volatile memory is provided. A set of data is maintained in one or more extents in non-volatile random-access memory (NVRAM) of a computing device. At least one buffer header is allocated in dynamic random-access memory (DRAM) of the computing device. In response to a read request by a first process executing on the computing device to access one or more first data blocks in a first extent of the one or more extents, the first process is granted direct read access of the first extent in NVRAM. A reference to the first extent in NVRAM is stored in a first buffer header. The first buffer header is associated with the first process. The first process uses the first buffer header to directly access the one or more first data blocks in NVRAM.

Growing community of inventors

Palo Alto, CA, United States of America

Wei-Ming Hu