Abstract: A method, apparatus, system, and signal-bearing medium that, in an embodiment, start a timer in response to a program encountering a first breakpoint and halt the program at a second breakpoint if the timer exceeds a condition. If the timer does not exceed the condition, the program is resumed. In various embodiments, the condition may be a value retrieved from the program based on a keyword and may further include a threshold. In another embodiment, after the timer exceeds the condition an interrupt is raised and in response the program counter for the program is changed to be a specified statement. In an embodiment, a loop entry breakpoint is set at a loop entry statement in the program, a loop body breakpoint is set at a loop body statement in the program, and a loop exit breakpoint is set at a loop exit statement in the program. A timer is then started for an iteration period in response to the program encountering the loop entry breakpoint.

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, method and program product determines 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 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: A method, apparatus, system, and signal-bearing medium that, in an embodiment, save a problem record associated with a query to a log if the query encountered a problem. The amount of data in the record is increased if an access plan associated with the query has changed within a threshold amount of time and decreased if the access plan has not changed. In various embodiments, the problem may be that the query executes longer than a historical average for the query, the query executes longer than a threshold, or the query encounters a functional error. In an embodiment, a benchmark record associated with the query is also saved to the log, the problem record is compared to the benchmark record, and the difference is presented. In various embodiments, an oldest record is periodically removed from the log, or an oldest record is removed from the log if the associated query has more than a threshold number of records in the log.

Abstract: Methods and apparatus for optimizing an abstract query are disclosed. Embodiments of the present invention allow an abstract database to optimize an abstract query composed from a set of logical fields. Each logical field includes a field name and an access method used to map the logical field to an underlying physical representation of the data. After a user composes an abstract query and submits it for execution, a runtime component and optimization component may be configured to resolve the abstract query to a physical query of the underlying physical data source using an access method associated with each logical field. In addition, as the runtime component builds a query consistent with the schema of the underlying database, an optimizing component may modify the query using any suitable optimization techniques.

Abstract: Mirroring database statistics, including receiving by a backup application of a backup computer a journal entry representing a requirement for backup database statistics and generating by a statistics engine of the backup computer backup database statistics for a backup database in accordance with the journal entry. Mirroring database statistics according to embodiments of the present invention may also include identifying by an original DBMS of an original database a requirement for backup database statistics and inserting in a database journal by the original DBMS the journal entry representing the requirement for backup database statistics.

Abstract: A method for selecting an access plan includes analyzing a plurality of access plans for a particular query and a plurality of low cost access plans for the particular query are identified. Each time a subsequent query, similar to the initial query, is encountered, one of the low cost access plans is executed. In a particular, the low cost access plans may be randomly selected and executed and their execution performance may be monitored to identify an optimal access plan of all the low cost access plans.

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 database monitor tracks performance statistics and information about the execution of different SQL statements. A query optimizer benefits from these statistics when generating an access plan. In particular, the query optimizer, upon receiving an SQL statement, searches the records of the database monitor for similar SQL statements that have previously been executed. As part of determining the best access plan for the current SQL statement, the query optimizer considers the information retrieved from the database monitor. In this way, the access plan that is generated can automatically be tuned based on empirical performance evidence.

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: 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 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 query plan modification system and method relates to a database system that includes a cost-based optimizer for generating access plans. The database system also permits a user to view an access plan that has been generated by a particular SQL query and modify the access plan if desired. The user specifies customizations that are associated with the access plan so that when that plan is executed, the customizations are executed as well. Exemplary customizations include specifying an initialization file specific to a query, specifying different implementation methods than those in the original access plan, prohibiting rebuilding of an access plan, and over-riding or ignoring a clause within the query that is used to generate the access plan.

Abstract: A database query optimizer determines when no optimal index for a query exists, determines whether a sub-optimal index exists, and if so, uses statistical information for each additional key in the sub-optimal index to rewrite the query in a manner that allows traversing the sub-optimal index. The sub-optimal index is then probed using the rewritten query, and the number of estimated returned rows is then used to optimize the query.

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 self-healing database engine and optimizer framework support automatically responding to execution errors to allow continued execution of a query plan. Upon encountering an execution error, the database engine automatically initiates a rebuilding of the query plan and executes the rebuilt execution plan. If an error is encountered in the rebuilt query plan then the query implementation methods are analyzed. If a query function is identified for which an alternative implementation method is available, then this alternative implementation method is substituted to create a new query plan. The new query plan is then executed to determine if the error is corrected.

Abstract: A database engine and optimizer framework support the use of transitive closure to assist in rewriting GROUP BY and ORDER BY clauses to reduce the number of referenced tables (optimally to a single table if possible) and to free the join order selected for the query plan. The SQL parser and optimizer, by performing transitive closure on the selection, or search, conditions is able to identify which fields referenced by the ORDER BY and GROUP BY clauses can be replaced with equivalent fields to improve the performance of the query. In one instance, the fields are replaced so that the ORDER BY or GROUP BY clause references only a single table. If more than one such possible ORDER BY or GROUP BY clause exists, then the optimizer selects from among the different possible clauses to select the one that provides the best performing join order.

Abstract: A method, apparatus, system, and signal-bearing medium that in an embodiment detect that a trigger exists, where the trigger indicates a potential need to rebuild a saved query access plan, and determine whether a previous job associated with the trigger created a new access plan that was identical to the saved access plan. If a previous job associated with the trigger has already created the new access plan and found that it was identical to the saved access plan, then the query is performed with the saved access plan, since there is no advantage to be gained by creating the new access plan again. In this way, multiple jobs are kept from repeatedly re-creating an access plan that is identical to one that already exists.

Abstract: An apparatus, program product and method utilize the retrieval status of a resource to generate an access plan for a database query that uses the resource. The retrieval status, which indicates, for example, what percentage of a given resource is already stored in working memory, and thus need not be separately retrieved during query execution, may be used to generate more accurate input/output cost estimates for access plans, and thus enable a query optimizer to better select an access plan that is optimal under given runtime conditions.