Google Inc.

Oracle International Corporation

Anjan Kumar Amirishetty

Viral Shah

Xun Cheng

Xiaobin Ma

Yunrui Li

Wilson Wai Shun Chan

Tolga Yurek

Simhachala Sasikanth Gottapu

Anthony Hsu

Haoyu Huang

Niranjan Nilakantan

Junjie Liang

Aspects of the disclosure are directed to a parallel recovery mode that applies log records while allowing read queries on read-replica databases. The parallel recovery mode can include applying log records in log sequence number (LSN) order for a block or for multiple blocks, and managing log records affecting multiple blocks. The parallel recovery mode can further manage dependency between different log records and maintain transactional consistency on read queries.

Technique for parallel recovery on read replica

A hybrid query execution plan is generated for executing queries on database systems implementing a columnar cache. A hybrid query execution plan combines a query execution plan for querying and retrieving data from a columnar cache and a base table. A columnar cache stores cached data in column-major format, which is logically represented by the database management system in row-major format. A database management system as described herein can scan valid blocks of column data according to a column scan operation. The system can identify invalidated blocks and execute a different sub-execution plan of the hybrid query execution plan to scan corresponding rows in tables corresponding to the location of data for the invalidated blocks.

Columnar cache query using hybrid query execution plan

Aspects of the disclosure are directed to maintaining transaction consistency when using a columnar cache. The columnar cache can be initially loaded with all-visible data, and as the data gets modified, respective data is invalidated in the columnar cache. As more data gets invalidated in the columnar cache, respective data can be refreshed in the columnar cache. As part of the refresh, the latest all-visible data can be populated while the queries are still using the old data in the columnar cache. When all the queries transition to use the newly populated data, old data can be removed from the columnar cache. A query can use valid blocks of columnar cache and go to a row store for invalid blocks. When a query starts to use the columnar cache, a request can be submitted to asynchronously prefetch the invalid blocks from the row store.

Maintaining transactional consistency in columnar engine

Aspects of the disclosure are directed to late materialization of attributes in response to queries to a database implementing a database cache. Queried data is materialized in temporary memory before the data is projected as part of generating a result to the query. Instead of materializing all of the attributes referenced in a query before executing the query, a database management system materializes attributes as 'late' as possible—when the operation needing the attributes is executed. The operation needing the attributes can be performed sooner, as opposed to materializing all referenced attributes are materialized before executing the query.

Late materialization of queried data in database cache

A method for providing elastic columnar cache includes receiving cache configuration information indicating a maximum size and an incremental size for a cache associated with a user. The cache is configured to store a portion of a table in a row-major format. The method includes caching, in a column-major format, a subset of the plurality of columns of the table in the cache and receiving a plurality of data requests requesting access to the table and associated with a corresponding access pattern requiring access to one or more of the columns. While executing one or more workloads, the method includes, for each column of the table, determining an access frequency indicating a number of times the corresponding column is accessed over a predetermined time period and dynamically adjusting the subset of columns based on the access patterns, the maximum size, and the incremental size.

Elastic columnar cache for cloud databases

Aspects of the disclosure provide for natively executing row-store expression data structures on column-store databases without rewriting. A database management system (DBMS) configured as described herein can maintain a mapping of row-store results to addresses of where corresponding column data is stored. When executing operators, such as logical operators, comparison operators, and/or function operators of a received query expression, the DBMS can operate on the column data, rather than the individual rows. The DBMS can store the results generated by executing the column operators, for example on a stack, and record the row-store addresses to which the stored results correspond. The DBMS responds with a number of rows corresponding to the processed column data.

Evaluating row-store expressions on a column-store database

Aspects of the disclosure are directed to generating a hybrid query execution plan for executing queries on database systems implementing a columnar cache. A hybrid query execution plan combines a query execution plan for querying and retrieving data from a columnar cache and a base table. A columnar cache stores cached data in column-major format, which is logically represented by the database management system in row-major format. A database management system as described herein can scan valid blocks of column data according to a column scan operation. The system can identify invalidated blocks and execute a different sub-execution plan of the hybrid query execution plan to scan corresponding rows in tables corresponding to the location of data for the invalidated blocks.

Techniques related to instance recovery using Bloom filters are disclosed. A multi-node node database management system (DBMS) includes a first database server instance and a second database server instance. A recovery set includes a set of data blocks that have been modified by a first database server instance and not persisted. A Bloom filter is generated to indicate whether data blocks are excluded from the recovery set. The Bloom filter is sent to the second database server instance, which determines whether the Bloom filter indicates that a particular data block is excluded from the recovery set. Based on determining that the Bloom filter indicates that the particular data block is excluded from the recovery set, access to the particular data block is granted.

Instance recovery using bloom filters

Techniques are described herein for quick identification of a set of units of data for which recovery operations are to be performed to redo or undo changes made by the failed node. When a lock is requested by an instance, lock information for the lock request is replicated by another instance. If the instance fails, the other instance may use the replicated lock information to determine a set of data blocks for recovery operations. The set of data blocks is available in memory of a recovery instance when a given node fails, and does not have to be completely generated by scanning a redo log.

Growing community of inventors

Fremont, CA, United States of America

Anjan Kumar Amirishetty