Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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).

Abstract: 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).

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.