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: Techniques for partitioning an inverted file (IVF) vector index in a database system are provided. In one technique, a partitioned IVF index is generated based on vectors in a base table using the following process. First, a first clustering technique is performed on vectors in a first subset of the base table. Such clustering results in a first plurality of clusters of vectors. For each cluster, a centroid of that cluster is identified, the centroid is stored in a first partition of a centroids table of the partitioned IVF index, the vectors in that cluster are stored in a first subpartition of a clusters table of the partitioned IVF index (where the first subpartition corresponds to the first partition of the centroids table), and a first association is stored between the centroid and the first subpartition. This clustering repeats for each subset of the base table.

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: Techniques are provided for moving data between partitions. Such a process may be performed without requiring any locks that block transactions that target a partition from being executed. Instead, such transactions may proceed while a move operation is being performed. The move operation involves copying data from the targeted partition to another partition that is hidden from (or “invisible” to) those transactions that attempt to read from or write to the partition. During the move operation, changes that are made to the partition are also reflected in a journal. Eventually, the changes reflected in the journal are drained and applied to the hidden partition. Once the partition and the hidden partition are synchronized, the identities of the partitions are swapped so that future transactions will target the previously-hidden partition instead of the previously-viewable partition.

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: What is disclosed is an improved approach to perform automatic partitioning, without requiring any expertise on the part of the user. A three stage processing pipeline is provided to generate candidate partition schemes, to evaluate the candidate using real table structures that are empty, and to then implement a selected scheme with production data for evaluation. In addition, an improved approach is described to perform automatic interval partitioning, where the inventive concept implements interval partitioning that does not impose these implicit constraints on the partition key column.

Abstract: Techniques for processing “destructive” database statements are provided. Destructive database statements, when processed, cause metadata of a database object to be changed. Examples of such database statements include ones that delete an index, that set a column as unused, and that drop a constraint on a column. When such a statement is received, a change is made to metadata of a database object. Such a metadata change may involve setting an index as unusable, disabling a constraint, or invalidating a cursor. After the metadata change, a first time is determined. Then, it is determined when one or more database transactions that were pending at the first time have committed. After those database transaction(s) have committed, one or more operations are performed, such as dropping an index or dropping a constraint.

Abstract: In an in-memory database management system, non-volatile random access memories (NVRAMs) are used to store database data and control data. Because this data is stored in NVRAM, the data survives system failures. Recovery from a system failure may be accomplished more quickly by, at least in part, modifying the surviving data in NVRAM, rather than loading an entire checkpoint image and applying uncheckpointed transactions needed to synchronize the database. Because in this form of recovery the database state that serves as the starting point for applying change records is the database as stored in the NVRAM, this form of recovery is referred to herein as in-memory-based recovery. Recovery, where the database state that serves as the starting point for applying change records is a checkpoint image, is referred to herein as checkpointed-based recovery. In-memory-based recovery eliminates or reduces the need to perform certain operations that are performed for checkpointed-based recovery.

Abstract: Techniques are provided for moving data between partitions. Such a process may be performed without requiring any locks that block transactions that target a partition from being executed. Instead, such transactions may proceed while a move operation is being performed. The move operation involves copying data from the targeted partition to another partition that is hidden from (or “invisible” to) those transactions that attempt to read from or write to the partition. During the move operation, changes that are made to the partition are also reflected in a journal. Eventually, the changes reflected in the journal are drained and applied to the hidden partition. Once the partition and the hidden partition are synchronized, the identities of the partitions are swapped so that future transactions will target the previously-hidden partition instead of the previously-viewable partition.

Abstract: Techniques are provided for moving data between partitions. Such a process may be performed without requiring any locks that block transactions that target a partition from being executed. Instead, such transactions may proceed while a move operation is being performed. The move operation involves copying data from the targeted partition to another partition that is hidden from (or “invisible” to) those transactions that attempt to read from or write to the partition. During the move operation, changes that are made to the partition are also reflected in a journal. Eventually, the changes reflected in the journal are drained and applied to the hidden partition. Once the partition and the hidden partition are synchronized, the identities of the partitions are swapped so that future transactions will target the previously-hidden partition instead of the previously-viewable partition.

Abstract: What is disclosed is an improved approach to perform automatic partitioning, without requiring any expertise on the part of the user. A three stage processing pipeline is provided to generate candidate partition schemes, to evaluate the candidate using real table structures that are empty, and to then implement a selected scheme with production data for evaluation. In addition, an improved approach is described to perform automatic interval partitioning, where the inventive concept implements interval partitioning that does not impose these implicit constraints on the partition key column.

Abstract: A database engine performs row filtering operations concurrently with performing database object partition maintenance operations. The filtering operations do not incur the high processing costs of database delete or purge operations that would incur per row costs for logging, locking, etc. The partitioning and filtering operations are specified in multiple clauses of a single database language statement. The clauses of the statement are executed concurrently. A method implementation receives a database language statement that comprises a partitioning operation specification as well as a filtering operation specification that includes a logical predicate for determining whether or not to filter-out predicate-matching entries when forming the resulting partitioned target database object. While processing the partitioning operations, the method discards entries taken from the source database object whenever the entry corresponds to the logical predicate.

Abstract: Techniques for processing “destructive” database statements are provided. Destructive database statements, when processed, cause metadata of a database object to be changed. Examples of such database statements include ones that delete an index, that set a column as unused, and that drop a constraint on a column. When such a statement is received, a change is made to metadata of a database object. Such a metadata change may involve setting an index as unusable, disabling a constraint, or invalidating a cursor. After the metadata change, a first time is determined. Then, it is determined when one or more database transactions that were pending at the first time have committed. After those database transaction(s) have committed, one or more operations are performed, such as dropping an index or dropping a constraint.

Abstract: Techniques for processing “destructive” database statements are provided. Destructive database statements, when processed, cause metadata of a database object to be changed. Examples of such database statements include ones that delete an index, that set a column as unused, and that drop a constraint on a column. When such a statement is received, a change is made to metadata of a database object. Such a metadata change may involve setting an index as unusable, disabling a constraint, or invalidating a cursor. After the metadata change, a first time is determined. Then, it is determined when one or more database transactions that were pending at the first time have committed. After those database transaction(s) have committed, one or more operations are performed, such as dropping an index or dropping a constraint.

Abstract: Techniques are described herein for creating a new database table for an exchange operation with a table partition of another table. A database management system (DBMS) is configured to receive a query such as “CREATE TABLE new_table FOR EXCHANGE FROM partition_P1”. The DBMS then identifies properties of the source partition (e.g., partition P1) and creates a new database table based on the properties identified. Some of these properties (e.g., hidden columns, data modeling frameworks, and table statistics) may not otherwise be directly accessible by the external entity that sent the query. The newly created table then has all of the necessary properties to be part of the other table if swapped with the source partition in an exchange operation.

Abstract: In an in-memory database management system, non-volatile random access memories (NVRAMs) are used to store database data and control data. Because this data is stored in NVRAM, the data survives system failures. Recovery from a system failure may be accomplished more quickly by, at least in part, modifying the surviving data in NVRAM, rather than loading an entire checkpoint image and applying uncheckpointed transactions needed to synchronize the database. Because in this form of recovery the database state that serves as the starting point for applying change records is the database as stored in the NVRAM, this form of recovery is referred to herein as in-memory-based recovery. Recovery, where the database state that serves as the starting point for applying change records is a checkpoint image, is referred to herein as checkpointed-based recovery. In-memory-based recovery eliminates or reduces the need to perform certain operations that are performed for checkpointed-based recovery.

Abstract: Techniques are described herein for creating a new database table for an exchange operation with a table partition of another table. A database management system (DBMS) is configured to receive a query such as “CREATE TABLE new_table FOR EXCHANGE FROM partition_P1”. The DBMS then identifies properties of the source partition (e.g., partition P1) and creates a new database table based on the properties identified. Some of these properties (e.g., hidden columns, data modeling frameworks, and table statistics) may not otherwise be directly accessible by the external entity that sent the query. The newly created table then has all of the necessary properties to be part of the other table if swapped with the source partition in an exchange operation.