Abstract: 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.

Abstract: 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.

Abstract: Techniques for automatically selecting a type of vector index are provided. In one technique, in response to determining to generate a vector index based on a base table that stores a plurality of vectors, a number of the plurality of vectors is identified. Based at least on the number of the plurality of vectors, a particular type of vector index is identified from among a plurality of types of vector indexes. Examples of the plurality of types include an HNSW index and an IVF index. A vector index of the particular type is generated for the base table. Another criterion in identifying a type of vector index to generate is the number of neighbors that is a parameter in generating a certain type of vector index.

Abstract: Techniques are described for Transaction Guard to impose at-most-once execution by generating and using the database's native transaction identifier, DB XID. In an implementation, DB XID is unique within a (pluggable) database instance (with local undo) and uniquely identifies a transaction in the database. The Transaction Guard that is extended to use native transaction information determines the commit outcome using the native transaction identifier of the transaction instead of relying on the persistence of the Logical Transaction Identifier (LTXID) in a separate table. Using the native transaction identifier, the Transaction Guard significantly improves performance by eliminating the extra write(s) incurred during commit operations.

Abstract: Herein is an accelerated interface between a database server and a storage area network (SAN). Persistent torage being managed for a database is spread across a number of storage buckets. Global distributed storage metadata is used only for tracking the location of storage buckets on different storage servers. With this approach, a very small amount of memory is needed at a global distributed level to maintain the map. Each storage bucket can have any number of mirrored replicas for further increasing speed and reliability. A database server contains a storage bucket map in memory, and uses the map to do database online transaction processing (OLTP) I/O and smart (i.e. offloaded) database operations on storage. This allows for direct I/O between database server and storage server with lower latency and without using slow and remote middleware such as a logical unit number (LUN) metadata server on a separate network element.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.