Sap Se

Sap Ag

Sap Global IP Group, Sap Ag

Martin Heidel

Joern Schmidt

Thorsten Glebe

Michael Muehle

Rolando Blanco

Christian Bensberg

Andreas Tonder

Mihnea Andrei

Shiping Chen

Vivek Kandiyanallur

Peter Steinemann

Colin Florendo

Robert Schulze

Reza Sherkat

Lars Fricke

Edward-Robert Tyercha

Chaitanya Gottipati

Carsten Thiel

Stephan Kottler

Ivan Schreter

Thomas Legler

Guenter Radestock

Sarika Iyer

Bernhard Scheirle

Holger Bischoff

Johannes Haeussler

Jörn Schmidt

Juchang Lee

Dirk Thomsen

Steffen Geissinger

Yong Sik Kwon

Anisoara Nica

Alexander Boehm

Thomas Peh

Meinolf Block

Sascha Zorn

Beomsoo Kim

Reiner Singer

David Wein

Holger Schwedes

Christoph Roterring

Myung Sun Park

Martin Schindewolf

Patrick Voelker

Christoph Hohner

Adrian Dragusanu

Nirvik Basak

Johannes Beigel

Andreas Thumfart

Martin Kittel

Holger Mack

Alexander Hermann

Felix Knittel

Xin Liu

Fabian Garagnon

Frank Benkstein

Timo Hochberger

Tobias Zahn

Andreas Bader

Thorsten Winsemann

Sergej Hardock

Andreas Hartel

Xun Chen

Liang Song

Mohamed Ali Chriki

Sascha Bastke

Christian Bartholomä

Michael Mühle

Hans-Jörg Leu

Volker Diesel

A method may include receiving a first transaction inserting a record into a database and a second transaction deleting the record from the database. A validity period for the record may be determined based on a first commit time at which the first transaction is committed and a second commit time at which the second transaction is committed. A current table and/or a history table of a system versioned table may be updated to include the record based on the validity period of the record. One or more temporal operations may be performed based on the system versioned table. For example, a time travel operation may be performed to retrieve, based on the system versioned table, one or more records that are valid at a given point in time. Related systems and computer program products are also provided.

System versioned table with transactional system time

A database system includes a persistent storage system, a memory storing metadata defining a tenant object and a plurality of database artifacts, a first instance of the tenant object, the first instance associated with a first plurality of the database artifacts including first data associated with the first instance of the tenant object, and a second instance of the tenant object, the second instance associated with a second plurality of the database artifacts including second data associated with the second instance of the tenant object. A processing unit is to execute program code of a database instance to cause the database system to encrypt the first data associated with the first instance of the tenant object using a first public encryption key and store the encrypted first data in the persistent storage system, and encrypt the second data associated with the second instance of the tenant object using a second public encryption key and store the encrypted second data in the persistent storage system.

Native multi-tenant encryption for database system

Disclosed herein are system, method, and computer program product embodiments for storing a large object (LOB) in a database. An embodiment operates by identifying the LOB to be stored in an on-disk store of the database and determining the size of the LOB. Thereafter, an index vector for the on-disk store to include an identifier corresponding to the LOB is created. Additionally, a dictionary for the on-disk store to include a copy of the identifier and corresponding LOB data is also created. The LOB data corresponds to the LOB itself or a LOB location inside of the on-disk store based on the LOB's size.

Paged hybrid LOBs

A method, computer program product and system are provided. The method, computer program product and system execute a process for storing an object in an object container that is stored in a persistency of a disk storage. The object container has size criteria whereby objects meeting the size criteria of the object container can be assigned to the object container. The object container can facilitate storing multiple objects to optimize disk storage usage by facilitating the assigning of multiple objects to the same disk storage page.

Large object containers with size criteria for storing mid-sized large objects

A method, a system, and a computer program product for performing testing of continuous log replays in a database system. A redo log generated for a data record in a database is received. The redo log is indicative of a change in persistency of the data record in the database. Based on the change in persistency recorded in the redo log, a redo handler in the plurality of handlers is selected for execution of a replay of the received redo log. Using the selected redo log, replay of the redo log is executed to generate a state of the data record prior to the change in persistency recoded in the redo log.

Test continuous log replay

A computer implemented method for manipulating data comprises receiving log transaction information from a primary database system at a secondary database system and parsing the log transaction information to identify data objects that have been modified on the primary database system. The secondary database system determines whether the data objects are present in main memory on the secondary database system and whether the log transaction corresponds to a data manipulation language (DML) query or a data definition language (DDL) query. If the data objects are not in the main memory and the query is a DML query, they are copied from persistence data volumes to the main memory. The data objects in main memory are modified by replaying the log transactions on the data objects in the main memory. Then, the data objects in the persistence data volumes are modified. Related apparatus, systems, techniques and articles are also described.

Replay of redo log records in persistency or main memory of database systems

Restoring of a database table in the database system (e.g., an in-memory insert-only database system, etc.) is initiated. Thereafter, a transaction log volume storing data log records and multi-version concurrency control (MVCC) log records corresponding to the database table is accessed. Based on such access, data log records corresponding to the database table are replayed while insert and update MVCC log records corresponding to the database table are skipped. Subsequently, restoring of the database table in the database system is finalized. Related apparatus, systems, techniques and articles are also described.

Database redo log optimization by skipping MVCC redo log records

Persisting data in logical tiers of an in-memory database based on aging rules of the database system. The database system can be configured to age data by moving the data from a first logical tier supporting high performance data access to a second logical tier supporting lower performance data access, thereby improving the operational efficiency of the database system.

Providing database storage to facilitate the aging of database-accessible data

Disclosed herein are system, method, and computer program product embodiments for a database recovery and optimization with batch processing system. An embodiment operates by retrieving a database log that includes a plurality of operations for modifying data of a database stored across a plurality of tables. From the database log, a plurality of consecutive insert operations for inserting data into the database are identified. The consecutive insert operations are sorted by table. The sorted insert operations are grouped into a batch message. The batch message is transmit to the database for replay. An acknowledgement is received that the replay has completed.

Database recovery and optimization with batch processing

Objects across multiple database manipulation language (DML) redo log records are cached, during continuous replay of redo log records on a secondary system, for the same table partition to enable reuse of such cached objects. Later, these cached objects can be reused as they are accessed during the sequential processing of DML redo records for a specific table partition.

Caching DML statement context during asynchronous database system replication

The subject matter disclosed herein provides methods for the forced ordering of a dictionary based on row identifier values. A plurality of concurrent transactions can be handled in an in-memory database. At least one of the transactions can include at least one write operation to a dictionary. Each write operation can be assigned a row identifier (ID). At least one of the write operations can be written to the dictionary out of sequence. The sequence can be based on the row ID. Each row ID in the dictionary can be mapped to a corresponding value identifier in the dictionary. The dictionary can position the value identifiers so that the corresponding row IDs are in a sorted sequential order based on the row ID. Related apparatus, systems, techniques, and articles are also described.

Forced ordering of a dictionary storing row identifier values

Disclosed herein are system, method, and computer program product embodiments for performing database processing after a lock condition. An embodiment operates by receiving a release of a lock on data of a database. It is determined whether the data was modified by a processing of a first transaction associated with the first request. The lock is provided to a second transaction associated with a second request to access the data. If the first transaction did not modify the data, a second transaction associated with the second request is retried without refreshing a snapshot of the data. If the first transaction modified the data, the snapshot of the data is refreshed before the second transaction is retried.

Database processing after a lock condition

A computer implemented method for manipulating data comprises receiving log transaction information from a primary database system at a secondary database system and parsing the log transaction information to identify data objects that have been modified on the primary database system. The secondary database system determines whether the data objects are present in main memory on the secondary database system. If the data objects are not in the main memory, they are copied from persistence data volumes to the main memory. The data objects are modified by replaying the log transactions on the data objects in the main memory. Then, the data objects in the persistence data volumes are modified. Related apparatus, systems, techniques and articles are also described.

Common runtime and recovery framework for manipulating data in main memory of database systems

Testing a database replication system within a multi-container system architecture comprises receiving a first request for creating a database recovery system within a multi-container system architecture. The multi-container system architecture is configured to contain a plurality of tenant databases and a system database, and the database recovery system includes a primary system and a secondary system. The primary system is then identified from the information in the first request. Upon identification, a first tenant database included in the plurality of tenant databases is determined that corresponds to the identified primary system. Upon determining the first tenant database, a second tenant database of the plurality of tenant database is generated that corresponds to the secondary system, and which is enabled to test replicating information that would otherwise be associated with the first tenant database. Related apparatus, systems, techniques and articles are also described.

Testing database replication with multi-container system architecture

Growing community of inventors

Walldorf, Germany

Martin Heidel