International Business Machines Corporation

Maryela Evelin Weihrauch

Pallavi Priyadarshini

Parameswara R Tatini

Namik Hrle

Oliver Benke

Peter Bendel

Ruiping Li

Stephen Andrew Brodsky

Kollol K Misra

Daniel Martin

Yao-Ching Stephen Chen

Claire Willey McFeely

Xiaohong Fu

Tammie Dang

John Joseph Campbell

Charles Roy Bonner

Frances Hwa Villafuerte

Xin Yang

Knut Stolze

Hao Wu

Curt Lee Cotner

Ke Wei Wei

Fen-Ling Lin

Vinayak Joshi

Oliver Draese

Paul Arnold Ostler

Roland Seiffert

Anshul Dawra

Miao Zheng

Binghui Zhong

Peter Wansch

Fung Lee

Daya Vivek

David J Kuang

Michael Schenker

Illong A Huang

Holger Karn

Kevin Michael McBride

Bilung Lee

Patrick Dooling Bossman

John Benjamin Tobler

Michael Leon Pauser

Sonali Surange

Tony Leung

Matthias Tschaffler

Michael Reichert

William Robert Bireley

Rebecca Braun Nin

Azadeh Ahadian

Swaminathan Gounder

Suavi Ali Demir

Delmar Eugene Blevins

Frank Darl Bower

Andreas Limmer

Christopher M Farrar

Robert Thomas Miller

Euna Park

Stephan Arenswald

Lawrence E Dunnell

Loic Raymond Robert Julien

Vasantha Jayakumar

Peter Kuang

A method, system and computer program product for providing consolidated access to data of a plurality of source databases. Tables of each of the source databases are replicated to a shared accelerator. The source DBMSs are configured to dispatch queries to the accelerator for accelerating query execution. The accelerator is configured such that the replicated tables can only be accessed by the source DBMS having provided said tables for executing a dispatched query. A user can select one of the source DBMSs to act as a consolidated DBMS&#x2014;C-DBMS. The C-DBMS provides the consolidated access. The user is enabled to select tables managed by another one of the DBMSs. In response to receiving the selection of the tables, the accelerator is re-configuring such that the C-DBMS is granted access also to the copies of the selected tables in the accelerator.

Accelerator based data integration

In managing multiple versions of triggers, a database system creates a first version of a trigger to apply a first set of actions in response to a first triggering event. The database system also creates a second version of the trigger to apply a second set of actions to the database object in response to a second triggering event. Upon receiving a command to set the current version of the trigger to the second version, the database system sets the second version as the current version of the trigger. When the triggering event of the trigger occurs, the database system determines that the second version is the current version of the trigger, retrieves the second set of actions in the second version, and executes the second set of actions.

Multiple versions of triggers in a database system

A distributed database system (or federated database system) where a catalogue is used to store metadata descriptive of data containers for the constituent database system(s) and/or accelerator system(s) of the federated database. In response to the generation of the trigger signal corresponding to a database definition language (DDL) statement, the accelerator system updates metadata in the catalogue.

Distributed system with accelerator and catalog

In supporting temporal logical transactions, a database management system (DBMS) determines that a temporal logical transaction time (T) is set for a temporal logical transaction. The DBMS receives a change request for a current row in a current table. A history row for a history table corresponding to the current table is created. The values in the history row are set to the values in the current row, where a begin time in the history row has same value as a begin time in the current row, and an end time in the history row is set to T. When the begin time equals the end time in the history row, the DBMS does not store the history row in the history table. The values in the current row are changed according to the change request, and the begin time in the current row is set to T.

Temporal logical transactions

Exposing existing database server attributes that are used for load balancing, accounting, log filtering, problem determination, and end user identification as tenant identifiers. An example of such attribute is the values in existing client information fields that are available to applications for passing additional information to the database server via connections. These values are then used by the database server for enhanced operational functions of load balancing, accounting, log filtering, problem determination, and end user identification.

Supporting multi-tenant applications on a shared database using pre-defined attributes

In an enforcement of temporal referential integrity in a database system, the database system receives a change request for one or more rows in a target table in the database system. The system determines that the target table has temporal referential constraints with a second table. The system compares a non-period child key value in child table row(s) with a non-period parent key value in parent table row(s) and compares a child business time period key value in the child table row(s) with a parent business time period key value in the parent table row(s). When the non-period child key value matches the non-period parent key value and when the child business time period key value is within the parent business time period key value, the system determines that the change request satisfies the temporal referential constraints. Otherwise, the system determines that the change request violates the temporal referential constraints.

Enforcing temporal referential integrity

Rows are inserted in a database table on a page having a first space reserved for inserting rows of the database table. A second space is reserved for updating data of the inserted rows, wherein reserving the second space includes reserving the second space on the page responsive to inserting each of the rows.

Free space management in a database

A first compute node of a plurality of compute nodes of a database cluster may receive a request for a database transaction from a client application. The client application may be located within the first compute node. A first connection may be established, without regard to whether another compute node has a lighter workload than the first compute node, between the client application and a first database of the database cluster. The first connection may be a local connection, wherein the first database is located within the first compute node. The first compute node may detect that a failure associated with the first database has occurred. The first compute node may execute a failover operation to continue servicing the request for the data. The executing of a failover operation may include establishing a second connection between the client application and a second database of the database cluster.

Automated local database connection affinity and failover

A database system searches for any statements that satisfy one or more of a set of filtering criteria. When a given dynamic query statement fully satisfies the set of filtering criteria, the given statement is stabilized by persistently storing a bound form of the given dynamic query statement. When the given dynamic query statement partly satisfies the set of filtering criteria, a monitoring request is created with the set of filtering criteria to begin monitoring subsequent executions of the statement, and the statement is linked to the monitoring request. When the given dynamic query statement subsequently fully satisfies the set of filtering criteria, the statement is stabilized by persistently storing the bound form of the statement. When the given dynamic query is re-executed, the stabilized statement is loaded, and the PREPARE process is bypassed.

Method to monitor dynamic SQL statements for automatic stabilization in a data sharing environment

Growing community of inventors

San Jose, CA, United States of America

Maryela Evelin Weihrauch