Sap Se

Sap Ag

Juchang Lee

Chang Gyoo Park

Kyu Hwan Kim

Ivan Schreter

Sang Kyun Cha

Franz Faerber

Joo Yeon Lee

Michael Muehle

Jaeyun Noh

Deok Koo Kim

Mihnea Andrei

Yong Sik Kwon

Hyoung Jun Na

Chul Won Lee

Beomsoo Kim

Myunggon Park

Nosub Sung

Yongsik Yoon

Chanho Jeong

Hyejeong Lee

Chang Bin Song

Deok Hoe Kim

Frank Renkes

Seyeong Bae

Christian Bensberg

Norman May

Stefan A Baeuerle

Ruediger Karl

Yongjae Chuh

Changgyoo Park

Alexander Schroeder

Ki Hong Kim

Jaeyoung Choi

Sung Heun Wi

Werner Thesing

Eunsang Kim

Chulwon Lee

Jeong Hee Won

Marco Paskamp

Anil Kumar Goel

Steffen Geissinger

Christoph Roterring

Jane Jung Lee

Kyungyul Park

Wonyoung Kwak

Chang-Gyoo Park

Kyu-Hwan Kim

Hyoung-Jun Na

Chae Kwang Lee

Thorsten Glebe

Wolfgang Stephan

Alexander Boehm

Lars Fricke

Taehyung Lee

Reiner Singer

Hannes Jakschitsch

Andreas Tonder

Myung Sun Park

Kiyong Lee

Ji Hoon Jang

Thomas Seufert

Marcel Birn

Eunjin Song

Hyungyu Shin

Seongyun Ko

Deok-Hoe Kim

Hyoungjun Na

Di Wu

Colin Florendo

Thomas Legler

Andreas Kemmler

Jonathan Bregler

Donald Kossmann

Sunho Lee

Thomas Peh

Meinolf Block

Martin Heidel

Lars Dannecker

Ivan T Bowman

Edward-Robert Tyercha

Hyunjun Kim

Hyeong Seog Kim

Roland Sedler

Sangyong Hwang

Kihong Kim

Henning Zahn

Martin Schindewolf

Kai Morich

Carsten Binnig

Patrick Voelker

Joo-Yeon Lee

Martin Kittel

Uwe Hahn

Holger Mack

Jin Yeon Lee

Jeong Ae Han

Friedrich Keller

Jihwan Lim

Hyogi Jung

Zhi Qiao

Systems and methods include creation of a first instance of a tenant object in a database instance, association of the first instance of the tenant object with a first plurality of database artifacts including first data associated with the first instance of the tenant object, creation of a second instance of the tenant object in the database instance, association of the second instance of the tenant object with a second plurality of database artifacts including second data associated with the second instance of the tenant object, and reception and response to queries on the first data associated with the first instance of the tenant object and to queries on the second data associated with the second instance of the tenant object.

Native multi-tenancy for database system

Techniques and solutions are described for implementing virtual table schemas. A virtual table schema includes a logical pointer that is used to target a table that includes data and is defined according to the virtual table schema. Values assigned to the logical pointer can be used to target tables at different locations, such as in a federated database system or in a cache of a database management system of a central computing system. When data associated with the virtual table is requested, or prior to receiving the request, the data can be stored in a table in the cache. The logical pointer can be updated to reference the cache. If the cache is full, the table can be removed from the cache, and the logical pointer can be updated to reference a table at the federated database system.

Virtual database tables with updatable logical table pointers

Techniques and solutions are described for implementing virtual table schemas. A virtual table schema includes a logical pointer that is used to target a table that includes data and is defined according to the virtual table schema. Values assigned to the logical pointer can be used to target tables at different locations, such as in-memory storage or in dynamic storage of a database management system. The dynamic storage includes an in-memory buffer cache and persistent storage. The logical pointer can be updated to point to the in-memory storage or the dynamic storage, including based on use statistics. Similarly, a table having data for the virtual table can be transitioned between the in-memory buffer cache and the persistent storage, including based on use statistics for the virtual table. A value for the logical pointer can be updated when the table is transferred between the in-memory buffer cache and the dynamic storage.

A system, method and computer product for managing distributed transactions of a database. A transaction manager is provided for each of a plurality of transactions of the database. Each transaction manager is configured to perform functions that include generating a transaction token that specifies data to be visible for a transaction on the database. The database contains both row and column storage engines, and the transaction token includes a transaction identifier (TID) for identifying committed transactions and uncommitted transactions. A last computed transaction is designated with a computed identifier (CID), record-level locking of records of the database is performed using the TID and CID to execute the transaction, and the plurality of transactions of the database are executed with each transaction manager.

Distributed transaction management with tokens

Technologies are described providing adaptive query routing in a replicated database environment. The technologies can be used with a variety of replication protocols. Prepared statements, such as for queries, from a database client can be routed to a source node, or a source node and available replica nodes, when a replica node becomes unavailable. When a replica node becomes available again, a prepared statement can be updated to indicate that the updated prepared statement can be executed at nodes including the replica node that is available again. Prepared statement routing can also be used when a portion of replicated data becomes unavailable at a replica node, but a portion of replicated data remains available.

Adaptive query routing in a replicated database environment

A system and method of query processing in a multi-level storage system having a unified table architecture. A query is received by a common query execution engine connected with the unified table architecture, the query specifying a data record. The common query execution engine performs a look-up for the data record based on the query at the first level storage structure. If the data record is not present at the first level storage structure, the common query execution engine performs separate look-ups in each of the second level storage structure and the main store.

Unified table query processing

Technologies are described for facilitating database system recovery in a distributed database environment having a master node and at least one slave node. The master node maintains an in-memory reference that includes transaction identifiers and their corresponding commit identifiers. When a slave node requests that a commit identifier be assigned to a transaction, the transaction and commit identifiers for the transaction are added to the in-memory reference. The commit identifier is sent by the master node to the slave node. The slave node writes a log entry to a commit log that includes the transaction identifier and the assigned commit identifier. If the database system is interrupted before the slave node writes the commit log entry, the slave node can request the commit identifier for the transaction from the master node, which retrieves the identifier from the in-memory reference.

Transaction commit protocol with recoverable commit identifier

Technologies are described for facilitating data workload capture, workload replay, and comparing the performance of a plurality of database systems. A plurality of requests for database operations are received from one or more database clients. The requests for database operations are executed. For the plurality of requests for database operations, execution context information is generated for a plurality of execution contexts. For the plurality of requests for database operations, a plurality of performance measures are generated. The execution context information and the performance measures are stored in a workload capture store, such as a file. The workload capture file is useable to replay the captured workload at a second database system using at least a portion of the execution context information and at least a portion of the performance measures.

Database workload capture and replay

Techniques are described for use in database and data management systems to efficiently capture and replicate changes that occur in database tables. The changes are captured in a transaction-consistent order, and in a format that may easily be searched and accessed using common relational queries.

Database change capture with transaction-consistent order

Technologies are described for facilitating transaction processing in a distributed database environment. A database client sends database operations to a slave node, which mediates execution of the transaction. A connection between the database client and the slave node is associated with an identifier, and the transaction has an identifier. The database client sends a commit request to a master node over a network connection between the master node and the database client. The commit request includes the transaction identifier. The commit request can also include an indication of database nodes executing operations in the transaction.

Client-driven commit of distributed write transactions in a database environment

A client computer establishes one or more sessions with a DBMS. Session context information for each session is cached in a client-side session cache. When a session disconnection is detected, the session recovery includes establishing a new session with the DBMS, and restoring the session context of the disconnected session from the session information of the disconnected session that is stored in the session cache.

Transparent database session recovery with client-side caching

Methods, systems, and computer-readable storage media for receiving a capture file, the capture file including data representative of a workload executed in a source database system, and processing the capture file to provide a replay file, the replay file being in a format that is executable by a replayer to replay the workload in a target database system, processing the capture file including: processing the capture file to provide a set of intermediate files, and processing the set of intermediate files using in-memory merge sort operations to generate a set of replay files.

Preprocessing in database system workload capture and replay

Technologies are described for routing structured query language (SQL) statements to elastic compute nodes (ECNs) using workload classes within a distributed database environment. The elastic compute nodes do not store persistent database tables. For example, a SQL statement can be received for execution within the distributed database environment. A workload class can be identified that matches properties of the SQL statement. Based on the workload class, a routing location hint can be obtained that identifies a set of elastic compute nodes. The SQL statement can then be routed to one of the identified elastic compute nodes for execution. Execution of the SQL statement at the elastic compute node can involve retrieving database data from other nodes which store persistent database tables.

Routing SQL statements to elastic compute nodes using workload class

Growing community of inventors

Seoul, South Korea

Juchang Lee