International Business Machines Corporation

Shantan Kethireddy

Robert J Bestgen

Ulrich Thiemann

Andrew Peter Passe

Wei Hu

Michael Steven Faunce

Brian Robert Muras

Henry E Calzaretta

Robert Victor Downer

Jeffrey Wayne Tenner

Jason Arnold

David Glenn Carlson

Dylan S Murphy

Timothy P Winkler

Mark John Anderson

Robert Douglas Driesch, Jr

Gary W Crupi

Michael W Cain

Edward J Miller

John Matthew Santosuosso

Daniel Beuch

Michael D Pfeifer

Kevin James Kathmann

Ruiping Li

Scott Forstie

Thomas Owen McKinley

James Michael Flanagan

Curtis Neal Boger

Annita Tomko

Andres Gonzalez, Jr

Stephanie A Foege

Meryl Lo

David R Trotter

Technical solutions are described for determining data replication cost for a data server. In an example, a method for estimating the data replication cost includes receiving an identification of a source table and an identification of a target table for the data replication. The method further includes receiving a selection of a data replication scheme to be used to replicate the data. A costing system that implements the method determines the data replication cost, based on a conversion cost for conversion of the data from the source table to the target table, and a transfer cost for transfer of the data from the source table to the target table. The costing system communicates the data replication cost to an administrator.

Determining data replication cost for cloud based application

Aspects include obtaining a pattern that describes an event in a natural language format. The pattern that describes the event is converted into at least one identified pattern key value pair. A database transaction is monitored and converted into a least one database transaction key value pair. A similarity score is calculated by scoring similarities between the identified pattern key value pair(s) and the database transaction key value pair(s). Based on similarity score meeting a threshold, an alert is output to indicate that the database transaction matches the pattern that describes the event.

Real-time pattern matching of database transactions and unstructured text

A central relational database management system (RDBMS) is operatively interconnected to one or more back-end database systems. A set of different query criteria specified for each of different types of queries for a mixed query workload is evaluated. At least one remote derived source of data requested by at least one of the different types of queries is dynamically created using at least one of the one or more back-end database systems that supports remote processing of the at least one of the different types of queries.

Runtime creation of remote derived sources for query offload

A system, method and program product for providing latency management for use with a database management system. A system is disclosed having: a system for capturing and storing a maximum latency (ML) whenever a derived source is created from a source data; a system for determining a difference between a last refresh timestamp of the source data and the last refresh timestamp of the derived source in response to a query; and a system for causing the source data to be used in response to the difference being greater than the ML, and for causing the derived source to be used in response to the difference being less than the ML.

Latency management and advising tool for a database management system

Methods, systems, and products are provided for code path tracking. Embodiments include identifying an instrumented trace point in software code to be path tracked; identifying a function executed at the instrumented trace point in the software code; identifying parameters for the function executed at the instrumented trace point; and recording a description of the function, the parameters, and the result of the execution of the function using the parameters.

Code path tracking

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.

Multiple result sets generated from single pass through a dataspace

Embodiments of the invention provide techniques for optimizing database queries for energy efficiency. In general, a query optimizer is configured to compare energy requirements of query plans, and to select a query plan requiring minimal energy to execute. In one embodiment, the query optimizer may also compare time performance of the query plans, and may select a query plan by matching to a user preference for a relative priority between energy requirements and time performance.

Organizing databases for energy efficiency

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.

Dynamically associating different query execution strategies with selective portions of a database table

A qualitative resource assignment wizard receives qualitative information for a logical partition (LPAR) and calculates computer resource assignments for the LPAR based on the qualitative information and a set of conversion functions. For example, the qualitative resource assignment wizard may calculate a processing unit assignment, a memory assignment, and an I/O slot assignment for the LPAR. The qualitative information may be input by a user, for example, utilizing a graphical user interface (GUI). In one embodiment, the conversion functions are calculated during a training phase, in which a user periodically provides qualitative information while resource usage data is gathered. The wizard may reside in a hardware management console (HMC) or other administrative console and/or may be a component of a hypervisor or other partition management code. Software code associated with the wizard may be provided by a network server application to a client system for enabling a user to remotely input the qualitative information.

Qualitative assignment of resources to a logical partition in a multipartitioned computer system

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.

Optimizing a query to a partitioned database table using a virtual maintained temporary index that spans multiple database partitions

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.

Database execution detail repository

Method and apparatus for dynamically associating different query execution strategies with selective portions of a database table

Generating database query plans

Growing community of inventors

Chicago, IL, United States of America

Shantan Kethireddy