Oracle International Corporation

Dmitry Mikhailovich Potapov

Juan R Loaiza

Cetin Ozbutun

Amit Ganesh

Hakan Jakobsson

Alexander Tsukerman

Kirk A Bradley

Mark D Callaghan

Jonathan D Klein

Kothanda Umamageswaran

Krishnan Meiyyappan

J William Lee

Margaret Susairaj

Alok Pareek

Wei Ming Hu

Umesh Panchaksharaiah

Poojan Kumar

Yiu Woon Lau

Francisco Sanchez

Alexander Hwang

Shen-Ban Meng

Wei Zhang

Tirthankar Lahiri

Sumanta Kumar Chatterjee

Gary C Ngai

Bipul Sinha

William Bridge

David Vengerov

Sanjay Kaluskar

Neil MacNaughton

Bharat Chandra Baddepudi

Adam Y Lee

Vipin Gokhale

Steven Wertheimer

Dmitri Bronnikov

Nilesh Choudhury

Wanli Yang

Adrian Tsz Him Ng

Allen Brumm

Vishwanath Karra

Semen Ustimenko

Adrian Ng

James Stenoish

Varun Malhotra

Rosanne Park Toohey

Robert K Abbott

Daniel McClary

Johnny Quan Zhou

Consistent External Table Access maintains transactional consistency for queries that access external tables stored in a DBFS. This ability is achieved by bypassing the OS. One or more database processes executing a query that access an external table stored in a DBFS access the database-file table like other database tables in the DBMS that can be accessed to execute a query. Based on metadata stored in the DBMS regarding how an external table is stored in a DBFS, a DBMS is able to marshal database processes that access database-file tables directly to execute a query.

Transactional query processing in external tables

A storage system communicatively coupled to a database management system (DBMS performs storage-side scanning of data sources that are not stored in native database storage format of the DBMS. Data sources for external tables are accessible in a storage system referred to as a distributed data access system (DDAS), e.g. a Hadoop Distributed File System. To execute a query that references an external table, a DBMS first generates an execution plan. The DDAS supplies the DBMS with information that specifies each portion of the data source, and specifies which data node to use to access the portion. The DBMS sends a request for each portion to the respective data node, requesting that the data node generate rows from data in the portion. The request may specify scanning criteria, specifying one or more columns to project and/or filter on, and code modules for the data node to execute to generate records.

Storage-side scanning on non-natively formatted data

Techniques for optimizing a query with an extrema function are provided. In main memory, a data summary is maintained for a plurality of extents stored by at least one storage server. The data summary includes an extent minimum value and an extent maximum value for one or more columns. A storage server request is received, from a database server, based on a query with an extrema function applied to a particular column of a particular table. The data summaries for a set of relevant extents are processed by maintaining at least one global extrema value corresponding to the extrema function and, for each relevant extent of the set of relevant extents, determining whether to scan records of the relevant extent based on at least one of the global extrema value and an extent summary value of the data summary of the relevant extent.

Optimizing a query with extrema function using in-memory data summaries on the storage server

Techniques are provided for managing cached data objects in a mixed workload environment. In an embodiment, a database system receives request to access a target data object. The database system determines whether the request to access the target data object is associated with a first type of workload or a second type of workload. In response to determining that the request is associated with the first type of workload, the target data object replaces a least recently used data object in a cache. In response to determining that the request is associated with the second type of workload, the target data object is cached based on an associated access-level value.

Caching large objects in a computer system with mixed data warehousing and online transaction processing workload

Processing resources at a storage system for a database server are utilized to perform aspects of a join operation that would conventionally be performed by the database server. When requesting a range of data units from a storage system, the database server includes join metadata describing aspects of the join operation for which the data is being requested. The join metadata may be, for instance, a bloom filter. The storage system reads the requested data from disk as normal. However, prior to sending the requested data back to the storage system, the storage system analyzes the raw data based on the join metadata, removing a certain amount of data that is guaranteed to be irrelevant to the join operation. The storage system then returns filtered data to the database server. The database system thereby avoids the unnecessary transfer of certain data between the storage system and the database server.

Hash join using collaborative parallel filtering in intelligent storage with offloaded bloom filters

In a consumer-producer distributed model of computing, consumers request data from producers and perform computing work on the data received from the producers, thereby transforming the data. At least some of the computing work performed by a consumer on data provided by the producer is commutable between the consumer and producer, that is, either the producer as well as the consumer can perform the computing work on the data. A producer redistributes commutable based on the work load of the producer and consumer as well as other factors.

Redistributing computation work between data producers and data consumers

A method, device, and computer readable medium for striping rows of data across logical units of storage with an affinity for columns is provided. Alternately, a method, device, and computer readable medium for striping columns of data across logical units of storage with an affinity for rows is provided. When data of a logical slice is requested, a mapping may provide information for determining which logical unit is likely to store the logical slice. In one embodiment, data is retrieved from logical units that are predicted to store the logical slice. In another embodiment, data is retrieved from several logical units, and the data not mapped to the logical unit is removed from the retrieved data.

Storing row-major data with an affinity for columns

Key conditioning involves the construction of a byte orderable array from values for a possibly multi-field key concatenated key, for comparison by a sort routine. Byte-orderable sort keys are conditioned prior to execution of a sort routine, to facilitate an accurate and/or efficient sort procedure. Key conditioning may be applied to values in one or more columns of a database table, where the column(s) are used as keys for sorting rows of the table. Six factors are considered in encoding the byte array, such as whether nulls compare high or low; whether a field is fixed width or variable width; whether a field is guaranteed to be not null; whether a field is ordered ascending or descending; whether a field is the last field of a multi-field sort key or the only field of a sort key; and whether a field is likely to contain a significant number of zero values.

Encoding data to be sorted

After receipt of an instruction (e.g. a database statement), one or more computers specialize an interpreter with the received instruction as constant, to obtain a specialized interpreter that is stored in memory and/or disk. The specialized interpreter is then invoked to execute the received instruction. Depending on the embodiment, the interpreter being specialized may additionally be received and used in binary form without specialization. Specifically, in some embodiments, an identical interpreter is received in two forms: in a binary language specific to the one or more computers and also in a language that is acceptable to a specializer, such as a source language or an intermediate language. The interpreter in the binary language is invoked by default unless a predetermined condition for specialization is met. When the predetermined condition is met, the interpreter in the specializer-acceptable language is specialized by the specializer, and then the specialized interpreter is invoked.

Generation of machine code for a database statement by specialization of interpreter code

Stored data are transported between different systems having different platforms by converting the format of the stored data into a common format either before or after transmitting the stored data from the source database system to the target database system. The common format may be a format that is universal in that the common format is not machine dependent. The stored data may be kept in the common format at the target database system and never converted to another format. Optionally, the stored data may be converted from the common format to a format associated with the target database system, thereby facilitating backward compatibility. A tool may be provided for performing the conversion.

Cross platform transportable tablespaces

Database operation-aware striping technique

A method, system, and computer program product for cost based analysis for data access in a database management system. In one approach, the method, system, and computer program product identifies data to access. A first cost for direct I/O storage access and a second cost for cache access are then determined for accessing the data. A comparison between the first cost and the second cost is then performed. Finally, a first portion of identified data is accessed based at least in part upon the comparison.

Cost based analysis of direct I/O access

Growing community of inventors

Emerald Hills, CA, United States of America

Dmitry Mikhailovich Potapov