Sap Se

Sap Ag

Sap Global IP Group, Sap Ag

Thorsten Glebe

Dirk Thomsen

Martin Heidel

Ivan Schreter

Michael Muehle

Andrei Suvernev

Mihnea Andrei

Christian Bensberg

Colin Florendo

Steffen Geissinger

Werner Thesing

Christoph Roterring

Eunsang Kim

Juchang Lee

Yong Sik Kwon

Daniel Booss

Meinolf Block

Rolando Blanco

Tobias Scheuer

David Wein

Chaitanya Gottipati

Peter Steinemann

Martin Schindewolf

Patrick Voelker

Nirvik Basak

Volkmar Soehner

Martin Kittel

Holger Mack

Norman May

Robert Schulze

Reza Sherkat

Jaeyoung Choi

Jonathan Bregler

Alexander Boehm

Lars Dannecker

Lars Fricke

Ivan T Bowman

Sascha Zorn

Frank Renkes

Amarnadh Sai Eluri

Beomsoo Kim

Hyunjun Kim

Myung Sun Park

Henning Zahn

Shiping Chen

Vivek Kandiyanallur

Panfeng Zhou

Sarika Iyer

Changgyoo Park

Christoph Hohner

Johannes Beigel

Stephan Kottler

Uwe Hahn

Felix Knittel

Fabian Garagnon

Urs Klingsporn

Johannes Haeussler

Jörn Schmidt

Melanie Handreck

Sergej Hardock

Blaise Lengrand

Andreas Hartel

Günter Radestock

Christian Bartholomä

Michael Mühle

Hans-Jörg Leu

Volker Diesel

Johannes Gloeckle

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

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

A provisional page to be filled with data is allocated in an in-memory database system in which pages are loaded into memory and having associated physical disk storage a provisional page to be filled with data. Thereafter, the provisional page is filled with data. The provisional page is register after the provisional page has been filled with data such that consistent changes in the database are not required for the provisional page prior to the registering.

In-memory database page allocation

Aspects of the current subject matter are directed to an approach in which a parallel load operation of file ID mapping containers is accomplished at start and/or restart of a database system. Parallel load operation of file ID mapping and/or large binary object (LOB) file ID mapping is done among a plurality of scanning engines into a plurality of data buffers that are associated with each of the plurality of scanning engines. Each scanning engine operates on a certain path of a page chain of a page structure including the mapping, causing the page chain to be split among scanning engines to process maps. Contents of the data buffers are pushed to mapping engines via a queue. The mapping engines load the file ID mapping and the LOB file ID mapping into maps for in-system access.

Parallel load of mapping containers for database system start and restart operations

Recovery of a database system by taking the database system offline is initiated. Thereafter, recovery operations specified by a redo log of the database system are replayed. A cleanup log is generated that identifies cleanup operations occurring during the replay of the recovery operations for garbage collection. Concurrent with the startup of the database, garbage collection of the cleanup operations as specified in the database savepoint is initiated. In addition, concurrent with the replay of the recovery operations, garbage collection of the cleanup operations specified by the cleanup log is initiated. The database system is later brought online after all of the recovery operations are replayed.

Asynchronous garbage collection in database redo log replay

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

Checking of a database snapshot of an active database is initiated. Thereafter, an anchor page associated with a most recent snapshot that links to a restart page is read. Subsequently, the linked restart page is read. It is then initially determined, based on the reading of the anchor page and the restart page, whether the snapshot is accurate. If it is initially determined that the snapshot is not accurate, the anchor page and the restart page are re-read until a final determination is made that whether the snapshot is accurate. Alternatively, if not is initially determined that the snapshot is accurate, then data is provided (e.g., displayed, loaded into memory, transmitted to a remote computing system, stored in physical persistence, etc.) that indicates that the snapshot is accurate.

Database snapshot checking

A request is received for a first non-exclusive lock to read a page in a database. Thereafter, execution of the at least one non-exclusive lock is initiated. Later, a request for an exclusive lock to modify the page in the database is received. Subsequently, a request is received for a second non-exclusive lock. In response, an amount of time to finish the first request and the second request is estimated. The second non-exclusive lock is allowed to execute in parallel to the first non-exclusive if the determined amount of time to finish the second non-exclusive lock is less than an estimated amount of time needed by the first non-exclusive lock. Alternatively, execution of the second non-exclusive lock is delayed to after the execution of the exclusive lock if the determined amount of time to finish the second non-exclusive lock is greater than an amount of time needed by the first non-exclusive lock.

Optimization of non-exclusive access database consistent change

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

Execution of an exclusive lock of a page in a database is initiated. Thereafter, subsequent to the initiation of the execution of the exclusive lock, at least one non-exclusive lock for the page in the database is received. The execution of the exclusive lock is selectively timed out based on at least one savepoint statistic. While the exclusive lock is timed out, at least one of the received non-exclusive locks is executed. Further, the exclusive lock can be restarted after the execution of the at least one of the received non-exclusive locks.

Optimization of exclusive access database consistent change locks

The subject matter disclosed herein relates to out of memory error handling in a database system. A database operation can be received by an in-memory database. The database operation can be for a database object stored in a database table that can be represented as a plurality of pages that can be persisted in a page chain. The in-memory database can reserve out of memory space sufficient to load a predetermined number of pages in the page chain into memory. The in-memory database can iteratively process each page in the page chain until completion of the database operation. The iterative process can include loading the page from persistence into memory of the in-memory database, performing at least a portion of the database operation using the loaded page, and unloading the page from the memory of the in-memory database. Related apparatus, systems, techniques, and articles are also described.

Out of memory error handling for data definition language operations

Provided are systems and methods for storing checkpoints of an in-memory storage device. In one example, the method may include detecting database transactions performed on a slice of an in-memory storage and storing a record of the database transactions in a log file, receiving a request to persist the slice of in-memory storage, the request comprising a timing indicator corresponding to a timing of database transactions, trimming the log file based on the timing indicator to remove a record of one or more database transactions from the log file that occurred prior to the timing indicator and to preserve a record of one or more database transactions that occurred after the timing indicator, and persisting, to disk, data from the slice of in-memory storage and the trimmed log file preserving the record of the one or more database transactions that occurred after the timing indicator.

Checkpoints for document store

Loading of a page into memory of an in-memory database system is initiated. Thereafter, a new page size for the page in memory is allocated corresponding to a greater of a current page size and an intended page size. Later, the page is loaded into the allocated memory so that a consistent change can be opened. Content within the page is reorganized according to the new page size followed by the consistent change being closed.

In-memory database with page size adaptation during loading

Growing community of inventors

Leimen, Germany

Thorsten Glebe