Oracle International Corporation

Sap Se

Shampa Chakravarty

Graham Ivey

Yunrui Li

Vsevolod Panteleenko

Aditya Gurajada

Fei Zhou

Carlos Ruiz

Shih-Yu Huang

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 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

Growing community of inventors

Pleasant Hill, CA, United States of America

Shampa Chakravarty