Sap Se

Werner Thesing

Christoph Roterring

Reiner Singer

Juchang Lee

Dirk Thomsen

Kyu Hwan Kim

Beomsoo Kim

Thorsten Glebe

Daniel Booss

Jaeyoung Choi

Markus Behrens

Chang Gyoo Park

Michael Muehle

Chul Won Lee

Deok Hoe Kim

Uwe Hahn

Omran Saleh

Yue Zhu

Ivan Schreter

Thomas Willhalm

Mihnea Andrei

Norman May

Yong Sik Kwon

Amit Pathak

Alexander Boehm

Thomas Peh

Peter Bumbulis

Tobias Scheuer

Frank Renkes

Hyunjun Kim

Sebastian Seifert

Eunsang Kim

Andre Schefe

Stefan Voss

Ruediger Karl

Janardhan Hungund

Bernhard Scheirle

Patrick Voelker

Jian Luo

Oliver Rebholz

Marcel Birn

Eduard Bartsch

Frank Huber

Abdelkader Sellami

Urs Klingsporn

Christoph Rottering

Timo Sulg

Jagadeesha Kanihal

Neha Shikha Kachhap

Mitja Kleider

Gunter Radestock

Tilman Giese

Johannes Gloeckle

Various examples are directed to systems and methods for operating a primary database management system and a secondary database management system. The secondary database management system may receive a takeover request indicating that the secondary database management system is to assume a role of the primary database system. The secondary database management system may determine that a last valid commit of a first host of the secondary database system is an oldest last valid commit. The secondary database management system may revert to a first state of the primary database management system corresponding to the last valid commit of the first host. The secondary database management system may be configured to assume the role of the primary database management system.

Database replication with host replication at asynchronously replicated system

A scale-out computing cluster may include a large number of computing servers and storage devices. In order to provide high reliability, the computing cluster must be able to handle failures of individual devices. Reliability of the computing cluster may be improved by providing a standby server for each active server in the computing cluster. If any active server fails, the corresponding standby server is activated. The failed server may be brought back online or replaced, at which time the restored server becomes the standby server for the now-active original standby server. During the restoration period, if any other active server fails, the standby server for that active server is immediately activated. As a result, the recovery ability of the computing cluster is only challenged if both servers of an active/standby pair fail during the restoration period, substantially improving reliability.

Increased replication for managed volumes

A primary database system loads database objects into a primary in-memory store according to a given format. The primary database captures, in replay logs, the loading of the database objects according to the given format. The primary database sends the replay logs to a secondary database system. In response to receiving a replay log, the secondary database checks the value of a log replay configuration parameter. If the configuration parameter is a first value, the secondary database replays the replay log to load the corresponding database objects into a secondary in-memory store according to a first format. If the configuration parameter is a second value, the secondary database replays the log to load the objects according to a second format, and if the configuration parameter is a third value, the secondary database replays the log to load the objects in a same format which was used by the primary database.

Database load unit for replication log replay

Systems and methods include reception of an instruction to recover a first database tenant of a first database instance to a first point in time, the first database tenant associated with first database artifacts of the first database instance, and the first database instance including two or more database tenants and, in response to the instruction, creation of a second database instance, selection of backup data of the first database instance based on the first point in time, execution of a recovery of the backup data on the second database instance, export of second database artifacts of the first database tenant from the second database instance to a storage, truncation of the first database artifacts from the first database instance, import of the second database artifacts from the storage to the first database instance, and deletion of the second database instance.

Tenant-level database recovery

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 computer implemented method is provided for determining a delay between a first database and an associated replicated database by replicating transactions of the first database in the replicated database, determining a delay between the two databases based on a commit timestamp from the first database and a timestamp associated with the commit transaction becoming visible in the replicated database. Then, after a predefined period of time has elapsed since replicating the commit transaction, determining a second delay based on a timestamp associated with a heartbeat log and a replicated database system time. And, selectively determining to execute or deny a statement received by the replicated database based on the second delay. Related apparatus, systems, techniques and articles are also described.

Measuring snapshot delay between source database and its asynchronous replica

A method, a system, and a computer program product for executing a takeover process. A takeover process of a primary computing system by a secondary computing system is triggered. The secondary computing system stores transaction data replicated from the primary computing system. Writing of a redo log of transaction data of one or more transactions into storage by the primary computing system is suspended. The redo log is written by the primary computing system prior to the suspending is transmitted to the secondary computing system. The takeover process of the primary computing system by the secondary computing system is executed upon receiving and persisting the redo log at the secondary computing system.

Replication system takeover with handshake

A computer implemented method is provided comprising receiving a group of transaction logs from a first database, allocating transaction logs from the group of transaction logs to a first queue and to a second queue, generating an end-of-group transaction log indicative of an end of the group of transaction logs, allocating the end-of-group log to the first queue and the second queue; replaying transaction logs from the first queue including the end-of-group transaction log allocated to the first queue, replaying transaction logs from the second queue including the end-of-group transaction log allocated to the second queue; and changing visibility of one or more transactions in response to replaying the end-of-group transaction log allocated to the first queue and the end-of-group transaction log allocated to the second queue. Related apparatus, systems, techniques and articles are also described.

Delayed snapshot isolation for read service at a database

Receiving a statement including requests for database operations in a secondary database system storing data replicated from a primary database system by replaying transaction output generated by the primary database system; responsive to receiving the statement, requesting an allocation of memory from the secondary database system to support the requested database operations; generating an aggregated statement memory consumption value based on the amount of memory consumed by all statements executing in the secondary database system that are not associated with replaying the transaction logs; determining that the requested allocation of memory in addition to the aggregated statement memory consumption value exceeds a total statement execution memory limit indicating a total amount of memory that may be allocated to all database operations associated with statement execution in a secondary database system, and denying the requested allocation of memory. Related apparatus, systems, techniques and articles are also described.

Database memory management in a high availability database system using limits

A system includes a non-volatile random access memory storing a column store main fragment of a column of a database table, and a processing unit to read the column store main fragment from the non-volatile random access memory. A volatile random access memory storing a column store delta fragment of the column of the database table may also be included, in which the processing unit is to write to the column store delta fragment. According to some systems, the stored column store main fragment is byte-addressable, and is copied from the volatile random access memory to the non-volatile random access memory without using a filesystem cache.

Column store main fragments in non-volatile RAM and the column store main fragments are merged with delta fragments, wherein the column store main fragments are not allocated to volatile random access memory and initialized from disk

A computer implemented method for replication includes registering a first database system with a second database system and performing a failback operation on the first database system. The failback operation includes opening a snapshot that includes data known to have existed on the first database system and the second database system at a first time. Transaction log information is requested from the second database system. The transaction log information corresponds to transactions performed on the second database system beginning with the first time. The transaction log information is applied to the snapshot data on the first database system. Related apparatus, systems, techniques and articles are also described.

Logical equivalent replication with snapshot based fallback of database systems

A savepoint is initiated in an in-memory database system that is associated with a plurality of modified pages and comprises a pre-critical phase, a critical phase, and a post-critical phase. Thereafter, as part of the critical phase, a physical page number is assigned to each page in the critical phase. Further, as part of the critical phase, each page assigned a physical page number is individually locked. Subsequently, each page is handed over from a corresponding first thread to a corresponding second thread to copy such page into a corresponding shadow page as part of the post-critical phase.

Database savepoint with shortened critical phase time

Measuring snapshot delay between source database system and its asynchronous replica

Growing community of inventors

Lautertal, Germany

Werner Thesing