Oracle International Corporation

Juan R Loaiza

Tirthankar Lahiri

Kothanda Umamageswaran

Wei-Ming Hu

Garret Frederick Swart

William Havinden Bridge, Jr

J William Lee

Sumanta Kumar Chatterjee

Jesse Kamp

Alexander Tsukerman

Ajit Mylavarapu

Neil J S MacNaughton

Kiran Badrinarain Goyal

Jia Shi

Vasudha Krishnaswamy

Wei Ming Hu

Alex Tsukerman

Gianfranco Putzolu

Selcuk Aya

Sukhada Pendse

Amit Ganesh

Boris Klots

Mahesh Baburao Girkar

Hideaki Kimura

Kartik Kulkarni

Yunrui Li

Jonathan D Klein

Niloy Mukherjee

Dmitry Mikhailovich Potapov

Krishna Kunchithapadam

Vineet Marwah

Richard L Frank

Neil MacNaughton

Graham Wood

Avneesh Pant

Sashikanth Chandrasekaran

Mark Charles Ramacher

William Bridge

Vinay H Srihari

Allison Holloway

Margaret Susairaj

Sanket Hase

Arvind Nithrakashyap

Aurosish Mishra

Michael J Gleeson

Meichun Hsu

Shasank Kisan Chavan

Namit Jain

Karl Dias

Carol L Colrain

Bipul Sinha

Cetin Ozbutun

Ananth Raghavan

Beda Christoph Hammerschmidt

Alok Pareek

Kam Shergill

Zuoyu Tao

Zhen Hua Liu

Roger J Bamford

James William Stamos

Lakshminarayanan Luxi Chidambaran

Gary C Ngai

Srinath Krishnaswamy

Vivekanandhan Raja

Douglas James McMahon

Mark Dilman

Joydip Kundu

Hui Joe Chang

Srinivas Vemuri

Teck Hua Lee

Venkateshwaran Venkataramani

Ying Lu

Mehul Dilip Bastawala

Atrayee Mullick

Ekrem Soylemez

Jiaqi Yan

Daniel ManHung Wong

Andrew Witkowski

Mohamed Zait

Uri Shaft

Hakan Jakobsson

Michael Zoll

Dheeraj Pandey

Sabina Petride

Krishnan Meiyyappan

Vikram Joshi

Shrikanth Shankar

Ravi Shankar Thammaiah

Michael P Stewart

Sanjay Kaluskar

David Brower

Sujatha Muthulingam

Sankar Subramanian

Kant C Patel

Roger MacNicol

Leonid Novak

Ramesh Kumar

Muthu Olagappan

Paul Youn

Bharat Chandra Baddepudi

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

Disclosed herein are techniques for storing, within a database system, metadata that indicates an intended usage (IU). Once created, an IU may be assigned to a column to (a) indicate how the column is intended to be used, and (b) affect how the database server behaves when database operations involve values from the column. The IU assigned to a column supplements, but does not replace, the datatype definition for the column. Each IU may have an IU-bundle. The IU-bundle of an IU indicates how the database server behaves with respect to any column that is assigned the IU. For example, the IU-bundle may indicate constraints that the database server must validate during operations on values from columns assigned to the IU. Techniques are also described for implementing multi-column IUs and flexible IUs.

Extending database data with intended usage information

JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Natively supporting JSON duality view in a database management system

One or more engine instances are executed on each host to form an engine cluster. A plurality of control instances are executed on a first set of hosts to form a control cluster and comprise a control instance leader and one or more control instance followers. In response to a first host indicating a failure of a neighbor host, a pair-wise focused investigation is initiated to check peer-to-peer connections between the first host and the neighbor host. In response to one or more additional hosts indicating failures of neighbor hosts while the pair-wise focused investigation is being performed, a wide investigation is performed to check connections between the control cluster and the plurality of hosts. One or more hosts are added to an eviction list and an eviction protocol is performed to evict the one or more hosts from the engine cluster using the eviction list.

System and method for transaction continuity across failures in a scale-out database

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

A shared-nothing database system is provided in which parallelism and workload balancing are increased by assigning the rows of each table to 'slices', and storing multiple copies (“duplicas”) of each slice across the persistent storage of multiple nodes of the shared-nothing database system. When the data for a table is distributed among the nodes of a shared-nothing system in this manner, requests to read data from a particular row of the table may be handled by any node that stores a duplica of the slice to which the row is assigned. For each slice, a single duplica of the slice is designated as the “primary duplica”. All DML operations (e.g. inserts, deletes, updates, etc.) that target a particular row of the table are performed by the node that has the primary duplica of the slice to which the particular row is assigned. The changes made by the DML operations are then propagated from the primary duplica to the other duplicas (“secondary duplicas”) of the same slice.

System and method for an ultra highly available, high performance, persistent memory optimized, scale-out database

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 are described for offloading remote direct memory operations (RDMOs) to 'execution candidates'. The execution candidates may be any hardware capable of performing the offloaded operation. Thus, the execution candidates may be network interface controllers, specialized co-processors, FPGAs, etc. The execution candidates may be on a machine that is remote from the processor that is offloading the operation, or may be on the same machine as the processor that is offloading the operation. Details for certain specific RDMOs, which are particularly useful in online transaction processing (OLTP) and hybrid transactional/analytical (HTAP) workloads, are provided.

Same-machine remote direct memory operations (RDMOS)

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 shared-nothing database system is provided in which parallelism and workload balancing are increased by assigning the rows of each table to 'slices', and storing multiple copies ('duplicas') of each slice across the persistent storage of multiple nodes of the shared-nothing database system. When the data for a table is distributed among the nodes of a shared-nothing system in this manner, requests to read data from a particular row of the table may be handled by any node that stores a duplica of the slice to which the row is assigned. For each slice, a single duplica of the slice is designated as the &#x201c;primary duplica&#x201d;. All DML operations (e.g. inserts, deletes, updates, etc.) that target a particular row of the table are performed by the node that has the primary duplica of the slice to which the particular row is assigned. The changes made by the DML operations are then propagated from the primary duplica to the other duplicas (&#x201c;secondary duplicas&#x201d;) of the same slice.

Techniques are described herein for executing queries on distinct portions of a database object that has been separate into chunks and distributed across the volatile memories of a plurality of nodes in a clustered database system. The techniques involve redistributing the in-memory database object portions on changes to the clustered database system. Each node may maintain a mapping indicating which nodes in the clustered database system store which chunks, and timestamps indicating when each mapping entry was created or updated. A query coordinator may use the timestamps to select a database server instance with local in memory access to data required by a portion of a query to process that portion of the query.

Method and mechanism for efficient re-distribution of in-memory columnar units in a clustered RDBMs on topology change

Growing community of inventors

Woodside, CA, United States of America

Juan R Loaiza