Abstract: A method, apparatus, and program product select a pre-started job from among a plurality of pre-started jobs in which to perform a task in a computer system with a NUMA configuration. An attempt to perform a task is received as a connection. Information associated with the connection is compared to information associated with a plurality of pre-started jobs. In response to comparing the information, it is determined either that a pre-started job was previously used to perform the task or that no pre-started job was previously used to perform the task. In response to either determination, another pre-started job is determined in which to perform the task. The other pre-started job is determined based on affinity with the task, and may be reallocated to perform the task.

Abstract: A method, apparatus, and program product select a pre-started job from among a plurality of pre-started jobs in which to perform a task in a computer system with a NUMA configuration. An attempt to perform a task is received as a connection. Information associated with the connection is compared to information associated with a plurality of pre-started jobs. In response to comparing the information, it is determined either that a pre-started job was previously used to perform the task or that no pre-started job was previously used to perform the task. In response to either determination, another pre-started job is determined in which to perform the task. The other pre-started job is determined based on affinity with the task, and may be reallocated to perform the task.

Abstract: A database query optimizer allows specifying a performance specification for a query. When an access plan is created, the actual performance for executing the query using the access plan is determined and compared to the performance specification for the query. If the actual performance does not satisfy the performance specification for the query, the query optimizer autonomically generates a different access plan to see if the performance improves. If an access plan that meets the performance specification is generated, the new access plan is stored in the access plan cache for the query. If no access plan can be generated that meets the performance specification for the query, the access plan that provided the best performance is selected and stored in the access plan cache for the query.

Abstract: A query engine (or optimizer) which supports database queries having user-defined functions maintains historical execution data with respect to each of multiple user-defined functions. The historical execution data is dynamically updated based on query execution performance. When executing a query having user-defined functions, the query engine uses the historical execution data to predict an optimal evaluation ordering for the query conditions and, preferably, to dynamically adjust the evaluation order when appropriate. Preferably, the historical execution data includes historical execution time of the user-defined function and proportion of evaluated records which satisfied the query parameters.

Abstract: An apparatus and program product determine information indicative of a performance differential between operation of a computer with the standby resource activated and operation of the computer with the standby resource inactivated. The information is communicated to a user. The standby resource may be activated in response to the determination.

Abstract: A query facility for database queries saves and re-uses query execution strategies, and automatically detects that a strategy should be re-optimized as a result of changes to an indexed variable value. Preferably, the number of records evaluated and selected by the index value condition is dynamically monitored during execution, and an alternative query strategy is initiated when this number appears to be out of proportion to expectations. In an exemplary embodiment, an indexed search strategy is changed to a table scan strategy (or vice versa) as a result of a change to the number of records eliminated by the indexed value, although other examples are possible. Preferably, the query engine initiates an alternative search strategy and concurrently continues to execute the original search strategy as separate threads. Search results are obtained from whichever thread completes first.

Abstract: A query engine (or optimizer) which supports database queries having user-defined functions maintains historical execution data with respect to each of multiple user-defined functions. The historical execution data is dynamically updated based on query execution performance. When executing a query having user-defined functions, the query engine uses the historical execution data to predict an optimal evaluation ordering for the query conditions and, preferably, to dynamically adjust the evaluation order when appropriate. Preferably, the historical execution data includes historical execution time of the user-defined function and proportion of evaluated records which satisfied the query parameters.

Abstract: An apparatus, program product and method that employ a dynamic use of Look Ahead Predicate Generation that will enable the database, database engine, and/or query optimizer to alter the processing of a query, and react to sub-optimal access plan selection and additional factors arising after processing has begun, to heal many poor performing queries. Conventional use of LPG requires the query optimizer to decide whether or not to use LPG before the processing of a query begins. As a result, the query optimizer may not only make sub-optimal decisions, but the query optimizer may not consider additional factors that may arise as the query is processing. However, the dynamic use of LPG allows predicates to be built after processing of the query has started and the ability to alter the query's processing to improve query performance.

Abstract: An apparatus and program product that utilize at least one prematurely terminated processing of a database query to improve the processing of the database query. The embodiments discussed track termination information associated with at least one user initiated premature termination of processing of a database query to improve the processing of the database query. Information related to the premature terminations of a database query may be utilized by a DBMS to generate and/or implement suggestions to improve the processing of the database query, resulting in improved query processing, improved performance, fewer premature terminations, and more satisfied users.

Abstract: A database management system predicts a selectivity for database query conditions requiring a join of records from different tables. The system identifies at least one skewed value in a field specified in the join condition, and constructs, for each skewed value, a set of hypothetical query predicates in which the field specified in the join condition is replaced with a constant equal to the skewed value. The system then predicts the selectivity for the hypothetical predicates, using any appropriate prediction technique. The selectivities of the hypothetical predicates are used to predict a selectivity for the original query.

Abstract: Building database statistics for use by a query optimizer is beneficial but may over utilize system resources. Accordingly, the frequency that statistics are rebuilt is controlled in order to minimize the effect of the system. In particular, the staleness of the data and the time since the last statistics collection are used to determine whether or not to re-collect statistics. Even for relatively stale data, statistics are not rebuilt until a predetermined time period has passed.

Abstract: An apparatus and program product that build column statistics utilizing at least one skew value. The column statistics built using skew values, instead of column statistics built only through random sampling, may be used to more accurately reflect skew values across join networks, and thus enable a query optimizer to better select an access plan that is optimal under current runtime conditions.

Abstract: A database engine and a system running a database engine utilize a dynamic join reordering feature to change the order of two or more join operations while a query is executing. The database engine starts execution of the query with an initial join order setting but monitors the execution of the query to determine whether the initial join order or some other join order would provide better runtime performance. If another join order would provide better performance, then the database engine can change the join order during query execution and complete the query using the new join order.

Abstract: A database engine and a system running a database engine utilize a dynamic bitmap updating routine to avoid the delay associated with building an entire bitmap. When running a query on a table, the database engine can build a bitmap over a column of the table that helps avoid unnecessary I/O operations to retrieve records. The database engine initializes the bitmap so that all elements have a value of “1”, or active, and proceeds to scan and retrieve the records of the table according to the bitmap using a first process. Any retrieved record is further analyzed to determine if it is part of the result set. Concurrently, a second process is initiated which continually updates the values within the bitmap according to a set of selection criteria. As the first process continues to operate, more and more elements of the bitmap are set to “0”, or inactive, so that the first process can avoid unnecessary I/O operations.

Abstract: A method, apparatus, and program product utilize intelligent job functionality to diagnose an error in a computer. After detecting an error in a first job processing a task, and in response to another attempt to perform the task, a job selection algorithm selects a predetermined job in which to perform the task and diagnose the error. The predetermined job can be the first job or a new job associated with a signature that corresponds to the task that experienced the error. The predetermined job can be used to diagnose the error in a debugging session. Alternately, the first job may enter a debug session immediately after experiencing an error.

Abstract: A database query optimizer creates a main access plan for a query, and also creates one or more subplans for the same query. The subplans are used in executing a query. When a subplan is generated, all tautological predicates (i.e., predicates that do not narrow the query) are dropped, thereby enhancing the reusability of stored subplans. When a query is processed, its tautological predicates are dropped, and if a subplan for the query with the dropped tautological predicates is found, the subplan is used to execute the query. If the query to be run has no main access plan in the cache, a main access plan is generated, and a subplan is also generated that corresponds to the query to be run, with all tautological predicates dropped. The same query may thus generate many subplans, enhancing the reusability of the query by storing each subplan in the access plan cache.

Abstract: A database engine and optimizer framework support creation of a series of profiling indices over a column having character string data, such as a traditional “varchar” data type. The profiling indices result in a reduction of the number of records that are searched when searching for a sub-string match within that column. In some embodiments, the series of indices are created over a column that is typically searched using the LIKE predicate or some similar technique; these indices indicate for each record whether certain sub-strings may exist in that record's value in the column. Thus, the indices are used to find the rows that may match one or more portions of the particular term being queried or, in other words, eliminate those records that do not have at least a portion of the term to be matched. The number of records actually retrieved and searched for the query sub-string is thereby reduced.

Abstract: A number of rows that a recursive query will retrieve from a table is estimated by recursively probing an index associated with the table. A recursive query includes a seed and a recursive predicate, each of which is associated with a respective column in the table. If the index has a leading column that matches the table column associated with the seed, and the index has a secondary column that matches the table column associated with the recursive predicate, then the index is recursively probed until a threshold depth of the recursive probing is reached or until all nodes of the index have been examined. The estimated number of rows that the recursive query will retrieve is then calculated based on either the number of rows examined in the index or based on the threshold depth, a cardinality of the secondary column, and a cardinality of the primary column.

Abstract: A database engine and optimizer framework support creation of a series of profiling indices over a column having character string data, such as a traditional “varchar” data type. The profiling indices result in a reduction of the number of records that are searched when searching for a sub-string match within that column. In some embodiments, the series of indices are created over a column that is typically searched using the LIKE predicate or some similar technique; these indices indicate for each record whether certain sub-strings may exist in that record's value in the column. Thus, the indices are used to find the rows that may match one or more portions of the particular term being queried or, in other words, eliminate those records that do not have at least a portion of the term to be matched. The number of records actually retrieved and searched for the query sub-string is thereby reduced.

Abstract: An apparatus and method to optimize a query access plan in a computer database system. In preferred embodiments, the query optimizer determines the query can be optimized and generates for the query an optimized access plan that eliminates records defined by a Where clause and one or more ordering criteria prior to ordering the records (sorting or grouping) and then returning a first n rows.