Sap Se

Christoph Roterring

Werner Thesing

Reiner Singer

Juchang Lee

Dirk Thomsen

Kyu Hwan Kim

Thorsten Glebe

Beomsoo Kim

Deok Hoe Kim

Chang Gyoo Park

Michael Muehle

Martin Heidel

Shiping Chen

Joern Schmidt

Vivek Kandiyanallur

Markus Behrens

Stephan Kottler

Xin Liu

Marcel Birn

Omran Saleh

Yue Zhu

Mitja Kleider

Timo Sulg

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

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

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

Measuring snapshot delay between source database system and its asynchronous replica

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 amount of parallelization of the garbage collection can be varied based on utilized processor resources. The database system is later brought online after all of the recovery operations are replayed.

Automatic adoption of parallelized database garbage collection

Recovery of a database system can be initiated by taking the database system offline. Thereafter, recovery operations specified by a redo log of the database system are replayed. During the replaying, updates to pages implicated by the recovery operations are blocked. In parallel, modified pages are flushed to physical disk storage. The database is later brought online after all of the recovery operations are replayed.

Optimized savepoint during database recovery

Each of a plurality of database transactions are logged (i.e., recorded) in a log. Concurrent with the logging, one or more characteristics of the log are monitored. Thereafter, a savepoint is triggered when a pre-defined condition is met as indicated by the monitoring. The triggered savepoint can override or accelerate a savepoint that would have otherwise been triggered based on pre-specified parameters.

Growing community of inventors

Sinsheim, Germany

Christoph Roterring