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.

Abstract: Systems for managing large database systems. Storage devices hold a set of one or more subject database tables that hold subject data accessed by one or more users. A data definition statement to perform a table alteration operation (e.g., a table partition operation) over a particular table in the subject database is received, parsed, and the table alteration operation over the particular table is initiated. During the processing of the data definition statement to complete the table alteration operation, a data manipulation statement to perform a table access operation over the same table is received and parsed. The data manipulation statement is not blocked, even while the table alteration operations are ongoing. Rather, during the time that the table alteration operations are ongoing, the data manipulation statement is processed using hidden tables. After the table alteration operations have completed, incoming data manipulation statements are performed over the altered database tables.

Abstract: A method commences upon receiving a database language statement pertaining to a database comprising database objects that are accessed by computing processes. The method analyzes the database language statement to form or identify a cursor object that has dependencies on one or more referenced data objects. The cursor object is associated with a set of cursor attributes that are stored in a cursor metadata data structure. By analyzing a subsequently-received database language statement, the method determines one or more operations to operate over at least one of the data objects. Rules are applied to the cursor attributes and/or to the operations and/or to objects referenced in the cursor so as to determine whether or not to invalidate the cursor object. The cursor may be considered at a later time for possible later invalidation or revalidation based on processing of later received database language statements and/or based on a later event.

Abstract: Techniques for creating and using partial indexes are provided. A partial index is an index that indexes one or more partitions of a partitioned table and does not index one or more other partitions of the partitioned table. Thus, if a partition of a partitioned table is rarely used, then an index may index all other partitions of the partitioned table or at least only those partitions that are written to or read from relatively frequently. Also, in preparation for loading data into a partition, indexing for the partition may be “turned off”, effectively making a full index a partial index. While the data is loaded into the partition, the partial index is still available for query processing. After the data is loaded into the partition, indexing for the partition is “turned on”, which causes the data in the partition to be indexed by the partial index.

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.