Sap Se

Sap Ag

Jaeyun Noh

Juchang Lee

Sang Kyun Cha

Michael Muehle

Chang Gyoo Park

Chulwon Lee

Alexander Schroeder

Marco Paskamp

Yong Sik Kwon

Yongjae Chuh

Hyeong Seog Kim

Ji Hoon Jang

Hyungyu Shin

Seongyun Ko

Ivan Schreter

Christian Bensberg

Stefan A Baeuerle

Di Wu

Kyu Hwan Kim

Steffen Geissinger

Ki Hong Kim

Wolfgang Stephan

Sung Heun Wi

Beomsoo Kim

Taehyung Lee

Eunsang Kim

Jin Uk Bae

Jin Yeon Lee

Long Zhang

Eun Kyung Chi

Taesik Yoon

Technologies are described for restarting an application while maintaining data in memory (e.g., using shared memory). For example, shared memory can be associated with an application. The shared memory can also be associated with a holder process to maintain the shared memory from the time the application stops to the time the application starts again. When the application starts, the shared memory can be associated with the started application. In addition, restart of in-memory databases can be provided using shared memory. For example, in-memory data can be maintained when a database process or database management system stops and starts (e.g., during a restart).

Fast restart of applications using shared memory

A method can include: generating a query execution plan for a query including a plurality of operations that operate on data from a relational database and data from a non-structured query language (NoSQL) database, the generating comprising optimizing the query by: identifying a first operation that operate on data from the relational database and an intermediate result output by a second operation, the second operation outputting the intermediate result by operating on the data from the NoSQL database; and determining a fixed datatype for the intermediate result, an indication of the fixed datatype being included in the query execution plan; and executing, based on the query execution plan, the query, the executing of the query comprising converting the intermediate result to the fixed datatype, the converting enabling the first operation to operate on the intermediate result output by the second operation along with the data from the relational database.

Harmonized structured query language and non-structured query language query processing

A system, computer-implemented method, and computer-program product embodiments for rebuilding database indexes is disclosed. A pre-loader thread rebuilds a plurality of indexes in the background once a database is initialized. Simultaneously, a query processor receives queries from a user/client of a database. If an index that is required by the query processor has not yet been rebuilt by the pre-loader, a request to rebuild the index is sent to an asynchronous index loader. The asynchronous index loader places the request in a queue, processes the queue based on available system resources, and then rebuilds the requested indexes. Once the necessary indexes have been rebuilt, a wake-up signal is sent to the query processor which then proceeds to execute the query from a user/client.

Asynchronous index loading for database computing system startup latency managment

Technologies are provided for using a multi-user execution plan cache to process database queries. A database query processor can be configured to store execution plans in a multi-user execution plan cache. The query processor can determine whether an execution plan is shareable by multiple database users. If the execution plan is shareable, it can be stored in the cache in association with a sharing user identifier. When a database query is received, the query processor can determine that the query can be performed using the cached execution plan. If the cached execution plan is shareable, the database query can determine whether the cached execution plan is valid for a database user associated with the received database query. If the cached execution plan is valid for the database user, the query processor uses the cached execution plan to perform the query for the associated database user.

Multi-user database execution plan caching

Technologies for performing garbage collection in database systems, such as multi-version concurrency control (MVCC) database systems, are described. For example, different garbage collection techniques can be used separately or in various combinations, including interval garbage collection, group garbage collection, table garbage collection, and combinations. For example, a particular type of combination, called hybrid garbage collection, uses technique from interval garbage collection and group garbage collection, or from interval, group, and table garbage collection.

Group garbage collection for multi-version concurrency control in database systems

Interval garbage collection for multi-version concurrency control in database systems

Technologies are described for performing proactive memory allocation (e.g., pre-allocation). Proactive memory allocation (e.g., proactive memory page allocation) can be provided for applications, such as database applications. For example, an application can be associated with a free memory pool (e.g., a free memory pool containing free memory pages). A dedicated thread of the application can monitor the free memory pool and perform proactive memory allocation when needed (e.g., when the amount of memory in the pool is low). For example, the dedicated thread can obtain new free memory from the operating system and add it to the pool.

Proactive memory allocation

Hybrid garbage collection for multi-version concurrency control in database systems

For each data change occurring transaction created as part of a write operation initiated for one or more tables in a main-memory-based DBMS, a transaction log entry can be written to a private log buffer corresponding to the transaction. All transaction log entries in the private log buffer can be flushed to a global log buffer upon completion of the transaction to which the private log buffer corresponds.

Transaction private log buffering for high performance of transaction processing

Systems, methods and computer program product embodiments for providing a locking protocol for partitioned and distributed database tables are disclosed herein. A locking method includes executing, by at least one processor, a first database transaction on a second node, attempting to acquire and acquiring a lock on the second node in intentional exclusive mode, executing, by the at least one processor, a second database transaction on a first node, acquiring a lock on the first node in exclusive mode and waiting to acquire a lock on the second node in exclusive mode, routing, by the at least one processor, the first database transaction to the first node and unsuccessfully trying to acquire a lock on the first node and committing, by the at least one processor, the first database transaction.

Locking protocol for partitioned and distributed tables

Techniques and solutions are provided for performing transactions within a database system that stores database data using a row store and a column store. For example, a transaction that performs operations to update data in both the row store and the column store can use the same transaction object. The state of the transaction can be atomically changed. For example, the state of the transaction object can be atomically changed from uncommitted to committed (e.g., set to a commit identifier to represent the committed state).

Multi-version concurrency control across row store and column store

A system includes reception of a first query from a client device at a first database node of a database instance comprising two or more database nodes, determination of a second database node of the two or more database nodes associated with the first query, compilation of the first query at the first database node to generate first compiled code, and transmission of the first compiled code and a first identifier of the second database node from the first database node to the client device.

Client-side statement routing in distributed database

Systems, methods and computer program product embodiments for providing version garbage collection using snapshot lists are disclosed herein. Version garbage collection using snapshot lists includes storing, by at least one processor, versions of a record in a database table, the record comprising a record value and a version timestamp, storing, by the at least one processor, active snapshots in two levels of active snapshot lists, an active snapshot comprising a transaction identifier and a snapshot timestamp, determining, by the at least one processor, a minimum active snapshot from the active snapshots in the two levels of active snapshot lists and deleting, by the at least one processor, versions of the record having a version timestamp earlier than a snapshot timestamp of the minimum active snapshot.

Version garbage collection using snapshot lists

A computer-implemented method, a computer program product, and a system are provided. A transaction master for each of a plurality of transactions of a database is provided. Each transaction master is configured to communicate with at least one transaction slave to manage execution a transaction in the plurality of transactions. A transaction token that specifies data to be visible for the transaction on the database is generated. The transaction token includes a transaction identifier for identifying whether the transaction is a committed transaction or an uncommitted transaction. The transaction master is configured to update the transaction token after execution of the transaction. A determination whether the transaction can be executed on the at least one transaction slave without accessing data specified by the transaction token is made. The transaction is executed on the at least one transaction slave using a transaction token stored at the at least one transaction slave.

Growing community of inventors

Seoul, South Korea

Jaeyun Noh