Oracle International Corporation

Sukhada Pendse

Tirthankar Lahiri

Juan R Loaiza

Ajit Mylavarapu

Vasudha Krishnaswamy

Vivekanandhan Raja

Amit Ganesh

Vineet Marwah

Garret Frederick Swart

Sanket Hase

Atrayee Mullick

Aurosish Mishra

Shuang Su

Kartik Kulkarni

Ankita Kumar

Solmaz Kolahi

Shasank Kisan Chavan

Yunrui Li

Meichun Hsu

Zhen Hua Liu

Boris Klots

Jesse Kamp

Ananth Raghavan

Douglas James McMahon

Beda Christoph Hammerschmidt

Allison Holloway

Hui Joe Chang

Teck Hua Lee

Hideaki Kimura

Ying Lu

Sundeep Abraham

Shubha Bose

Mahesh Baburao Girkar

Vlad Ioan Haprian

Neil MacNaughton

Marco Arnaboldi

Ioannis Alagiannis

Jing Zheng

Henry Chau

Shruti Gautam

Shashank Gugnani

Agnivo Saha

Rohan Aggarwal

Akshay Kulkarni

Martin Brugnara

Benita Kathleen Britto

Allison L Holloway

Techniques for generating and leveraging a multi-snapshot HNSW index are provided. In one technique, multiple snapshots of an HNSW index that was generated based on a vector table comprising an initial set of vectors are stored. Each of snapshots has a different build time and is associated with a shared journal that stores a plurality of changes to a plurality of vectors in the vector table. A latest snapshot of the plurality of snapshots is identified. The shared journal is identified. It is determined, based on one or more criteria, whether to generate a new snapshot based on the latest snapshot and the shared journal. In another technique, in response to receiving a vector query that is associated with a timestamp, a particular snapshot is selected from the snapshots based on the timestamp. The vector query is executed against the particular snapshot and the shared journal.

Multi-snapshot HNSW index

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 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 related to query execution against an in-memory standby database are disclosed. A first database includes PF data stored on persistent storage in a persistent format. The first database is accessible to a first database server that converts the PF data to a mirror format to produce MF data that is stored within volatile memory. The first database server receives, from a second database server, one or more change records indicating one or more transactions performed against a second database. The one or more change records are applied to the PF data, and a reference timestamp is advanced from a first to a second timestamp. The first database server invalidates any MF data that is changed by a subset of the one or more transactions that committed between the first and second timestamps.

Query execution against an in-memory standby 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.

System and method for high performance multi-statement interactive transactions with snapshot isolation in a scale-out database

Embodiments store transaction metadata in dedicated pools of allocated memory chunks. Portions of the pools of allocated memory chunks are dedicated to the respective apply slave processes that mine and process change records. Also, the pools of allocated memory chunks are anchored within the structure of a transaction log such that buffering and application of metadata for one transaction does not block required buffering and application of metadata for other transactions. The standby database system pre-processes transaction metadata in preparation for application of the metadata to invalidate appropriate portions of MF data. Further, embodiments divide the work of pre-processing invalidation records among the many apply slave processes that record the invalidation records. A garbage collection selects memory chunks for garbage collection in reverse order of how the chunks were allocated. Also, a deduplication algorithm ensures that typically only a single invalidation message per block is applied to invalidate MF data.

Space management for transactional consistency of in-memory objects on a standby database

Techniques are provided for maintaining data persistently in one format, but making that data available to a database server in more than one format. For example, one of the formats in which the data is made available for query processing is based on the on-disk format, while another of the formats in which the data is made available for query processing is independent of the on-disk format. Data that is in the format that is independent of the disk format may be maintained exclusively in volatile memory to reduce the overhead associated with keeping the data in sync with the on-disk format copies of the data.

Mechanism to run OLTP workload on in-memory database under memory pressure

Techniques are herein described for loading a portion of a database object into volatile memory without blocking database manipulation language transactions. The techniques involve invalidating data items loaded from blocks affected by a transaction, referred to as a straddling transaction that started before the load time and committed after the load time. Identifying these straddling transactions involves reviewing one or more transaction lists associated with the set of data items loaded in memory. The transaction list may be read in reverse temporal order of commit to identify a transaction meeting the criteria of starting before the load start, not committing before the load time, and affecting a data item loaded in memory.

Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object

Multi-version concurrency control on in-memory snapshot store of oracle in-memory database

Growing community of inventors

Foster City, CA, United States of America

Sukhada Pendse