Database system with active standby and nodes

• US 8,868,504 B2
• Filed: 02/12/2008
• Issued: 10/21/2014
• Est. Priority Date: 03/07/2007
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Aranha, Rohan, Tuck, Paul, Miller, John Ernest, Wang, Chih-Ping, Neimat, Marie-Anne, Cheung, Susan Sokeng
• Primary Examiner(s): Saeed, Usmaan
• Assistant Examiner(s): Allen, Brittany N
• Application Number:
  US12/030,094
• Publication Number:
  US 20080222159A1
• Time in Patent Office: 2,443 Days
• Field of Search: 707/999.005, 707/652, 707/648
• US Class Current: 707/640
• CPC Class Codes: G06F 16/21 Design, administration or maintenance of databases

Abstract

A system includes an active node and a standby node and zero or more replica nodes. Each of the nodes includes a database system, such as an in-memory database system. Client updates applied to the active node are written through to the standby node, and the standby node writes the updates through to a primary database and updates the replica nodes. Commit ticket numbers tag entries in transaction logs and are used to facilitate recovery if either of the active node or the standby node fails. Updates applied to the primary database are autorefreshed to the active node and written through by the active node to the standby node which propagates the updates to the replica nodes. Bookmarks are used to track updated records of the primary database and are used to facilitate recovery if either of the active node or the standby node fails.

Claims

1. A computer-implemented method comprising steps of:

from one or more clients, an active node receiving first row updates for rows belonging to a cache group that are stored within an in-memory database of said active node, said cache group being defined as a set of rows of one or more base tables stored in a database of a disk-based primary database system;

said active node committing said first row updates to said in-memory database of said active node;

propagating the first row updates as first active write-through updates to a standby node;

said standby node receiving said first active write-through updates;

said standby node committing said first active write-through updates to an in-memory database of said standby node;

said standby node propagating the first active write-through updates to said disk-based primary database system to cause said disk-based primary database system to update rows belonging to said cache group in said database of said disk-based primary database system;

said active node receiving autorefresh row updates periodically propagated from said disk-based primary database system, said autorefresh row updates reflecting second row updates made to said cache group at said database of said disk-based primary database system, said second row updates being different than said first row updates;

said active node committing said autorefresh row updates to said in-memory database of said active node;

said standby node committing said autorefresh row updates to said in-memory database of said standby node; and

said standby node preventing reapplying said autorefresh updates to said disk-based database of said disk-based primary database system.

2. The method of claim 1, wherein the second row updates include a subset of row updates to a certain row in said database of said disk-based primary database system, the method further including the steps of:

said primary database system making a determination of a most recent row update of said subset of row updates,

only propagating an autorefresh row update for the most recent row update but not for other one or more row updates of said subset of row updates.

3. The method of claim 1, wherein said autorefresh row updates received by said active node are propagated by said standby node to said active node.

4. The method of claim 1, wherein the autorefresh row updates received by said active node are propagated by said active node to said standby node.

9. The method of claim 1, wherein data indicating that a source of said second row updates is not a client of said active node includes data indicating at least one of the following:

said source of said second row updates is said disk-based primary database system;

or said autorefresh row updates are of the autorefresh type.

11. The method of claim 1, wherein the steps further include said standby node propagating said first active write-through updates and said autorefresh row updates to one or more replica nodes.

5. A non-transitory computer-readable medium storing one or more sequences of instructions, which, when executed by one or more processors, cause:

from one or more clients, an active node receiving first row updates for rows belonging to a cache group that are stored within an in-memory database of said active node, said cache group being defined as a set of rows of one or more base tables stored in a database of a disk-based primary database system;

said active node committing said first row updates to said in-memory database of said active node;

propagating the first row updates as first active write-through updates to a standby node;

said standby node receiving said first active write-through updates;

said standby node committing said first active write-through updates to an in-memory database of said standby node;

said standby node propagating the first active write-through updates to said disk-based primary database system to cause said disk-based primary database system to update rows belonging to said cache group in said database of said disk-based primary database system;

said active node receiving autorefresh row updates periodically propagated from said disk-based primary database system, said autorefresh row updates reflecting second row updates made to said cache group at said database of said disk-based primary database system, said second row updates being different than said first row updates;

said active node committing said autorefresh row updates to said in-memory database of said active node;

said standby node committing said autorefresh row updates to said in-memory database of said standby node; and

said standby node preventing reapplying said autorefresh updates to said disk-based database of said disk-based primary database system.

6. The non-transitory computer-readable of claim 5, wherein the second row updates include a subset of row updates to a certain row in said database of said disk-based primary database system, wherein the instructions further include instructions for:

said primary database system making a determination of a most recent row update of said subset of row updates,

only propagating an autorefresh row update for the most recent row update but not for other one or more row updates of said subset of row updates.

7. The non-transitory computer-readable of claim 5, wherein the one or more sequences of instructions further including instructions for the autorefresh row updates received by said active node to be propagated by said standby node.

8. The non-transitory computer-readable of claim 5, wherein the one or more sequences of instructions further include instructions for the autorefresh row updates received by said active node to be propagated by said active node to said standby node.

10. The non-transitory computer-readable of claim 5, wherein data indicating that a source of said second row is not a client of said active node includes data indicating at least one of the following:

said source of said second row updates is said disk-based primary database system;

or said autorefresh row updates are of the autorefresh type.

12. The non-transitory computer-readable of claim 5, the instructions further including instructions for said standby node propagating said first active write-through updates and autorefresh row updates to one or more replica nodes.