Abstract: A method, apparatus and program product are provided for performing a query of a database. A database query is received, which includes first and second operations respectively configured to generate first and second disjoint results sets from a dataspace. The database query is analyzed to identify a set of attributes from the dataspace that are used by at least one of the first and second operations in the database query. During execution of the database query, a plurality of records from the dataspace is iteratively processed in a single pass, including, for each of the plurality of records, processing such record by retrieving the plurality of attributes for such record from the dataspace and performing each of the first and second operations on the record using the retrieved attributes for such record to build the first and second disjoint results sets.

Abstract: Methods, systems, and computer program products are provided for improving the processing of database queries. Some embodiments include detecting an overly long running query execution plan, stopping execution of the plan, and utilizing the query optimizer to select an alternate plan for execution. Embodiments may utilize system timers which are set with a time limit for the first selected plan, with instructions to re-optimize and initiate selection of an alternate plan when the timer times out. Risky constructs may be located in the first plan and removed from future consideration for executing the query. In some embodiments, the additional overhead for non-problem queries consists of little more than creating and sending a message or setting a timer when starting query execution, and canceling a timer upon successful query processing completion. A secondary thread may be created responsive to detecting a long running query, to supervise selecting an alternate execution plan.

Abstract: A query facility for database queries dynamically determines whether selective portions of a database table are likely to benefit from separate query execution strategies, and constructs an appropriate separate execution strategies accordingly. Preferably, the database contains at least one relatively large table comprising multiple partitions, each sharing the definitional structure of the table and containing a different respective discrete subset of the table records. The query facility compares metadata for different partitions to determine whether sufficiently large differences exist among the partitions, and in appropriate cases selects one or more partitions for separate execution strategies. Preferably, partitions are ranked for separate evaluation using a weighting formula which takes into account: (a) the number of indexes for the partition, (b) recency of change activity, and (c) the size of the partition.

Abstract: A query optimizer optimizes a query to a partitioned database table by determining common characteristics of the partitions and generating a virtual maintained temporary index that spans multiple partitions. Using the virtual maintained temporary index allows the query optimizer to generate an access plan based on the virtual maintained temporary index, which relieves the optimizer from having to individually optimize access to each partition for partitions that share common characteristics.

Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation, modification and deletion. An autonomic index mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created, modified or deleted based on the information in the index advice records and the index advice policies. By automating the process of creating, modifying and deleting indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating, modifying and deleting indexes.

Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation. An autonomic index creation mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created based on the information in the index advice records and the index advice policies. By automating the process of creating indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating indexes.

Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation, modification and deletion. An autonomic index mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created, modified or deleted based on the information in the index advice records and the index advice policies. By automating the process of creating, modifying and deleting indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating, modifying and deleting indexes.

Abstract: A stream data node receives real-time streamed data from one or more input devices, dynamically filters the streamed data to reduce the streamed data, and delivers the reduced data when requested. By providing real-time filtering of the data, the amount of data that must be stored in a database may be substantially reduced. The stream data node can perform aggregation functions, group functions, and select functions, thereby also significantly reducing the amount of data that must be stored in a database. The stream data node may also be part of a query execution data structure, where it delivers its data when requested by another node in the query execution data structure.

Abstract: A database query optimizer includes an access plan storage mechanism that stores execution detail corresponding to a query statement in an access plan cache. By storing execution detail in the access plan cache along with the query statement, the execution detail is available when needed to debug database problems, even after a problem occurs. The execution detail stored in the access plan cache may be mined and analyzed after-the-fact, producing a very powerful tool for debugging database problems. Snapshots of the execution detail may also be created by a user. In addition, the user may setup autonomic snapshots and comparisons so that a user may be alerted from a degradation in database performance between two snapshots.

Abstract: A query facility for database queries dynamically determines whether selective portions of a database table are likely to benefit from separate query execution strategies, and constructs an appropriate separate execution strategies accordingly. Preferably, the database contains at least one relatively large table comprising multiple partitions, each sharing the definitional structure of the table and containing a different respective discrete subset of the table records. The query facility compares metadata for different partitions to determine whether sufficiently large differences exist among the partitions, and in appropriate cases selects one or more partitions for separate execution strategies. Preferably, partitions are ranked for separate evaluation using a weighting formula which takes into account: (a) the number of indexes for the partition, (b) recency of change activity, and (c) the size of the partition.

Abstract: An apparatus and method for a multi-partition query governor in a partitioned computer database system. In preferred embodiments a query governor uses data of a query governor file that is associated with multiple partitions to determine how the query governor manages access to the database across multiple partitions. Also, in preferred embodiments, the query governor in a local partition that receives a query request communicates with a query governor in a target partition to accumulate the total resource demands of the query on the local and target partitions. In preferred embodiments, a query governor estimates whether resources to execute a query will exceed a threshold over all or a combination of database partitions.

Abstract: An index advice record engine generates and stores index advice records. An index advice policy mechanism allows a user to define an index advice policy that specifies criteria for autonomic index creation, modification and deletion. An autonomic index mechanism reads the index advice records, compares this information with the criteria in the user-defined index advice policies, and determines whether an index should be created, modified or deleted based on the information in the index advice records and the index advice policies. By automating the process of creating, modifying and deleting indexes according to user-defined policies, the preferred embodiments alleviate human users from most of the work of manually creating, modifying and deleting indexes.

Abstract: Embodiments of the invention provide techniques for aggregating database queries for energy efficiency. In one embodiment, queries received by a DBMS are aggregated and staged according to hard-disk drives required for query execution. Each group of queries accessing a given drive may be dispatched for execution together. Further, the queries received by a DBMS may be matched to patterns of previously received queries. The matching patterns may be used to predict other queries which are likely to be received by the DBMS. The received queries may be staged to be dispatched with the predicted queries. By aggregating queries to be executed, access to each hard-disk drive may be optimized, thus reducing the overall energy consumption required for executing the queries.

Abstract: A method, apparatus and program product to optimize a database query. In a first system having a first dataspace, a query plan is generated for the database query. Remote statistics collection associated with the database query is initiated on a second system having a second dataspace. The remote statistics collection uses the second dataspace, which includes a current copy of at least a portion of the first dataspace on the first system. Database statistics are collected for the first system by analyzing the second dataspace and then communicating the collected database statistics to the first system for use in optimizing database queries executed by the first system.

Abstract: Embodiments of the invention provide techniques for aggregating database queries for energy efficiency. In one embodiment, queries received by a DBMS are aggregated and staged according to hard-disk drives required for query execution. Each group of queries accessing a given drive may be dispatched for execution together. Further, the queries received by a DBMS may be matched to patterns of previously received queries. The matching patterns may be used to predict other queries which are likely to be received by the DBMS. The received queries may be staged to be dispatched with the predicted queries. By aggregating queries to be executed, access to each hard-disk drive may be optimized, thus reducing the overall energy consumption required for executing the queries.

Abstract: An apparatus and method for a multi-partition query governor in a partitioned computer database system. In preferred embodiments a query governor uses data of a query governor file that is associated with multiple partitions to determine how the query governor manages access to the database across multiple partitions. Also, in preferred embodiments, the query governor in a local partition that receives a query request communicates with a query governor in a target partition to accumulate the total resource demands of the query on the local and target partitions. In preferred embodiments, a query governor estimates whether resources to execute a query will exceed a threshold over all or a combination of database partitions.

Abstract: An apparatus and method for a multi-partition query governor in a partitioned computer database system. In preferred embodiments a query governor uses data of a query governor file that is associated with multiple partitions to determines how the query governor manages access to the database across multiple partitions. Also, in preferred embodiments, the query governor in a local partition that receives a query request communicates with a query governor in a target partition to accumulate the total resource demands of the query on the local and target partitions. In preferred embodiments, a query governor estimates whether resources to execute a query will exceed a threshold over all or a combination of database partitions.

Abstract: A method, apparatus, and program product are provided for preserving a query plan cache on a backup system having a dataspace containing a copy of data and a copy of a query plan cache from a production system. An update is initiated of at least a portion of the copy of the data on the backup system with a portion of the data on the production system. A merge is initiated of updated query plans in the query plan cache from the production system with corresponding query plans in the copy of the query plan cache on the backup system. Objects are correlated in the updated query plans in the copy of the query plan cache with the updated copy of the data on the backup system.

Abstract: A database management system maintains a record of queries which can be executed against the database. For a given auxiliary database structure, an advisory function automatically reviews the query record and identifies those queries which might execute with greater efficiency using the auxiliary database structure, presenting analytical information to the user. Preferably, the auxiliary database structure is an index, and the information is used for determining whether to include the index in the database definition. Preferably, a query optimizer records potentially useful indexes when considering multiple alternative database optimizations, and this information is later retrieved to identify queries which would benefit from an index.

Abstract: A method, apparatus, system, and signal-bearing medium that, in an embodiment, determine performance data for query optimization of a query directed to a database table having multiple partitions. The performance data for the query optimization is presented in a user interface, and an option is provided in the user interface to create a non-spanning index for any of the partitions mentioned in the performance data.