Oracle International Corporation

Sybase, Inc.

Sap Se

Graham Ivey

Yunrui Li

Shampa Chakravarty

Fei Zhou

Vsevolod Panteleenko

Sarika Iyer

Carlos Ruiz

Kothanda Umamageswaran

Jia Shi

Zuoyu Tao

Aditya Gurajada

Vijay Sridharan

Paresh Manhar Rathod

Jay Gorakhnath Sudrik

Shih-Yu Huang

Zheren R Zhang

Carlos Ruiz Muñoz

Yiliang Jin

The present disclosure relates to adaptively overlapping redo writes. A log writer, while operating in a thin mode, may assign a first log writer group of a plurality of log writer groups to write one or more first redo log records to an online redo log in response to determining that a pipelining parameter is satisfied. The thin mode may be associated with one or more target sizes that are less than one or more target sizes associated with a thick mode. The log writer may determine to operate the thick mode based at least in part on at least a portion of the plurality of log writer groups being unavailable to write one or more second redo log records to the online redo log. The log writer, while operating in the thick mode, may assign a second log writer group of the plurality of log writer groups to write one or more second redo log records from the log buffer to the online redo log in response to determining that an amount of redo log records in the log buffer meets one of the one or more target sizes associated with the thick mode. The log writer, while operating in the thick mode, may assign a third log writer group of the plurality of log writer groups to write one or more second redo log records from the log buffer to the online redo log in response to determining that a highest busy group number meets or exceeds a core threshold.

Adaptively overlapping the writing of redo log records

In an embodiment, before modifying a persistent ORL (ORL), a database management system (DBMS) persists redo for a transaction and acknowledges that the transaction is committed. Later, the redo is appended onto the ORL. The DBMS stores first redo for a first transaction into a first PRB and second redo for a second transaction into a second PRB. Later, both redo are appended onto an ORL. The DBMS stores redo of first transactions in volatile SRBs (SLBs) respectively of database sessions. That redo is stored in a volatile shared buffer that is shared by the database sessions. Redo of second transactions is stored in the volatile shared buffer, but not in the SLBs. During re-silvering and recovery, the DBMS retrieves redo from fast persistent storage and then appends the redo onto an ORL in slow persistent storage. After re-silvering, during recovery, the redo from the ORL is applied to a persistent database block.

Increasing OLTP throughput by improving the performance of logging using persistent memory storage

A computer's processes and/or threads generate and store in memory, data to reimplement or reverse a transaction on a database, so that the database can be recovered. This data is written to persistent memory storage ('persisted') by another process, for which the processes and/or threads may wait. This wait includes at least a sleep phase, and additionally a spin phase which is entered if after awakening from sleep and checking ('on-awakening' check), the data to be persisted is found to not have been persisted. To sleep in the sleep phase, each process/thread specifies a sleep duration determined based at least partially on previous results of on-awakening checks. The previous results in which to-be-persisted data was found to be not persisted are indications the sleeps were insufficient, and these indications are counted and used to determine the sleep duration. Repeated determination of sleep duration makes the sleep phase adaptive.

Adaptive synchronization for redo writing to persistent memory storage

A system for managing database logging, the comprises a processor; and a user task executing in a database server process and executable by the processor, the user task to: receive in a database management system on a database server, a command to manipulate a portion of a database managed by the database management system; obtain a lock on the portion of the database; create a first log record in a first private log cache associated with the user task, the first log record recording a data manipulation to the portion of the database; enqueue the first log record to a queue; and release the lock on the portion of the database after copying the first log record to the queue.

Reduce log contention by batching log record transfers to the log

A system for an in-memory row storage architecture can be provided. In some implementations, the system performs operations comprising processing a database transaction affecting at least a first row in an in-memory row store and at least a second row in a persistent page store, logging changes to the second row within a page store transaction log as part of the processing and prior to committing the database transaction, logging a final aggregated result of the first row as part of committing the database transaction within a row store transaction log that is separate and distinct from the page store transaction log, and altering at least a portion of the in-memory row store based on accessing the row store transaction log. Related systems, methods, and articles of manufacture are also described.

In-memory row storage durability

A shared storage architecture persistently stores database files in non-volatile random access memories (NVRAMs) of computing nodes of a multi-node DBMS. The computing nodes of the multi-node DBMS not only collectively store database data on NVRAMs of the computing nodes, but also host database server instances that process queries in parallel, host database sessions and database processes, and together manage access to a database stored on the NVRAMs of the computing nodes. To perform a data block read operation from persistent storage, a data block may be transferred directly over a network between NVRAM of a computing node that persistently stores the data block to a database buffer in non-volatile RAM of another computing node that requests the data block. The transfer is accomplished using remote direct memory access ('RDMA). In addition to techniques for performing a data block read operation to NVRAM, computing nodes perform a data block write operation to data blocks stored in NVRAM of the NVRAM shared storage architecture. The data block write operation is referred to herein as a one-sided write because only one database process needs to participate in the writing of a data block to NVRAM in order to successfully commit the write.

Remote one-sided persistent writes

The capability to perform data backup and restore within a distributed database system environment is provided. The embodiments includes initiating a backup operation of a database distributed across a plurality of nodes, and coordinating synchronization of the backup operation within and among the plurality of nodes for parallel, local data dumping with transactional consistency to a single point in time.

Parallel backup for distributed database system environments

Systems and methods are presented for reducing load database time in a database backup process. In some embodiments, a computer-implemented method may include marking a checkpoint in a log of the database; generating a backup of the database for data up to the checkpoint; recording first changes in the database while generating the backup of the database; adding to the backup of the database an additional backup of the recording of the first changes; recording second changes in the database while adding the additional backup; determining if a number of second changes satisfies a criterion; and if the number of second changes satisfies the criterion, then adding to the backup of the database a backup of the recorded second changes. Recording these changes can enable a database dump process to contain more recent page images, so that the amount of recovery at load time is reduced.

Growing community of inventors

Hampshire, United Kingdom

Graham Ivey