Branch-based recovery in a database system

Patent metadata

Field	Value
Publication number	US-11093485-B2
Application number	US-201916552119-A
Country	US
Kind code	B2
Filing date	Aug 27, 2019
Priority date	Aug 27, 2019
Publication date	Aug 17, 2021
Grant date	Aug 17, 2021

Abstract

A staging table created in a database system may store a snapshot of live database table captured prior to an unintended change to the live database table. One or more entries in the staging table may be updated to incorporate one or more intended changes to the live database table that occurred after the unintended change. The live database table may be updated by merging each of the updated entries from the staging table to the live database table. The updated database table may eliminate the unintended change.

First claim

The invention claimed is:

1. A computer-implemented method implemented a database system, the method comprising:
receiving via a communication interface a message identifying a designated change of a sequence of changes to a live database table as unintended;
creating a staging table in the database system upon receiving the message, the staging table storing a snapshot of the live database table, the snapshot of the live database table being captured prior to the unintended change to the live database table;
updating one or more entries in the staging table, the updated entries incorporating one or more intended changes to the live database table that occurred after the unintended change; and
updating the live database table by merging each of the updated entries from the staging table to the live database table, the updated live database table eliminating the unintended change.

2. The method recited in claim 1 , wherein updating the one or more entries comprises replaying an instruction transmitted via an application procedure interface and associated with one of the intended changes.

3. The method recited in claim 1 , wherein updating the one or more entries comprises executing a database script associated with one of the intended changes.

4. The method recited in claim 1 , the method further comprising:
determining a logical difference between the live database table and the staging table, the logical difference identifying one or more data rows that differ between the live database table and the staging table.

5. The method recited in claim 1 , the method further comprising:
applying to the staging table a database branch correction script, the database branch correction script replacing the unintended change.

6. The method recited in claim 1 , the method further comprising:
locking the live database table prior to updating the live database table; and
unlocking the live database table after updating the live database table.

7. The method recited in claim 1 , wherein merging each of the updated entries from the staging table to the live database table comprises applying a merge policy.

8. The method recited in claim 1 , wherein the merge policy identifies one or more conditions under which to copy an entry from the staging table to the live database table.

9. The method recited in claim 1 , wherein the merge policy identifies an entry if a collision is detected between a live database table entry and a staging table database entry.

10. The method recited in claim 1 , the method further comprising:
deleting one or more rows from the live database table prior to updating the live database table.

11. The method recited in claim 1 , the method further comprising:
prior to updating one or more entries in the staging table, restoring the live database table based on the snapshot.

12. The method recited in claim 1 , wherein the live database table is stored in a multitenant database, the live database table including a plurality of rows, each row being associated with an organizational identifier that identifies a tenant associated with data stored in the row.

13. The method recited in claim 1 , wherein the live database table is stored in a dynamic schema database, the live database table including a plurality of rows, each row being associated with a respective entity definition that defines one or more data types for column values associated with the row, at least two of the rows being associated with different entity definitions.

14. A database system implemented on a computer system, the database system comprising:
a live database table storing data that has been updated by a sequence of changes;
a communication interface configured to receive a message identifying a designated one of the changes as unintended;
a staging table created upon receiving the message to store a snapshot of the live database table, the snapshot of the live database table being captured prior to the unintended change to the live database table; and
a processor configured to update one or more entries in the staging table to incorporate one or more intended changes to the live database table that occurred after the unintended change and to update the live database table by merging each of the updated entries from the staging table to the live database table, the updated live database table eliminating the unintended change.

15. The database system recited in claim 14 , wherein updating the one or more entries comprises replaying an instruction transmitted via an application procedure interface and associated with one of the intended changes.

16. The database system recited in claim 14 , wherein updating the one or more entries comprises executing a database script associated with one of the intended changes.

17. The database system recited in claim 14 , wherein the computer system is further configured to:
determine a logical difference between the live database table and the staging table, the logical difference identifying one or more data rows that differ between the live database table and the staging table.

18. The database system recited in claim 14 , wherein the computer system is further configured to:
apply to the staging table a database branch correction script, the database branch correction script replacing the unintended change.

19. One or more non-transitory computer readable media having instructions stored thereon for performing a method in a database system, the method comprising:
receiving via a communication interface a message identifying a designated change of a sequence of changes to a live database table as unintended;
creating a staging table in the database system upon receiving the message, the staging table storing a snapshot of the live database table, the snapshot of the live database table being captured prior to the unintended change to the live database table;
updating one or more entries in the staging table, the updated entries incorporating one or more intended changes to the live database table that occurred after the unintended change; and
updating the live database table by merging each of the updated entries from the staging table to the live database table, the updated live database table eliminating the unintended change.

20. The one or more non-transitory computer readable media recited in claim 19 , wherein updating the one or more entries comprises replaying an instruction transmitted via an application procedure interface and associated with one of the intended changes.

Assignees

• Salesforce Com Inc

Inventors

• Chainani Mikhail
• Wang Xiaodan
• Devadhar Vijayanth

Classifications

• G06F16/215 Primary

  Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors · CPC title

• G06F16/2379 Primary

  Updates performed during online database operations; commit processing · CPC title

• G06F16/2343

  Locking methods, e.g. distributed locking or locking implementation details · CPC title