Oracle International Corporation

Amazon Technologies, Inc.

Atrayee Mullick

Sanket Hase

Amit Ganesh

Vineet Marwah

Vivekanandhan Raja

Sukhada Pendse

Shuang Su

Alexandre Olegovich Verbitski

Dhruva Ranjan Chakrabarti

Yingjie He

Saraswathy Narayan

Juan R Loaiza

Tirthankar Lahiri

Gopi K Attaluri

Niloy Mukherjee

Tengiz Kharatishvili

Neil MacNaughton

Damien Katz

Jesse Kamp

Dieter Gawlick

Bipul Sinha

George Eadon

Allison Holloway

Srinivas Vemuri

Sujatha Muthulingam

Ramesh Kumar

Michael J Gleeson

Mehul Dilip Bastawala

Suhas Keshavamurthy

Huawei Wang

Jianguo Wang

Transaction statements may be forwarded for a database transaction. A transaction begun at a read-only node may include a write statement. The read-only node may forward the write statement to the read-only node to perform as a transaction. The read-only node may update a read view for the transaction to include the write statement before performing a read statement submitted after the write statement at the read-only node.

Selective forwarding for multi-statement database transactions

Database commands may be asynchronously forwarded between nodes of a database system. A read-only node may receive a request, such as a read request or write request, and determine that the request should be forwarded to a read-only node for performance. A thread that handles the request may forward the request to the read-only node and register a call-back event for a response to the request and be made available to perform other work. When the response from the read-write node is received, the call-back event may be triggered and return a response to the request using the same or different thread.

Asynchronously forwarding database commands

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

Automatic consistency is implemented for forwarding writes in a database system. A read-only node may support both read and write requests to a database. The read only node may forward write requests to a read-write node. The read-only node may determine whether to include the forwarded requests in a version of the database for a read request automatically according to a consistency specified for a read request.

Automatic consistency for database write forwarding

Techniques for non-disruptive versioning of in-memory units in a database are provided. A database server generates and maintains a first IMU that reflects changes made to a mirrored-data-set up to a first snapshot time, and a second IMU that reflects changes made to the mirrored-data-set up to a second snapshot time. During a first period, the database server responds to updates to first data items in the mirrored data by storing first staleness metadata that indicates that the copies of the first data items in the first IMU are stale. During a second period, the database server responds to updates to second data items in the mirrored data by storing second staleness metadata that indicates that the copies of the second data items in the second IMU are stale. The database server responds to a request by accessing the first IMU or the second IMU.

Versioning and non-disruptive servicing of in-memory units in a 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 described for maintaining coherency of a portion of a database object populated in the volatile memories of multiple nodes in a database cluster. The techniques involve maintaining a local invalidation bitmap for chunks of data stored in memory in each particular node in the cluster by tracking locks granted by a lock manager. During a pre-loading operation, each given node requests a set of shared locks associated with the chunks of data to be store in the given node's memory. When a request to release one of these shared locks occurs, the in-memory copy of those data items may be invalidated in the node releasing its shared lock.

Maintaining cross-node coherence of an in-memory database object in a multi-node database cluster

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

To prioritize repopulation of in-memory compression units (IMCU), a database server compresses, into an IMCU, a plurality of data units from a database table. In response to changes to any of the plurality of data units within the database table, the database server performs the steps of: (a) invalidating corresponding data units in the IMCU; (b) incrementing an invalidity counter of the IMCU that reflects how many data units within the IMCU have been invalidated; (c) receiving a data request that targets one or more of the plurality of data units of the database table; (d) in response to receiving the data request, incrementing an access counter of the IMCU; and (e) determining a priority for repopulating the IMCU based, at least in part, on the invalidity counter and the access counter.

Prioritizing repopulation of in-memory compression units

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

Techniques are disclosed for creating and using a filter index in order to identify registered queries whose result sets are likely to have been changed by changes made to tables. The filter index entries are based on filter conditions. The filter conditions are created based on predicates contained in the registered queries. The filter conditions may include exclusive predicates and join predicates. Join predicates that join a table Twith a table Tmay be instantiated by replacing references to table Twith values extracted from table T. Various techniques are described for recognizing situations in which a query can be included in, or excluded from, the set of likely-changed queries, without fully evaluating the filter conditions that correspond to the queries.

Adaptive filter index for determining queries affected by a DML operation

Growing community of inventors

Santa Clara, CA, United States of America

Atrayee Mullick