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 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 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: Methods, systems, and computer program products are provided to efficiently allocate extremely large storage spaces for use by dynamic hash tables. A contiguous storage space is designated from which dynamic hash tables can be created. These dynamic hash tables benefit from rapid allocation by being able to reserve many allocation units (each potentially comprising a large number of pages, e.g., 256 pages) within a short span of time, rather than resorting to reserving individual pages. The efficiency from allocation and the contiguous space significantly improves performance for databases in the 50 GB-100 GB size range.