Oracle International Corporation

Adrian Tsz Him Ng

Kothanda Umamageswaran

Krishnan Meiyyappan

Semen Ustimenko

Wei Zhang

Tirthankar Lahiri

Amit Ganesh

Juan R Loaiza

Shasank Kisan Chavan

Jesse Kamp

Dmitry Mikhailovich Potapov

Alexander Tsukerman

Roger MacNicol

Viral Shah

Vijay Sridharan

Xia Hua

Allen Brumm

James Stenoish

Roger Dermot Macnicol

Maria Colgan

Robert K Abbott

Daniel McClary

Yiran Qin

Ke Hu

Xin Zeng

Laura Liaoruo Wang

Roger D Macnicol

Region summaries of database data are stored in persistent memory of a storage cell. Because the region summaries are stored in persistent memory, when a storage cell is powered off and data in volatile memory is not retained, region summaries are nevertheless preserved in persistent memory. When the storage cell comes online, the region summaries already exist and may be used without the delay attendant to regenerating the region summaries stored in volatile memory.

Storing derived summaries on persistent memory of a storage device

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 are provided for storing in in-memory unit (IMU) in a lower-storage tier and copying the IMU to DRAM when needed for query processing. Techniques are also provided for copying IMUs to lower tiers of storage when evicted from the cache of higher tiers of storage. Techniques are provided for implementing functionality of IMUs within a storage system, to enable database servers to push tasks, such as filtering, to the storage system where the storage system may access IMUs within its own memory to perform the tasks. Metadata associated with a set of data may be used to indicate whether an IMU for the data should be created by the database server machine or within the storage system.

Columnar caching in tiered storage

According to embodiments, a derived cache that is derived from a first instance of particular data is used to speed up queries and other operations over a second instance of the particular data. Traditionally, a DBMS generates and uses derived cache data only for the database data from which the derived data was derived. However, according to embodiments, derived cache data associated with a first instance of database data is relocated to the location of a second, newly created, instance of the database data. Since the derived cache data is derived from an identical copy of the database data, the cache data derived for the first instance can successfully be used to speed up applications running over the second instance of the database data.

Relocating derived cache during data rebalance to maintain application performance

Techniques are described herein for generating and using in-memory data structures to represent columns in data block sets. In an embodiment, a database management system (DBMS) receives a query for a target data set managed by the DBMS. The query may specify a predicate for a column of the target data set. The predicate may include a filtering value to be compared with row values of the column of the target data set. Prior to accessing data block sets storing the target data set from persistent storage, the DBMS identifies an in-memory summary that corresponds to a data block set, in an embodiment. The in-memory summary may include in-memory data structures, each representing a column stored in the data block set. The DBMS determines that a particular in-memory data structure exists in the in-memory summary that represents a portion of values of the column indicated in the predicate of the query. Based on the particular in-memory data structure, the DBMS determines whether or not the data block set can possibly contain the filtering value in the column of the target data set. Based on this determination, the DBMS skips or retrieves the data block set from the persistent storage as part of the query evaluation.

Reducing data I/O using in-memory data structures

Growing community of inventors

Redwood City, CA, United States of America

Adrian Tsz Him Ng