Mechanism to run OLTP workload on in-memory database under memory pressure

Patent metadata

Field	Value
Publication number	US-9323799-B2
Application number	US-201414337182-A
Country	US
Kind code	B2
Filing date	Jul 21, 2014
Priority date	Sep 21, 2013
Publication date	Apr 26, 2016
Grant date	Apr 26, 2016

Abstract

Techniques are provided for maintaining data persistently in one format, but making that data available to a database server in more than one format. For example, one of the formats in which the data is made available for query processing is based on the on-disk format, while another of the formats in which the data is made available for query processing is independent of the on-disk format. Data that is in the format that is independent of the disk format may be maintained exclusively in volatile memory to reduce the overhead associated with keeping the data in sync with the on-disk format copies of the data.

First claim

What is claimed is:

1. A method comprising:
maintaining, on persistent storage, a database that is accessible to a database server;
wherein the database includes a first set of data;
maintaining a second set of data in volatile memory that is accessible to the database server;
wherein each data item in the second set of data is a copy of a corresponding data item in the first set of data;
maintaining an in-memory journal for a particular transaction;
while the particular transaction is not in a downgraded mode, the particular transaction:
performing particular updates to copies of particular data items, in the first set of data, that are also in the second set of data, without performing the particular updates to copies of the particular data items in the second set of data; and
generating records of the particular updates, and storing the records of the particular updates in the in-memory journal for the particular transaction;

while the particular transaction is in the downgraded mode, the particular transaction performing certain updates to copies of certain data items, in the first set of data, that are also in the second set of data without performing the certain updates to copies of the certain data items in the second set of data, and without generating records, of the certain updates, for the in-memory journal;
responsive to determining that a memory consumption threshold has been exceeded, placing the particular transaction in the downgraded mode;
responsive to a request for a certain data item, a copy of which is in the second set of data:
determining whether the in-memory journal includes a version of the certain data item that is more recently updated than the copy of the certain data item in the second set of data, and
in response to determining that the in-memory journal includes a version of the certain data item that is more recently updated than the copy of the certain data item in the second set of data, retrieving the certain data item from the in-memory journal.

2. The method of claim 1 , further comprising:
while the particular transaction is executing in the downgraded mode, the particular transaction requesting an update to a particular data item;
wherein both the first set of data and the second set of data have copies of the particular data item;
in response to the request to update the particular data item, performing the steps of:
updating the copy of the particular data item in the first set of data; and
based, at least in part, on the particular transaction being in the downgraded mode: storing data to indicate that the copy of the particular data item in the second set of data is invalid, without updating the copy of the particular data item in the second set of data, and without storing, in the in-memory journal for the particular transaction, a record indicating the update of the particular data item.

3. The method of claim 2 wherein:
the update, to the particular data item, is to a particular row of a table within the database; and
the particular row is stored on a block within the database;
the step of storing data to indicate that the copy of the particular data item in the second set of data is invalid comprises storing data to indicate that data items, within the second set of data, that correspond to the block are invalid.

4. The method of claim 2 further comprising:
after the particular transaction commits, causing all requests for a current version of the particular data item to be routed to the first set of data.

5. The method of claim 1 wherein:
the memory consumption threshold is for the in-memory journal;
the particular transaction is a first transaction;
the first transaction is executing concurrently with a second transaction; and
the method further comprises:
maintaining a second in-memory journal for the second transaction;
while the first transaction is executing in the downgraded mode, the second transaction requesting an update to a particular data item;
wherein both the first set of data and the second set of data have copies of the particular data item;
wherein the memory consumption threshold, for the second in-memory journal, has not been exceeded;
in response to the request to update the particular data item, performing the steps of:
updating the copy of the particular data item in the first set of data; and
without updating the copy of the particular data item in the second set of data, storing, in the second in-memory journal for the second transaction, a record indicating the update of the particular data item.

6. The method of claim 1 wherein:
both the first set of data and the second set of data have copies of a particular data item;
the particular data item belongs to a table;
the method further comprises:
in response to the particular transaction being placed in the downgraded mode, moving one or more existing entries from the in-memory journal for the particular transaction to a journal for the table; and
wherein the one or more existing entries are for updates previously made by the particular transaction to data items belonging to the table.

7. The method of claim 6 wherein:
when moved to the journal for the table, the one or more existing entries do not indicate a commit time; and
the method further comprises in response to the particular transaction committing, updating the one or more existing entries in the journal for the table to indicate the commit time of the particular transaction.

8. One or more non-transitory computer-readable media storing instructions, wherein the instructions comprise:
instructions which, when executed by one or more hardware processors, cause maintaining, on persistent storage, a database that is accessible to a database server;
wherein the database includes a first set of data;
instructions which, when executed by one or more hardware processors, cause maintaining a second set of data in volatile memory that is accessible to the database server;
wherein each data item in the second set of data is a copy of a corresponding data item in the first set of data;
instructions which, when executed by one or more hardware processors, cause maintaining an in-memory journal for a particular transaction;
instructions which, when executed by one or more hardware processors, cause, while the particular transaction is not in a downgraded mode, the particular transaction:
performing particular updates to copies of particular data items, in the first set of data, that are also in the second set of data, without performing the particular updates to copies of the particular data items in the second set of data; and
generating records of the particular updates, and storing the records of the particular updates in the in-memory journal for the particular transaction;

instructions which, when executed by one or more hardware processors, cause, while the particular transaction is in the downgraded mode, the particular transaction performing certain updates to copies of certain data items, in the first set of data, that are also in the second set of data without performing the certain updates to copies of the certain data items in the second set of data, and without generating records, of the certain updates, for the in-memory journal;
instructions which, when executed by one or more hardware processors, cause responsive to determining that a memory consumption threshold has been exceeded, placing the particular transaction in the downgraded mode;
instructions which, when executed by one or more hardware processors, cause, responsive to a request for a certain data item, a copy of which is in the second set of data:
determining whether the in-memory journal includes a version of the certain data it

Assignees

• Oracle Int Corp

Inventors

• Hase Sanket
• Raja Vivekanandhan
• Ganesh Amit
• Marwah Vineet
• Pendse Sukhada
• Su Shuang
• Mullick Atrayee

Classifications

• G06F16/23 Primary

  Updating · CPC title

• G06F17/30345 Primary

  Physics · mapped topic

• G06F16/128

  Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion (error detection or correction of the data by redundancy in operations or in hardware G06F11/14, G06F11/16) · CPC title

• G06F16/283 Primary

  Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP · CPC title

• G06F16/1805

  Append-only file systems, e.g. using logs or journals to store data · CPC title