Oracle International Corporation

Sunil Parrokkaren Chakkappen

Mohamed Zait

Hong Su

Uri Shaft

Christoforus Widodo

Zhan Li

Benoit Dageville

Thierry Cruanes

Jiaqi Yan

Allison Waingold Lee

Mohamed Ziauddin

Ali Cakmak

Shasank Kisan Chavan

Cetin Ozbutun

David Vengerov

Aurosish Mishra

Suratna Budalakoti

Krishna Kantikiran Pasupuleti

Can Tuzla

Andre Menck

Fatih Emekci

Palash Sharma

Yiqiong Zhang

Automated Index Management entails automated monitoring of query workload in a DBMS to determine a set of higher load queries to use to evaluate new potential indexes. Without the need of user approval or action, the potential indexes are automatically created, evaluated and tested, and then made available for system wide use for executing queries issued by end users. Indexes created by Automated Index Management are referred to herein as auto indexes.

Automated real-time index management

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

Techniques are described for responding to aggregate queries using optimizer statistics already available in the data dictionary of the database in which the database object targeting by the aggregate query resides, without the user creating any additional objects (e.g. materialized views) and without requiring the objects to be loaded into volatile memory in a columnar fashion. The user query is rewritten to produce a transformed query that targets the dictionary tables to form the aggregate result without scanning the user tables. 'Accuracy indicators' may be maintained to indicate whether those statistics are accurate. Only accurate statistics are used to answer queries that require accurate answers. The accuracy check can be made during runtime, allowing the query plan of the transformed query to be used regardless of the accuracy of the statistics. For queries that request approximations, inaccurate statistics may be used so long as the statistics are 'accurate enough'.

Statistics based query transformation

Techniques for processing queries are provided. In one approach, an execution plan for a query includes multiple sub-plans, one or more of which are selected at runtime while one or more other sub-plans are not executed during execution of the execution plan. In another approach, data about misestimate is generated and stored persistently for subsequent queries. In another approach, statistics for a database object are generated automatically and efficiently while the database object is created or data items are added thereto. In another approach, a hybrid histogram is created that includes a feature of frequency histograms and a feature of height-balanced histograms. In another approach, computer jobs are executed in such a way to avoid deadlock. In another approach, changes to a database object trigger a hard parse of a query even though an execution plan already exists for the query.

Creating hybrid and top-frequency histograms

Leveraging query-specific statistics in non-equivalent queries

Techniques are provided for merging (a) statistics associated with data added to a table in a bulk load operation with (b) statistics associated with data that existed in the table before the bulk load operation. The statistics associated with the bulk load data are generated on-the-fly during the bulk load, and are merged with the pre-existing statistics as part of the same transaction that is used to perform the bulk load operation. Consequently, execution plans for queries that are assigned snapshot times after the commit time of the bulk load transaction will be selected based on the new statistics, while execution plans for queries that are assigned snapshot times before the commit time of the bulk load transaction will be selected based on the pre-existing statistics.

Online optimizer statistics maintenance during load

Systems for database system management. A method embodiment commences upon intercepting a feature or command that is issued from a software application that interfaces with a database management system. Rules are used to identify that the feature or command is of a first type (e.g., an older type). The feature or command is analyzed to determine if it is a candidate to be modified or upgraded to implement a newer feature or command of a second type (e.g., a newer type). Modifications are made to the old feature or command of the first type to implement a new feature or command of a second type. The new feature or command of the second type is sent to the database management system for processing.

Database system feature management

Techniques are described for maintaining an expression statistics store that stores and updates metadata values for query expressions based on the occurrence of those query expressions within queries. In an embodiment, a database server instance receives a database query. In response, the database server instance identifies expressions within the database queries. The database server instance then determines whether an expression statistics store includes an entry for the particular expression. Responsive to determining that the expression statistics store includes an entry for the particular expression, the database server instance updates at least one metadata value in the entry based on the occurrence of the particular expression. Responsive to determining that the expression statistics store does not include an entry for the particular expression, the database server instance adds an entry for the particular expression.

Tracking and maintaining expression statistics across database queries

A system performs database management. The system receives a request for a query of a plurality of tables under a join condition on an attribute and determines a uniform mapping that maps a domain of the attribute into a set of numbers, where the domain of the attribute includes all attribute values taken by the attribute in the tables. Then, for a row in a table, the system includes the row into a synopsis of the table if the row includes an attribute value that is mapped by the uniform mapping to a number less than an inclusion probability associated with the table. The system obtains a plurality of synopsis for the tables by repeating the including for all rows in the table and for all tables, and determines, based on the plurality of synopsis, an estimate join size of the tables under the join condition.

One-pass join size estimation with correlated sampling

A table is processed to determine an approximate NDV for a plurality of groups. For each row, a group based is identified based on one or more group-by columns. A hashed valued is generated by applying a uniform hash function to a value in an NDV column. The hashed value is assigned to a particular bucket based on the values at a first set of bit positions in a binary representation of the hashed value. A bit position value is determined based on for a remaining portion of the binary representation of the hashed value. The bit position value is based on a number of ordered bits in the hashed value that match a particular bit pattern. For each group identified, a maximum bit position (MBP) table is generated. The MBP table stores, for one or more buckets, the maximum bit position value determined for hashed values assigned to a particular bucket.

Approximate distinct counting in a bounded memory

Triggering hard parses

Creating and using data that indicates misestimates of actual costs

A table-level histogram is maintained incrementally without requiring rescanning of the entire table when new data values are added to the table. A table has multiple partitions of data values. A histogram for data values of the partitions is generated. When a new partition of data values is added to the table, a histogram for only the new partition is generated. To generate a histogram for the entire table, the histograms for the previously generated and newly added partitions are used without needing to refer to the underlying data. A similar approach is applicable when modifying data values in a partition.

Growing community of inventors

Foster City, CA, United States of America

Sunil Parrokkaren Chakkappen