Oracle International Corporation

Mohamed Ziauddin

Benoit Dageville

Andrew Witkowski

Mohamed Zait

Dinesh Das

Khaled Yagoub

Karl Dias

You Jung Kim

Yali Zhu

Mark Charles Ramacher

Hong Su

Peter Clayton Belknap

Randall G Bello

James Finnerty

Cetin Ozbutun

Hakan Jakobsson

Sabina Petride

Alex Tsukerman

Zhe Wu

Sankar Subramanian

Sunil Parrokkaren Chakkappen

Leng Leng Tan

Tirthankar Lahiri

Gary C Ngai

Ananth Raghavan

Rafi Ahmed

Vasudha Krishnaswamy

Sujatha Muthulingam

Graham Wood

Gianfranco Putzolu

Shilpa Lawande

William McKenna

Stephen John Vivian

Hermann Baer

William D Norcott

Huagang Li

Angela Amor

Wanli Yang

Sushil Kumar

John Raitto

Gregory Scott Smith

Richard Sarwal

Vishwanath Karra

Praveen T J Kumar

Krishna Kantikiran Pasupuleti

Sreenath Bodagala

Francisco Sanchez

Zhan Li

Janaki Latha Lahorani

Venkatesh Sakamuri

Hsiao-te Su

Ahmed Alomari

Andrew Sc Witkowski

Mikhail Tyulenev

Praveen Tj Kumar

Michael T Ong

Palash Sharma

Yiqiong Zhang

A new type of table join operation, outer semi join (OSJ), is provided, which can be used by an optimizer layer and an execution layer of a database management system (DBMS). OSJ combines the semantics of both left outer-join and semi-join. The concept of an anti-join marker (AJM) is also introduced, which specifies whether a matching row was not found between joined tables for each result row in an OSJ operation. The OSJ operation supports unnesting of a class of disjunctive ANY, ALL, EXISTS, NOT EXISTS, IN, and NOT IN subqueries for execution plan optimization. The disjunction may contain filter predicates. For unnesting, OSJ avoids the need of using a distinct operator on the right table and also supports using inequality (e.g. >, >=, <, <=) in connecting or correlating conditions of subqueries, rather than being limited to equality only.

Outer semi join for disjunctive subquery unnesting

Disclosed is an approach for applying fine-grained hints to obtain optimal control over error handling during query compilation. Using fine-grained hints causes less disruption to the query plans generated by the optimizer as they constrain specific features while retaining scope for the rest of the optimizer functionality. This approach provides a query plan of better quality that avoid errors, particularly in comparison to coarse-grained approaches that restrict processing to earlier database versions or which disables cost-based processing.

Method and system to implement error handling with fine-grained SQL hints

Techniques for automatically preventing execution plan regressions are provided. In one technique, in a first user database session, in response to receiving a first database statement, a first execution plan is generated and, while executing the first execution plan, first performance data that indicates one or more first performance metrics of executing the first execution plan is recorded. In response to receiving a second database statement, where the first execution plan may be used to generate a result for the second database statement, a second execution plan is generated and second performance data that indicates one or more second performance metrics of executing the second execution plan is recorded. A comparison between the first performance data and the second performance data is performed. Based on the comparison, it is determined whether the second execution plan will be stored for future use to process a database statement.

Automatic prevention of plan regressions

Embodiments generate random walks through a directed graph that is represented in a relational database table. Each row of the graph table represents a directed edge in the graph and includes a source vertex and a destination vertex. Each row is further augmented to (a) indicate the number of outbound edges starting from the destination vertex in the row and (b) include an identifier that distinguishes the edge from other outbound edges starting from the same source vertex. An SQL query may be executed on the augmented graph table. Starting from a source vertex (starting vertex or the destination vertex of the previously selected hop) the query randomly selects a row of the graph table representing one of the outbound edges from the source vertex and adds the selected outbound edge as a row in a random walk table that represents the next hop in the random walk.

Efficient SQL-based graph random walk

Techniques for the automatic creation and maintenance of zone maps are provided. In one technique, a set of data sets is identified. For each data set, a data set width is determined based on a maximum value in the data set and a minimum value in the data set. One or more zones within the data set are identified. For each zone, a zone width is determined based on a difference between a maximum value in that zone and a minimum value in that zone. An aggregate zone width is generated that is based on the zone width of each zone. Based on the data set width and the aggregate zone width, it is determined whether to automatically generate a zone map for the data set.

Automatic creation and maintenance of zone maps

Techniques are provided for bitmap-based computation of a COUNT(DISTINCT) function, where the bitmaps are generated based on ranks of target expression values. According to an embodiment, the ranks are computed using the DENSE_RANK function. The bitmaps may be maintained in a materialized view. Bitmap data that represents the ranks for target expression values occurring in data for a given group is divided across multiple bucket bitmaps, each corresponding to a distinct sub-range of the ranks. According to an embodiment, target expression value ranks are computed relative to partitions of the target expression values. When these partitions correspond to a subset (not necessarily strict) of the target query grouping keys for a query rewrite, the resulting bitmaps allow computation of multiple levels of aggregation from the single set of bitmaps.

Densification of expression value domain for efficient bitmap-based count(distinct) in SQL

Techniques are described for storing and maintaining, in a materialized view, bitmap data that represents a bitmap of each possible distinct value of an expression and rewriting a query for a count of distinct values of the expression using the materialized view. The materialized view contains bitmap data that represents a bitmap of each possible distinct value of a first expression, and aggregate values of additional expressions, and is stored in memory or on disk by a database system. The database system receives a query that requests a number of distinct values, of the first expression, and an aggregate value for an additional expression. In response, the database system, rewrites the query to: compute the number of distinct values by counting the bits in the bitmap data of the materialized view that are set to the first value, and obtains the aggregate value for the additional expression in the materialized view.

Bitmap-based count distinct query rewrite in a relational SQL algebra

Techniques are provided for using of zone maps to improve the performance of a much wider range of queries than those for which zone maps are currently used. Specifically, techniques are provided for using zone maps to improve performance of queries by providing aggregate values for a wide range of aggregate operations, including SUM, AVG, etc., providing aggregate values for aggregate queries that specify filter conditions, distinguishing between situations in which the aggregate values for a zone are invalid for pruning purposes and when the aggregate values are invalid for query-answering purposes, determining when aggregate values may be used in multi-table zone maps where the type of join specified by a query differs from the type of join used to generate the aggregate values in the zone map, and selecting among different aggregate values for the same zone based on the type of join specified in a query.

Dual purpose zone maps

Techniques are presented herein for storing cursor duration temporary tables in memory of nodes in a clustered database system in association with iterations of an iterative query operation. The techniques involve associating a portion of memory with one or more iteration values. The iteration values indicate which iterations correspond to data that is stored in the portion of memory. When data is requested for a particular iteration, portions of memory are checked to determine if it stores the particular iteration.

Efficient data retrieval in staged use of in-memory cursor duration temporary tables

Techniques related to efficient data retrieval based on aggregate characteristics of composite tables are provided. A join zone map includes entries that describe data from a join relationship between a first key column of a first table and a second key column of a second table. The first table includes a dimension column. Each entry of the join zone map corresponds to a respective zone. Each zone includes contiguous data blocks that correspond to one or more second key column values. Each entry also includes a respective dimension value range of one or more dimension column values. Each dimension value range includes a respective maximum dimension value and a respective minimum dimension value. Furthermore, each entry includes a respective anti-join attribute value that indicates whether any of the one or more second key column values in a particular zone are non-null and fail to match any first key column values.

Efficient data retrieval based on aggregate characteristics of composite tables

Techniques are described herein for executing queries with a recursive clause using a plurality of processes that execute database operations in parallel. Each process of the plurality of processes either generate or are assigned a segment that is part of a temporary table. For each iteration of the recursive query, work granules are divided up and assigned to each of the plurality of processes. As each respective process produces a portion of a result set for a given iteration, that process appends said portion of the result set to the respective segment that the respective process manages. Each slave process then publishes, to one or more sources, a reference to the newly generated results. During the next iteration, any slave process may access any of the data from the previous iteration.

Parallel execution of queries with a recursive clause

Techniques are described herein to generate and to execute a query execution plan using static data buffering. After receiving a query with a clause that requires multiple iterations to execute, a database management system (DBMS) generates a plurality of plans that vary the order in which the database operations are executed. Within each plan, the DBMS identifies sets of rows within that plan that contain static data during execution of the query. Then, an additional step is added to each plan that includes loading the static set of rows in a database buffer cache. One or more database operations, from an iteration other than the first iteration, may be performed against the cached static set of rows. For each plan generated in this manner, a cost analysis model is applied, and the plan with the lowest estimated computational cost is selected for use as the query execution plan.

Static data caching for queries with a clause that requires multiple iterations to execute

Approaches, techniques, and mechanisms are disclosed for ensuring that a database command is executed according to a query plan that has been verified to be actually optimal. Except in rare circumstances, a database server does not execute a query plan unless it is first verified by the database server. The database server receives a request to execute a database command. The database server determines an unverified plan is the best plan for satisfying the request. Rather than risk the unknown behavior of an unverified plan, the database server instead satisfies the request according to a verified plan. Subsequently&#x2014;for example as part of a scheduled job&#x2014;the database server executes the unverified plan to determine performance statistics. Based at least on the performance statistics, the database server determines whether or not to verify the unverified plan. Techniques for concurrent and optimistic verifications are also disclosed.

SQL execution plan verification

Techniques are provided for generating a 'dimensional zonemap' that allows a database server to avoid scanning disk blocks of a fact table based on filter predicates in a query that qualify one or more dimension tables. The zonemap divides the fact table into sets of contiguous disk blocks referred to as 'zones'. For each zone, a minimum value and a maximum value for each of one or more &#x201c;zoned&#x201d; columns of the dimension tables is determined and maintained in the zonemap. For a query that contains a filter predicate on a zoned column, the predicate value can be compared to the minimum value and maximum value maintained for a zone for that zoned column to determine whether a scan of the disk blocks of the zone can be skipped.

Pruning disk blocks in a relational database management system

Growing community of inventors

Pleasanton, CA, United States of America

Mohamed Ziauddin