Method and apparatus for performing conflict resolution in database logging

• US 20050102326A1
• Filed: 10/22/2003
• Published: 05/12/2005
• Est. Priority Date: 10/22/2003
• Status: Abandoned Application

• Current Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Original Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Inventors: Zernik, Dror, Peleg, Nitzan, Bortnikov, Edward
• Application Number:
  US10/691,175
• Publication Number:
  US 20050102326A1
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 16/22 Indexing; Data structures therefor; Storage structures
• CPC Class Codes: G06F 16/2393 Updating materialised views
• CPC Class Codes: G06F 16/2455 Query execution
• CPC Class Codes: G06F 16/284 Relational databases

Abstract

The disclosed embodiments relate to a system and method for performing conflict resolution when refreshing a materialized view. The system may comprise a logging mechanism that maintains a refresh log, the refresh log may contain a first range and a second range that at least partially overlap, the first range and the second range each having a timestamp associated therewith. The system may also include a refresh manager that resolves conflicts between the first range and the second range that at least partially overlap by selecting portions of the first range and the second range that have the more recent timestamp and applying the selected portions of the first range and the second range to the materialized view. In another embodiment, the system may comprise a logging mechanism that maintains a refresh log, the refresh log containing a range and a single-row entry, the range and the single row entry each having a timestamp associated therewith. The system may also include a refresh manager that resolves conflicts between the range and the single-row entry by ignoring the single-row entry if the single-row entry is part of the range and if the single-row entry has the more recent timestamp and by applying the single-row entry to the materialized view if the single-row entry is not part of the range or if the range has the more recent timestamp.

Claims

1. A system, comprising:

a materialized view that is derived at least in part from a table;

a logging mechanism that maintains a refresh log, the refresh log containing a first range and a second range that at least partially overlap, the first range and the second range each having a timestamp associated therewith; and

a refresh manager that resolves conflicts between the first range and the second range that at least partially overlap by selecting portions of the first range and the second range that have the more recent timestamp and applying the selected portions of the first range and the second range to the materialized view.

2. The system set forth in claim 1, wherein the refresh log comprises a plurality of entries, each of the entries comprising an epoch identifier.

3. The system set forth in claim 2, wherein the epoch identifier is defined to correspond to changes that have been made to the table since a previous refresh operation on the materialized view.

4. The system set forth in claim 1, wherein a plurality of materialized views are derived at least in part from the table.

5. A system, comprising:

a materialized view that is derived at least in part from a table;

a logging mechanism that maintains a refresh log, the refresh log containing a range and a single-row entry, the range and the single row entry each having a timestamp associated therewith; and

a refresh manager that resolves conflicts between the range and the single-row entry by ignoring the single-row entry if the single-row entry is part of the range and if the single-row entry has the more recent timestamp and by applying the single-row entry to the materialized view if the single-row entry is not part of the range or if the range has the more recent timestamp.

6. The system set forth in claim 5, wherein the refresh log comprises a plurality of entries, each of the entries comprising an epoch identifier.

7. The system set forth in claim 6, wherein the epoch identifier is defined to correspond to changes that have been made to the table since a previous refresh operation on the materialized view.

8. The system set forth in claim 7, wherein the single-row record belongs to an epoch E, a latest screening range belongs to an epoch E′

<

E, and the refresh manager is adapted to ignore the single-row record for a materialized view that fulfils MV.EPOCH[T]<

=E′ and

to apply the single-row record to a materialized view that fulfils MV.EPOCH[T]>

E′

.

9. The system set forth in claim 5, wherein a plurality of materialized views are derived at least in part from the table.

10. A method, comprising:

deriving a materialized view at least in part from a table;

storing a first range and a second range that at least partially overlap in a refresh log;

associating a timestamp with the first range and the second range in the refresh log; and

resolving conflicts between the first range and the second range in the portion that overlaps by applying a portion of either the first range or the second range that has the more recent timestamp to the materialized view.

11. The method for performing conflict resolution set forth in claim 10, comprising creating a plurality of records in the refresh log and storing an epoch identifier in each of the records.

12. The method for performing conflict resolution set forth in claim 11, comprising defining the epoch identifier to correspond to changes that have been made to the table since a previous refresh operation on the table.

13. The method for performing conflict resolution set forth in claim 10, comprising deriving a plurality of materialized views at least in part from the table.

14. A method, comprising:

deriving a materialized view at least in part from a table;

storing a range and a single-row entry in a refresh log, the range and the single-row entry each having a timestamp associated therewith;

ignoring the single-row entry if the single-row entry is part of the range and if the single-row entry has the more recent timestamp; and

applying the single-row entry to the materialized view if the single-row entry is not part of the range or if the range has the more recent timestamp.

15. The method set forth in claim 14, comprising storing a plurality of entries in the refresh log, each of the plurality of entries comprising an epoch identifier.

16. The method set forth in claim 15, comprising defining the epoch identifier to correspond to changes that have been made to the table since a previous refresh operation on the materialized view.

17. The method set forth in claim 16, wherein the single-row record belongs to an epoch E, a latest screening range belongs to an epoch E′

<

E, the method comprising;

ignoring the single-row record for a materialized view that fulfils MV.EPOCH[T]<

=E′

; and

applying the single-row record to a materialized view that fulfils MV.EPOCH[T]>

E′

.

18. The method set forth in claim 14, comprising deriving a plurality of materialized views at least in part from the table.

19. A computer program, comprising:

a machine readable medium;

a logging mechanism stored on the machine readable medium, the logging mechanism being adapted to create a refresh log that containins a first range and a second range that at least partially overlap, the first range and the second range each having a timestamp associated therewith; and

a refresh manager stored on the machine readable medium, the refresh manager being adapted to resolve conflicts between the first range and the second range that at least partially overlap by selecting portions of the first range and the second range that have the more recent timestamp and applying the selected portions of the first range and the second range to the materialized view.

20. The computer program set forth in claim 19, wherein the refresh log comprises a plurality of entries, each of the entries comprising an epoch identifier.

21. The computer program set forth in claim 20, wherein the epoch identifier is defined to correspond to changes that have been made to the table since a previous refresh operation on any materialized view that is derived at least in part from the table.