Oracle International Corporation

Ramesh Kumar

Ananth Raghavan

George Eadon

Hermann Baer

Suresh Sridharan

Shrikanth Shankar

Amit Ganesh

Juan R Loaiza

Zhen Hua Liu

Tirthankar Lahiri

Vineet Marwah

Shasank Kisan Chavan

Thomas Baby

Jesse Kamp

Niloy Mukherjee

Dheeraj Pandey

Allison Holloway

Vasudha Krishnaswamy

Aurosish Mishra

Mehul Dilip Bastawala

Atrayee Mullick

Krishna Kunchithapadam

Amirali Valiani

Joy Forsythe

Allison L Holloway

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.

Moving data between partitions

An approach for implementing function semantic based partition-wise SQL execution and partition pruning in a data processing system is provided. The system receives a query directed to a range-partitioned table and determines if operation key(s) of the query include function(s) over the table partitioning key(s). If so, the system obtains a set of values corresponding to each partition by evaluating the function(s) on a low bound and/or a high bound table partitioning key value corresponding to the partition. The system may then compare the sets of values corresponding to different partitions and determine whether to aggregate results obtained by executing the query over the partitions based on the comparison. The system may also determine whether to prune any partitions from processing based on a set of correlations between the set of values for each partition and predicate(s) of the query including function(s) over the table partitioning key(s).

Consistent client-side caching for fine grained invalidations

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.

Autonomously partitioning database tables

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.

Dropping an index without blocking locks

Disclosed is a system, method, and computer program product that allows multiple partition schemes to be applied to a single object. Each scheme represents the same set of partitions, but the schemes may have different partition methods, different partition keys, and/or different partition bounds.

Multiple partitioning schemes for partitioned database objects

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_P'. The DBMS then identifies properties of the source partition (e.g., partition P) 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.

Create table for exchange

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.

Non-blocking database table alteration

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.

Highly selective invalidation of database cursors

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.

Partial indexes for partitioned tables

Techniques are described for materializing pre-computed results of expressions. In an embodiment, a set of one or more column units are stored in volatile or non-volatile memory. Each column unit corresponds to a column that belongs to an on-disk table within a database managed by a database server instance and includes data items from the corresponding column. A set of one or more virtual column units, and data that associates the set of one or more column units with the set of one or more virtual column units, are also stored in memory. The set of one or more virtual column units includes a particular virtual column unit storing results that are derived by evaluating an expression on at least one column of the on-disk table.

Materializing expressions within in-memory virtual column units to accelerate analytic queries

Techniques for maintaining a global index in response to a partition being dropped are provided. In response to an instruction to drop a partition, partition identification data that identifies the partition is stored. Index entries, in the global index, that correspond to the dropped partition become 'orphaned' entries. Later, an execution plan for a query is processed, where the execution plan targets a global index. During execution of the execution plan, one or more index entries are accessed. For each accessed index entry, the partition identification data is analyzed to determine if the index entry is an orphaned entry. If so, then the index entry is ignored for purposes of the query. Later, the global index may be updated to delete each orphaned entry. Such deletion may occur much later, such as during a time when the database is not queried or updated frequently.

Asynchronous global index maintenance during partition maintenance

Techniques are provided for processing a CREATE INDEX statement that avoids one or more locks on the underlying table. The processing of such a statement may be divided into a build phase and a cooperation phase. During the build phase, a journal table is created and published. A snapshot of the table is obtained after the last DML transaction (that was pending at the time the journal table was published) commits. The index is built based on the state of the table as of the snapshot. Any changes to the table while the index is built are recorded in the journal table. During the cooperation phase, the index is partially published. A subsequent DML statement determines whether any changes in the journal table affect the same data as the subsequent DML statement. If so, then those changes are applied to the index followed by the subsequent DML statement.

Growing community of inventors

Foster City, CA, United States of America

Ramesh Kumar