DE112022000767T5 - ASYNCHRONOUS PERSISTENCE OF REPLICATED DATA CHANGES IN A DATABASE ACCELERATOR - Google Patents

Abstract

A computer-executed crash recovery method for linked databases can be provided. The linked databases have a source database and an associated target database. Selected queries from the source database are transferred to the target database. The method includes synchronizing selected portions of the source database with tables of an in-memory portion of a target database and asynchronously and persistently storing persistently applied changes to the in-memory target database portion. After a database crash of the target database system, the method also includes restoring the target database in-memory portion with the most recent snapshot available and applying changes from the source database recovery log file that have a later timestamp than the most recent snapshot available in the target database persistent database portion of the target database in-memory portion.

Description

BACKGROUND

Field of invention

The invention relates generally to crash recovery for a database, and more particularly to a computer-executed method for crash recovery for linked databases. The invention further relates to a linked database system with crash recovery for linked databases and a computer program product.

Related technology

Managing large amounts of data remains a persistent problem for enterprise IT (information technology) organizations. This is due to (i) the ever-increasing amount of data and (ii) also to the diversity of data. In addition to traditional structured data, semi-structured and so-called unstructured data are also stored in large quantities in company IT systems. Furthermore, in addition to traditional transaction-oriented databases, special database systems optimized for analytical processing have been introduced to meet the industry's need for more and more data analysis. On the other hand, attempts have been made to do all analytical processing in a traditional transactional database. However, it turned out that analytical processing has too strong and unpredictable an impact on the performance of online transaction processing.

Consequently, intelligent combinations of transaction-oriented database management systems with analytics-optimized database management systems have been introduced. An example of such combined products is based on the IBM DB2 Analytics Accelerator (IDAA) architecture.

On the one hand, a complete, row-based database management system (DBMS) can serve as an application endpoint for data manipulation language (DML) operations and query executions. Using heuristic decision criteria and rules, the query optimizer can transparently decide whether a query should be executed on the source DBMS - primarily for online transaction processing - or offloaded to a target DBMS - primarily for online analytical processing.

The target DBMS may be a complete column-based database management system that maintains a shadow copy of a selected set of the source DBMS's tables. Strategies for creating shadow copies of the target DBMS may include transferring data stored in one or more tables of the source DBMS to the target DBMS at a given time. However, query data in the target DBMS may be stale if the load was performed some time ago and the corresponding source table was changed in the meantime. Therefore, the contents of the tables are typically adjusted incrementally as changes are recorded in the corresponding tables in the source database.

Both database systems implement transaction mechanisms to ensure ACID properties (ACID = Atomicity, Consistency, Isolation, Durability) of the respective database. That is, concurrent changes are properly isolated via locking techniques, consistency checks can ensure that the database state is transitioned from one consistent state to another, and logging techniques such as write-ahead logging can be performed to ensure atomicity and durability for transaction changes.

However, ensuring ACID properties can incur significant overhead if the source database is changed by current transactions. In particular, logging slows down the processing of insert/update/delete (IUD) statements because change records must be written to a persistent storage medium before transactions can proceed. Compared to the commonly used in-memory processing of changes to the contents of the database table, adding this level of persistence using transaction logs is comparatively slow. On the other hand, crash recovery is required to restore the latest consistent state of the respective database in the event of a failure.

In the context of the database accelerator, such as IDAA, the target accelerator database simply mirrors a snapshot of the source database. That is, the source database can act as the master of the data or data manipulations via IUDs can be processed by the source database management system and changes are replicated to the target database via an update technique. The accelerator database can therefore act as a cache for storing Partitions of the source database that may require fast analysis operations.

There are already several revelations in this context. The document US 2015 / 0 205 853 A1 describes a method for replicating database data and creating read-only copies of the replicated data in a properly shut down state. An associated system may include a monitoring module that monitors initial transactions from a database application to a source storage device to produce log entries that have at least one marker indicating a known good state of the application. The system further includes a computer connected to a target storage device having a database and log files. The computer processes the transactions based on the log entries to replicate data to the target storage device, takes an initial snapshot, and returns data stored in the log files to the database.

In addition, the document US 2014 / 0 279 930 A1 describes a distributed database system that performs rapid recovery after a crash. After recovering from a failure of a database head node, a connection may be established to one or more storage nodes of a distributed storage system that stores data for a database executed by the database head node. Once connected to a storage node, this database can be made available for access, such as for various access requests.

However, all of the traditional connected databases that are optimized for transactions and analytical processing can require the known overhead of maintaining persistent recovery logs, in addition to unoptimized utilization of the changes from the source database in the target database combined databases can slow down considerably. Therefore, it may be necessary to reduce the effort required to achieve higher performance levels for a combined transactional/analytical database management system while elegantly solving the target database recovery problem.

SHORT PRESENTATION

According to one aspect of the present invention, a computer-executed crash recovery method for linked databases may be provided. The linked databases may include a source database and an associated target database, and selected queries directed to a database management system comprising the source database may be transferred to a database management system comprising the target database for processing. The method may include synchronizing selected portions of the contents of tables of the source database with respective portions of the contents of tables of the target database, applying, during synchronization, changes to the source database to an in-memory target database portion of the database management system having the target database using a recovery log file of the source database and asynchronously storing changes persistently applied to the in-memory target database part in a persistent target database store.

After a database crash of the target database system, the method may include restoring the in-memory target database portion with the most recent snapshot available in the target database persistent storage and applying, after the database crash on the target database system, changes from the source database recovery log file that have a later timestamp than those in the persistent Target database storage has the most recent snapshot available, to the in-memory target database portion.

According to another aspect of the present invention, a linked database system with crash recovery for linked databases may be provided. The linked databases may include a source database and an associated target database, and selected portions of the contents of tables of the source database may be synchronized with respective portions of the contents of the tables of the target database. The linked database system may include a processor and a main memory coupled to the processor via communication, the main memory being able to store portions of program code that, when executed, enable the processor to match selected portions of the contents of tables of the source database with respective portions of the contents of tables to synchronize the target database, while synchronizing, to apply changes to the source database to an in-memory target database portion of the database management system having the target database using a recovery log file of the source database, and persistently applied changes to the in-memory target data Asynchronously store the bank part in a persistent target database storage.

Main memory may also store portions of program code that, when executed, enable the processor to restore the in-memory target database portion to the most recent snapshot available in the target database persistent memory after a database crash on the target database system and to recover changes from the recovery log file of the target database system after the database crash Source databases that have a later timestamp than the most recent snapshot available in the target database persistent storage to the in-memory target database part.

The proposed computer-executed crash recovery method for linked databases may provide several advantages, technical effects, contributions and/or improvements:

The update and change as well as the queries to the in-memory part can continue without slowdown by also persisting the changes to the target database. Thus, the logging and state storage of data structures of a physical database can be decoupled from the processing of IUDs in database transactions. This means that the persistence phase is skipped when changes are made to the target database - especially in the in-memory part - and update operations can continue without additional delay. Therefore, records that would be required for crash recovery of the target database can be written asynchronously by an associated asynchronous data persistence service. Changes made by IUD transactions are applied only to the in-memory representation of the data, where it can be immediately processed by database queries offloaded to the target database, i.e. the accelerator, regardless of whether or not it is already stored on persistent disks. This can also be interpreted as removing the persistence condition of database ACID properties.

Due to the asynchronous writing of committed changes from in-memory data structures to their persistent counterparts, some of them may be missing from the target database system in the event of a database crash. Crash recovery may therefore need to synchronize the potentially incomplete snapshot with the source database system by restoring missing changes. Unlike other solutions that do not fully reload paged tables with a bulk data loading mechanism, the missing parts can be restored incrementally. That is, the state of the target database can be restored from the most recent, asynchronously persistent snapshot of the target database and uses restore metadata to determine what additional changes may still be missing. That is, what changes from the source database must be restored by the target databases from the transaction or recovery log file of the source database system in order to ultimately restore the current consistent state of the target database.

This allows incoming queries on the target database to be delayed while the recovery processes are active until the in-memory portion of the target database is restored to a consistent and updated state. The delay caused by the restore can be significantly lower compared to known solutions, but processing and storage costs for asynchronously maintaining the database snapshot in the target database system may be slightly higher. However, this is a small price to pay for increased availability and short-term recovery times of the target database system.

Asynchronously persisting changes to the target database can also help logging to be performed more efficiently, I/O operations can be performed more efficiently - for example through a batch process - or self-compensating changes can be deleted entirely. That is, a target record that has been changed in a way that can be rolled back from changes to the target database before a next persistent storage step can be deleted in a buffer between the target database and the persistent storage medium.

Additional embodiments of the concept according to the invention - which are applicable to both the method and the system - are described below.

According to an interesting embodiment of the method, synchronizing may include reading entries of a recovery log file related to the source database and applying the read entries to the target database. This can be done through the management part of the target database management system be performed. However, other synchronization techniques can also be used, for example based on SQL (Structured Query Language) or Q, ie a query language optimized for column-based databases.

According to a single useful embodiment of the method, the source database may be optimized for transactions - i.e., online transaction processing (OLTP) - and/or wherein the source database is a row-oriented relational DBMS. This can represent and efficiently support the operational backbone of a company's IT (information technology) operations. A row-oriented database can be optimized for symmetric, fast read, write, and modify operations on the data in the database. It can also be suitable for generating reports. However, this type of database is often not optimal for analytical operations.

According to a single acceptable embodiment of the method, the target database may be optimized for analytical operations - i.e. for online analytical processing (OLAP) - and/or the target database may be a column-oriented database. This type of database - according to a further embodiment - can be a column-oriented database. It can support queries with many dependencies and cross-correlations much better than OLTP-optimized database systems.

According to an advantageous embodiment, the method can also include delaying, in the event of a crash of the target database, queries to the target database until a recovery of the target database can be completed. Thus, the recovery process can be transparent to a user. Finally, there may be a slight delay in its analysis query. However, since the response time for complex analysis queries is already comparatively long, the user may not notice the delay at all.

Optionally, queries directed at the target database can be executed by the source database during the target database recovery process. This may make the source database slightly slower during transactions, but this may be an acceptable trade-off for overall user satisfaction.

According to an advantageous embodiment of the method, metadata defining the selected tables may be part of the recovery log file. In this way, the general architecture of the target in-memory database can already be defined in the recovery log file of the source database. This may also apply to the portions of table data that are to be mirrored to the source database. This means that a single source for data definitions can be used so that no conflict situations can arise.

According to an extended embodiment of the method, saving persistently applied changes may include waiting until, if necessary, a predetermined number of changes in the in-memory target database part has been completed. The predetermined number may be configurable during configuration of the database and/or may also be changed during operation of the database management system. However, the advantage of this approach may be that it does not slow down the analysis operations of the target database. This means that a group of updates to the target database can be extracted and stored persistently in one step. In addition to using a predetermined number of changes on the target database, one may also consider monitoring the load on the target database and persisting changes to the target database during periods when the analysis load on the target database is comparatively low.

This feature can be implemented within a single thread or process that can wait until a predetermined number of changes in the in-memory portion are completed. For each change within the set of completed changes since the last execution, the changes are persisted to the persistent database part of the target database. Additionally, associated metadata describing the recently persisted change (such as the last corresponding sequence number of the block record within the source database system) is also persisted so that change replay points can be specified during the restore phase. This can result in a time of the last consistent changed record that was saved. This point in time can be useful to restore the in-memory portion of the target database from the persistent portion of the target database and to incrementally restore the remaining IUDs of the in-memory portion of the target database from the source database recovery log file. This additional data is - in the event of a required restore of the target database - from the source database or the incremental len update process requested. At the end of the recovery process, the query processor can be informed by a "back in action" signal that queries can then be processed by the target database.

According to a further advantageous embodiment of the method, restoring tables - or the partitions thereof - of the in-memory target database part may include prioritizing the restoring or restoring according to an option consisting of a data usage, a query priority and a data priority Group is selected.

These options are detailed in the paragraphs below. However, the general concept is to enable various optimization techniques during the recovery process to allow queries to be executed even though the target database is “in recovery”, i.e. in recovery mode. These optimization options can be configurable and - generally - combined in a single execution.

According to a single optional embodiment of the method, prioritizing recovery according to data usage may include maintaining a counter for each table - or a partition thereof - in the target database. The counter value of the counter can indicate how many queries may be waiting on the associated table, as well as indicate that the database table with the highest counter value will be restored first. The other tables can then be restored later. This option can enable quick recovery of those tables in the target database that are in high demand. Thus, a fully restored part of the database, i.e. the high-demand tables, can be provided to users as soon as possible. This option can be referred to as demand-optimized or data usage-optimized recovery.

Thus, the list of waiting queries can be taken into account to control the recovery process and minimize the recovery time. As soon as a new database query arrives at the target database while a restore is in progress, its data access can be analyzed. If it does not access unrecovered data, it can be processed immediately. Otherwise, the query is entered into a waiting query list as part of the recovery state. The recovery levels are evaluated through a recovery schedule to derive a sequence of recovery actions, favoring those tables and/or table partitions that actually block queries. The most useful restore action can be scheduled after the restore is complete using one of the available restore strategies, the restore state can be updated, and queries waiting on the restored table and/or partition can be notified when they no longer need to be blocked.

• (i) ermittle die nächste(n) wiederherzustellende(n) Tabellen und/oder Tabellenpartition aus der Liste;
• (ii) terminiere die Wiederherstellungsaktion über die für die Zieldatenbank konfigurierte Wiederherstellungsstrategie;
• (iii) warte, bis die Wiederherstellungsaktion abgeschlossen ist;
• (iv) aktualisiere den Wiederherstellungszustand, d.h., markiere die wiederherzustellende Tabelle/Partition und entferne die Tabelle/Partition aus der Blockierungsdatenliste einer jeden auf die Tabelle und/oder Tabellenpartition wartenden Abfrage; und
• (v) ermittle die Liste der Abfragen, deren Blockierungsdatenliste leer wurde, und benachrichtige den Abfrageprozessor, so dass er die Abfrage jetzt verarbeiten kann.

In more detail, crash recovery on the target database can be described as follows: first, the list of tables or table partitions that need to be recovered using known recovery metadata on the target database. Second, the list of tables or table partitions to be restored is stored in the restore state. Third, as long as the list to be restored is not empty, the following can be done:

• (i) determine the next table(s) and/or table partition(s) to be restored from the list;
• (ii) schedule the recovery action using the recovery strategy configured for the target database;
• (iii) wait for the recovery action to complete;
• (iv) update the recovery state, ie, mark the table/partition to be recovered and remove the table/partition from the blocking data list of each query waiting on the table and/or table partition; and
• (v) identify the list of queries whose blocking data list has become empty and notify the query processor so that it can now process the query.

The list of tables and/or table partitions to be restored may be executed through a priority queue, using the algorithm described below to dynamically calculate the next restore item for the next restore cycle. The steps mentioned in (iii) can be performed for multiple tables and/or table partitions in parallel to speed up the recovery process.

• (i) wenn der Wiederherstellungsprozess nach einem Absturz eingeleitet wird, erstelle ein leeres Histogramm von Blockierungstabellen und/oder Blockierungstabellenpartitionen;
• (ii) wenn die Blockierungsabfrage in dem Wiederherstellungszustand eingetragen wird, erhöhe den Nutzungszähler für jede Tabelle und/oder Tabellenpartition in der Blockierungsbereichsliste der Abfrage um eins;
• (iii) wenn die nächste wiederherzustellende Tabelle/Tabellenpartition ermittelt werden muss, wähle die Tabelle/Tabellenpartition aus, welche den größten Nutzungszähler hat; und
• (iv) wenn eine Wiederherstellungsaktion einer Tabelle/Tabellenpartition beendet wird, entferne die entsprechenden Histogrammdaten.

Determining which tables and/or table partitions to restore can be done as follows:

• (i) when the crash recovery process is initiated, create an empty histogram of blocking tables and/or blocking table partitions;
• (ii) if the blocking query is entered into the recovery state, increment the usage count for each table and/or table partition in the query's blocking range list by one;
• (iii) if the next table/table partition to restore needs to be determined, select the table/table partition that has the largest usage count; and
• (iv) when a table/table partition restore action terminates, remove the corresponding histogram data.

According to a further optional embodiment of the method, prioritizing the restore according to the query priority may include first restoring those database tables that receive queries with the highest priority. Such a priority value can be assigned to a database system - for example, a production database compared to a test database - or even on the basis of a single query. This option can be called query priority or simply data priority optimized recovery.

According to a further optional embodiment of the method, prioritizing recovery according to data priority may include managing (at least) two groups of database tables, each group relating to a single group of users, and initially restoring the group's database tables has a higher group priority configured. Such a situation may occur in a multi-user/multi-group/multi-tenant environment where a user or a group or a tenant may be assigned a higher priority for queries. For example, a tenant can have a higher guaranteed availability of the database system. In such a case, that tenant may be assigned a higher priority. Such a scenario may work best in a multi-tenant database operating in a cloud computing data center. This option can be referred to as customer priority optimized recovery.

According to another interesting embodiment, the method may also include determining the data volume to be restored for next tables to be restored and restoring the table(s) using a restore strategy that depends on the volume to be restored. The recovery strategy is an incremental refresh strategy or a bulk data refresh strategy. Thus, database table by database table (or group of database tables) it can be decided which update strategy should be used to minimize the overall recovery time of the target database. This option can be called time-optimized recovery.

Additionally, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium, the program code for use by or in connection with a computer or any instruction execution system Instruction execution system provides. For purposes of this description, a computer-usable or computer-readable medium may be any device that may contain means for converting the program for use by the instruction execution system, instruction execution device or device, or for use in conjunction with the instruction execution system Store, transmit, distribute or transport instruction execution device or unit.

BRIEF DESCRIPTION OF THE VARIOUS VIEWS OF THE DRAWINGS

It should be noted that embodiments of the invention will be described with reference to various subject matter. In particular, some embodiments are described with reference to method claims, whereas other embodiments are described with reference to device claims. However, the person skilled in the art will understand from the above and the following description that, unless otherwise stated, in addition to any combination of features belonging to a type of object, also any combination between features relating to different objects, in particular between features of the Method claims and features of the device claims, is considered a combination to be disclosed in this document.

The aspects defined above and other aspects of the present invention will be apparent from the examples of embodiments to be described below and will be discussed with reference to the examples of embodiments men explained, to which the invention is not limited.

• 1 zeigt ein Blockschaubild einer Ausführungsform des erfindungsgemäßen, durch einen Computer ausgeführten Verfahrens für eine Wiederherstellung nach einem Absturz für verknüpfte Datenbanken.
• 2 zeigt ein Blockschaubild einer Ausführungsform von verknüpften Datenbanken.
• 3 zeigt ein Blockschaubild einer Ausführungsform der Art und Weise, in der die Zieldatenbank synchronisiert werden kann.
• 4 zeigt ein Blockschaubild einer Ausführungsform des vorgeschlagenen Konzepts in einer ausführungsnäheren Form.
• 5 zeigt ein Blockschaubild einer Ausführungsform des verknüpften Datenbanksystems, das Komponenten für eine kundenprioritätsoptimierte Wiederherstellungsstrategie aufweist.
• 6 zeigt ein Blockschaubild einer Ausführungsform des verknüpften Datenbanksystems, das Komponenten für eine volumenoptimierte Wiederherstellungsstrategie aufweist.
• 7 zeigt ein Blockschaubild einer Ausführungsform des verknüpften Datenbanksystems für eine Wiederherstellung nach einem Absturz für verknüpfte Datenbanken.
• 8 zeigt eine Ausführungsform eines Datenverarbeitungssystems, welches das verknüpfte Datenbanksystem aufweist.

Preferred embodiments of the invention are described by way of example only and with reference to the following drawings:

• 1 1 shows a block diagram of an embodiment of the computer-executed method for crash recovery for linked databases according to the invention.
• 2 shows a block diagram of an embodiment of linked databases.
• 3 shows a block diagram of an embodiment of the manner in which the target database may be synchronized.
• 4 shows a block diagram of an embodiment of the proposed concept in a more detailed form.
• 5 shows a block diagram of an embodiment of the linked database system having components for a customer priority optimized recovery strategy.
• 6 shows a block diagram of an embodiment of the linked database system having components for a volume-optimized recovery strategy.
• 7 shows a block diagram of an embodiment of the linked database system for crash recovery for linked databases.
• 8th shows an embodiment of a data processing system that has the linked database system.

DETAILED DESCRIPTION

The following conventions, terms and/or expressions may be used in the context of this description:

The term “crash recovery” can refer to a process of restoring a database to a state that the database was in before the crash occurred. If a crash occurs, data may be unavailable or inconsistent.

The term “linked databases” can mean at least two databases that are closely linked to each other. In the context of this document, linked databases can be referred to as those that can store, at least partially, identical data. On the other hand, in such a pair, the primary database may be optimized for different tasks than the secondary database.

The term “source database” - or “primary database” - can refer to a database that is optimized, for example, for fast transactions, i.e. online transaction processing. However, databases optimized in this way - i.e. for fast read, write, update operations on the data - can be slow in performing complex queries involving a large number of tables or a large number of data, as in the case of online -Analysis processing. Additionally, online analytics processing can slow down online transaction processing. Therefore, highly optimized database management systems of the database types just mentioned can work successfully in tandem.

The term “target database” or “secondary database” can mean the second database in such a tandem of databases that is optimized for different tasks. In the context of the concept described here, the target database may be optimized for online analytical processing. It can store at least parts of the tables and parts of the data in the tables of the source database. The target database may also consist of two parts: an in-memory part for fast execution of complex and multi-dimensional queries and a persistent part that can store the tables and data of the in-memory part of the target database in the longer-term storage, such as a hard drive or flash memory . This can allow the target database - in the event of a crash of the target database - to recover most of its contents from persistent storage.

The term “selected parts of the contents of tables” may mean the aforementioned parts or partitions of data from parts of the tables of the primary database that can be copied and kept synchronous in the target database.

The term "selected queries" can refer to a specific type of queries directed at the linked databases, which, depending on the type of query, are better executed by one of the two databases - in particular the target database. For example, if the type of query is related to online analytical processing, the query may be routed to the target database and may not be executed by the source database.

The term “database management system” can refer to a combination of administration/management system, usually in one Combination of hardware and software and at least one associated database that stores the data.

The term “in-memory target database part” can refer to the part of the target database that can hold almost all of its data in the main memory of the computer system. The database management system of the target database may have an in-memory portion and a persistent portion of the target database, where the persistent portion may be a persistently stored copy of the in-memory portion, except for recent changes to the in-memory portion.

The term "target database persistent storage" may describe the part of the target database management system capable of storing the target database's data persistently, i.e. using a hard drive or flash memory instead of in-memory storage.

The term “most recent snapshot” may mean a most recent consistent saved state of the target database.

For example, the term "later timestamp" - particularly a change that has a later timestamp - may mean a record of the source database's recovery log file that has a time indication that may be taken later in time than the most recent snapshot stored by the persistent portion of the target database.

The term "recovery log file" can mean a sequential file that logs operations performed on a database, particularly all those operations that modify the data, i.e. insert, update and delete operations. The recovery log file can be intended to enable a full recovery of the database. Therefore, the database table definitions can also be part of the recovery log file.

The term “metadata” can mean data about data, particularly a definition of data from tables in a database and possibly relationships between them.

The figures are described in detail below. All instructions in the figures are schematic. First, a block diagram of an embodiment of the computer-executed method for crash recovery for linked databases according to the invention is shown.

Further embodiments and embodiments of the linked database system with crash recovery for linked databases will then be described.

1 shows a block diagram of a preferred embodiment of the computer-executed method 100 for crash recovery for linked databases - in particular according to an IDAA architecture - where the provided, 102, linked databases a source or primary database - in particular optimized for transactions - e.g. a role-based database - and an associated target or secondary database. This can be optimized for online analytical processing operations (OLAP) and advantageously organized in a column-based manner.

Selected queries - in particular those aimed at analysis operations - to a database management system that has the source database are transferred for processing to a database management system that has the target database, i.e. outsourced.

The method 100 also includes synchronizing, 104, selected portions of the contents of tables of the source database - in some databases only portions of data from portions of the tables and in other embodiments a complete copy - with respective portions of the contents of tables of the target database, by applying changes to the source database to an in-memory target database portion of the database management system having the target database using a recovery log file of the source database during synchronization, 106.

Additionally, the method 100 includes asynchronously storing, 108, persistently applied changes to the in-memory target database portion in a persistent target database storage portion and, after a database crash on the target database system, restoring, 110, the in-memory target database portion with the most current snapshot available in the persistent target database storage, and applying, 112, after the database crash of the target database system, to the in-memory target database portion, changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage.

Optionally, the persistent part of the target database can also be updated in parallel. In addition However, the persistent storage process or storage processor would also have to be active to persist changes to the in-memory part of the target database.

Additionally, it may be advantageous to load the target database with bulk data from the source database, particularly during an initialization process. This can help avoid the comparatively slower incremental update or synchronization process as the source database may already have a larger number of entries and thus a larger number of entries in its recovery log file. Initialization can also work for selected tables or just partitions of them.

2 shows a block diagram of an embodiment 200 of linked databases. The primary or source database 202 receives OLTP queries 210 and OLAP queries 214. Those queries specified as OLAP queries 214 are transferred or offloaded 222 to the secondary or target database 206. The source database 202 has a plurality of tables 204 and associated stored data. The target database 206 also includes tables that represent at least a subset of the database tables 204 of the source database 202 and at least a subset of the data in the database tables 208.

After the OLAP operation is performed by the target database 206, the data is returned 224 and the OLAP output 220 is returned back to the requesting program or process. OLTP queries 210 are executed directly on the source database 202 and returned as OLTP output 212 to the requesting program or process. Thus, the OLTP or source database 202 can operate at peak performance because it is not slowed down by resource-intensive OLAP queries.

Due to a possible different data organization in the target database 206 - e.g., column-oriented instead of row-oriented as in the source or OLTP database 202 - the target database may return OLAP results much faster than the source database 202, 224.

3 shows a block diagram of an embodiment 300 of the manner in which the target database may be synchronized. The source database management system 302 controls the operation of the source database 202 and its associated tables 204 (see 2 ). The same applies to the target database management system 308 for the target database 206 and the associated tables 208.

The source database management system 302 also manages the recovery log file 306 for the source database 202. A log reader or log file reader 314, which reads the recovery log file 306, provides this data to the application unit 316, which contains the changes made to the source database (i.e., insert, update, delete). also applies to the target database 206 for the selected tables and set of data. The selected tables and set of data may be a subset of those associated tables and data in the source database 202 that were previously defined. The application entity 316 can optimize the application of the changes to the target database 206 depending on OLAP queries being executed. The protocol buffer 318 can be helpful for this.

To initialize the target database 206, an operation 312 to load bulk data from the source database 202 into the target database 206 may be performed for performance reasons.

It should be noted that 3 - for reasons of clarity of the concept according to the invention - does not yet show the division of the target database management system into an in-memory part and a persistent part of the target database 206 and its tables 208. This is shown in the next figure.

It should be noted that this synchronization mechanism can represent one of many synchronization techniques. Other synchronization techniques may also be applicable.

4 shows a block diagram of an embodiment of the proposed concept in a more detailed form 400. The elements of the source database management system in those which are optionally used to interface the source database with the target database (mainly the upper part of 4 ) to synchronize are not described again.

The target database management system 308 includes the in-memory portion 402 of the target database and the persistent portion 404 of the target database. The persistence service 406 writes the status of the in-memory target database part 402 to the persistent database 404 during operation. During such periodic operations - for example, after a predetermined number of Updates have been made to the in-memory database 402 - the query processor 408 transmits the incoming queries to the in-memory portion 402 of the target database.

• (i) der Abfrageprozessor 408 analysiert zusammen mit dem Wiederherstellungsprozessor 410 die Datenzugriffe der Abfragen, um eine Liste von Zieltabellen und/oder Listen von Tabellenpartitionen zu ermitteln, die für die Abfrage zur Verfügung stehen müssen, wobei Query-Parsing-a-View-Lösungsverfahren nach dem Stand der Technik verwendet werden;
• (ii) eine Blockierungsdatenliste wird ermittelt, indem man sich alle Tabellen und/oder Tabellenpartitionen der Datenzugriffsliste aus dem vorherigen Schritt innerhalb des Wiederherstellungszustands anschaut, der noch nicht wiederhergestellt wurde;
• (iii) wenn die Liste aus dem vorherigen Schritt nicht leer ist, werden die Abfrage und ihre Blockierungsdatenliste zu der wartenden Abfrage hinzugefügt, und der Abfrageprozess wartet, bis die Wiederherstellung beendet wird (die Blockierungsdatenliste wird leer), dann kann das Abfragen fortgesetzt werden; und
• (iv) die Abfrage der Zieldatenbank wird wie üblich verarbeitet, nachdem eine Abschlussbenachrichtigung von dem Wiederherstellungsprozessor 410 an den Abfrageprozessor 408 gesendet wurde.

However, if the target DBMS is currently performing crash recovery - particularly in the case of demand-optimized or data-usage optimized recovery - things work differently:

• (i) the query processor 408, together with the recovery processor 410, analyzes the data accesses of the queries to determine a list of target tables and/or lists of table partitions that must be available for the query, using query parsing-a-view solving techniques be used according to the state of the art;
• (ii) a blocking data list is determined by looking at all tables and/or table partitions of the data access list from the previous step within the recovery state that have not yet been recovered;
• (iii) if the list from the previous step is not empty, the query and its blocking data list are added to the waiting query, and the query process waits until the recovery finishes (the blocking data list becomes empty), then querying can continue; and
• (iv) the query of the target database is processed as usual after a completion notification has been sent from the recovery processor 410 to the query processor 408.

During the action controlled by the recovery processor 410, the most current consistent snapshot of the relevant tables and/or table partitions available in the persistent database 404 is loaded into the in-memory portion 402 of the target database, 412, and the entries in the recovery log file 306 of the source database 202, which are a have a later time stamp than the snapshot of the persistent database 404 are imported back into the in-memory database 402. These are requested by the recovery processor 410 via the query processor 408 from the source DBMS 302, e.g. from the recovery log file 306 via the log reader unit 314 and the application unit 316.

5 shows a block diagram of an embodiment 500 of the linked database system that includes components for a customer priority optimized recovery strategy. The source DBMS 542 exemplarily has a first source database 504 of a first user or tenant (eg, in a cloud computing environment) and a second source database 506 of a second user or tenant. Additionally, individual source database systems may be available to other users or tenants.

Individual data synchronization subsystems 510, 512 are implemented in the data synchronization system 508 to synchronize the source databases 504, 508 with the respective in-memory parts 518, 520 of the in-memory target database 516. The query process 522 receives the database queries for execution in the in-memory portion of the target database(s) 516. These queries are typically OLAP queries that have been offloaded from the source database(s) 504, 506.

The recovery process or recovery processor 524 of the target DBMS 514 also receives data from the query processor regarding queries to be entered into and analyzed in the data access analysis component 526. During the target database restore process, the query analysis component determines the waiting queries 530 and the already restored table partitions 532 in the restore state management system 528 to determine which tables should be restored first based on a priority of queries from a particular user. This is ultimately determined and decided by the recovery schedule 534. To perform this task, the recovery schedule 534 is in constant communication with the recovery state management system 528 to check the actual recovery status and receives configuration data from the workload management system's configuration store. In addition, the recovery schedule 534 also exchanges data with the data synchronization system 508 to trigger a load of the target database management system's recovery database from the source database management system 502.

In this way, it can be ensured that the user or customer with a configured higher priority has early access to restored database tables, the recovery time of which can also be optimized depending on the use of access from specific tables.

Specifically, this can be achieved through the following procedure: If the crash recovery process for the target data bank is initialized, an empty histogram of blocked table/partitions is created for each tenant. When a new blocking query is entered into the recovery state, the usage count for each table/partition in the query's blocking data list is incremented by 1. Then, when a next table/partition to be restored needs to be determined, a restore priority of the table is determined based on the blocked query usage count and the tenant's current workload management system (WLM) configuration (i.e., its priority or importance). and the highest priority recovery item is selected. Finally, when the restore action of the table/partition is completed, the corresponding histogram entry is also removed.

The calculation of user or tenant specific restore priorities can be carried out as an example: If there is a strict priority between tenant pairs - e.g. a production system is more important than a test system (which can be specified by a simple configuration text), the list of restores is calculated Tables/partitions grouped by user/tenant; the list of groups is ordered by decreasing user/tenant priority; and the next table/partition is selected from the first non-empty group via the query usage counter selection algorithm.

However, if there is a relative resource sharing position for each tenant in the WLM configuration (e.g. Tenant-1 50%, Tenant-2 30%, Tenant-3 20%), a priority for each recovery item becomes as follows calculates: (i) the query usage counter q for the recovery item is determined; (ii) then the tenant t that owns the recovery item is determined; (iii) next, the resource sharing position r(t) is determined for the tenant t; (iv) based on this, the priority is determined as a * q * b * r(t), where a and b are static configuration parameters - in particular in the range between [0 ... 1] - where b is based on a, e.g. b = 1-a, can be calculated to reduce the number of parameters. Finally (v) the list of recovery items can be ordered by priority, e.g. in a priority queue.

6 shows a block diagram of an embodiment 600 of the linked database system that includes components for a volume-optimized recovery strategy. Already with 5 introduced elements are shown with the same reference numbers. The source DBMS 502 is shown at the top left with a source database 504 and an associated recovery log file 604. First, the in-memory database portion 516 of the target DBMS 514 (with the persistent portion not shown) may be loaded with bulk data via the bulk data loader 602.

In addition to the in-memory part 516 of the target DBMS 514, the focus here may be on other metadata 608 and the recovery process or recovery processor 614. The restore process has at least three components: the restore item selector 616, the change estimate unit 618, and the restore schedule 620. The restore processor 614 communicates with the in-memory database 516 to provide status information about the tables in the in-memory database portion 516 of the target DBMS 514 capture.

If a database crash occurs on the target DBMS side, the target database 516 must be recovered from the source database 504 either through a bulk data loading mechanism or incrementally, as previously described. In addition, the table/table partitions to be restored are dynamically selected here by the restore process 614. The concept proposed here is extended to include a change estimation component 618, which is responsible for estimating or determining the amount of data that needs to be restored during crash recovery. Therefore, this change estimation component 618 evaluates data change statistics to extrapolate how many data changes have accumulated in the source database since a recovery baseline timestamp. Based on this information, the restore schedule 620 selects the most efficient data synchronization method for restoring the data of the table/table partition to be restored. The data change statistics are maintained during periodic update processing, either incrementally or via a bulk data load, of the target database (i.e., the in-memory database portion 516). The change estimate 618 may be triggered by the recovery item selection component 616.

The recovery schedule 620 is also in communication with the loader 602 for loading bulk data and with details of the incremental update process 606 to support the recovery process to manage the in-memory database part 516. For example, when the restore of the in-memory database portion 516 is complete, a restore completion notification is received from the bulk data loader 602. On the other hand, the recovery schedule 620 requests change commits for specific tables in the in-memory database portion 516. Similar to the signal from the bulk data loaders 602, the restore schedule 620 also receives a restore completion notification from the incremental update process(or) 606. As discussed in the context of 3 As described, the incremental update process 606 includes the log reader unit (not shown here) configured to read the recovery log file entries from the recovery log file 604, and the recovery log file application unit (not shown here) configured to that it incrementally updates the main storage database portion 516 using the respective recovery log file entries from the source database 504. Stay tuned for details 3 referred.

To successfully manage the process of the embodiment described herein, data change statistics should be stored and managed in the persistent metadata catalog contained in the metadata 608 of the target database system 514 when the target database system 514 is updated, i.e. via the incremental update strategy or the bulk data load strategy. It may store the following information: (i) a timestamp of when the update was processed; (ii) Schema information of the database tables, e.g. column types, column widths, ...; (iii) the amount of data changes per table/table partition that were affected by the update; i.e. inserted records and deleted records, updated records; and aggregated metrics such as the total number of records changed, the total volume of data applied, the total execution time of updates, etc.

The statistical data can be linked to a time interval, e.g. the last x days. Additionally, the statistics data can be managed incrementally as part of each update cycle.

In addition, the recovery baseline 610 is also maintained in the persistent metadata 608 (e.g., a metadata catalog) of the target database system 514. It is needed for estimation to determine the volume of data that needs to be restored. Therefore, it is not necessary to determine an exact timestamp, rather interpolating the value is sufficient, e.g.: It can be managed as a heartbeat timestamp, which is updated by the target database system at regular time intervals; it can be managed as a starting point of the crash recovery process; and it can be managed as the time of the last successfully persisted snapshot of the target database. The timestamp can be managed for each table in the target database.

Crash recovery on the target database can be performed as follows: (i) first, the next table/partition to be recovered is determined; (ii) the volume of data to be restored since the restore baseline is estimated; (iii) the best recovery strategy is selected based on the estimated data volume and the recovery time is estimated; (iv) then the table recovery is scheduled using the selected strategy; and (v) these steps are repeated in a loop until all data has been restored.

The estimation of the data volumes to be restored can be carried out as follows: (i) for a table/partition to be restored, the corresponding data change statistics 612 are searched; (ii) the recovery baseline for the table/partition is determined; and (iii) the number of changes that need to be replicated via the incremental update process at the interval [recovery baseline, current recovery time] is interpolated.

7 shows a block diagram of an embodiment of the linked database system 700 for crash recovery for linked databases. The linked databases 700 include a source database 706 and an associated target database 708, wherein selected portions of the contents of tables of the source database are synchronized with respective portions of the contents of the tables of the target database.

The linked database system 700 includes a processor 702 and a main memory 704 communicated to the processor 702, the main memory 704 storing portions of program code that, when executed, enable the processor to match selected portions of the contents of tables of the source database 706 with respective ones Sharing the contents of tables of the target database 708 - for example using a synchronization unit 714 - to synchronize.

The stored program code portions which, when executed, enable the processor 702 to apply - using an application unit 716 - changes to the source database 706 during synchronization to the in-memory target database portion 710 of the database management system having the target database and - for example, through a storage processor 718 - asynchronously save changes applied to the in-memory target database part 712 in a persistent target database storage.

In addition, the stored program code portions, when executed, enable the processor 702 - for example through a recovery unit 720 - to restore the in-memory target database portion 710 with the most current snapshot available in the target database persistent storage portion 712 following a database crash on the target database system and - for example through a second one Application entity 722 - after the database crash on the target database system, apply changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage portion 712 to the in-memory target database portion 710.

It should also be noted that all modules and units of the linked database system 700 may be electrically connected to one another for signal and/or data exchange. This may be for the processor 702, the main memory 704, the source database system 706, the target database system 708, which includes the in-memory part 710 and the persistent part 712, the synchronization unit 714, the application unit 716, the storage processor 718, the recovery unit 720 and the second application unit 722 apply. Instead of a 1:1 connection between these modules and units, they can also be connected to an internal bus system 724 of a linked database system for signaling data exchange.

Embodiments of the invention may be implemented with virtually any type of computer, regardless of the platform suitable for storing and/or executing program code. 8th shows, as an example, a data processing system 800 suitable for executing program code related to the proposed method.

The data processing system 800 is merely an example of a suitable computer system and, regardless of whether the computer system 800 is executable and/or capable of performing any of the functionality set forth above, should not be considered as an indication of a limitation on the scope of use or functionality of embodiments of the The invention described herein can be understood. There are components in the computer system 600 that are operable with various other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments and/or configurations that may be suitable for use with the computer system/server 800 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick Clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems and distributed cloud computing environments, any of the foregoing systems or devices include, and the like. The computer system/server 800 may be described in the general context of computer system-executable instructions, such as program modules executed by a computer system 800. In general, program modules can include routines, programs, objects, components, logic, data structures, and so on that perform specific tasks or execute specific abstract data types. The computer system/server 800 may be practiced in distributed cloud computing environments where tasks are performed by remote processing units connected by a communications network. In a distributed cloud computing environment, program modules can reside in both local and remote storage media of a computer system, including main storage devices.

As shown in the figure, the computer system/server 800 is shown in the form of a general purpose data processing unit. The components of the computer system/server 800 may include, but are not limited to, one or more processors or processing units 802, a system memory 804, and a bus 806 that connect various system components, including the system memory 804, to the processor 802. Bus 806 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not by way of limitation, these architectures include: Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a local Video Electronics Standards Association (VESA) bus bus and a Peripheral Component Interconnects (PCI) bus. The computer system/server 800 typically includes a variety of media readable by a computer system. These media may be any available media accessible by the computer system/server 800 and include both volatile and non-volatile media as well as removable and non-removable media.

System memory 804 may include computer system-readable volumes in the form of volatile memory, such as a random access memory (RAM) 808 and/or a cache 810. The computer system/server 800 may further include other removable/non-removable, volatile/non-volatile storage media of a computer system. By way of example only, a storage system 812 may be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and commonly referred to as a “hard disk drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM or other optical data carrier. In these cases, each drive may be connected to bus 806 through one or more disk interfaces. As further illustrated and described below, main memory 804 may include at least one program product that has a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the invention.

By way of example, and not limitation, the program/utility having a set (at least one) of program modules 816 may be stored in main memory 804, as well as an operating system, one or more application programs, other program modules, and program data. The operating systems, one or more application programs, other program modules and program data, or a combination thereof, may each comprise an execution of a network environment. The program modules 816 generally perform the functions and/or procedures of embodiments of the invention described herein.

The computer system/server 800 may also be equipped with one or more external devices 818 such as a keyboard, a pointing device, a monitor 820, etc.; with one or more devices that enable a user to interact with the computer system/server 800; and/or any units (e.g. network card, modem, etc.) that enable the computer system/server 800 to exchange data with one or more other data processing units. Such data exchange can occur via input/output (I/O) interfaces 814. However, the computer system/server 800 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via a network adapter 822. As shown, the network adapter 822 may communicate with the other components of the computer system/server 800 via the bus 806. It should be understood that other hardware and/or software components could also be used in connection with the computer system/server 800, although these are not shown. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems, etc.

Additionally, the linked database system 700 may be connected to the bus system 806 with crash recovery for linked databases.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variants will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over marketed technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

The present invention may be a system, a method and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for use by a processor to carry out aspects of the present invention.

The medium may be an electronic, magnetic, optical, electromagnetic, infrared or a semiconductor system for a distribution medium. Examples of a computer-readable medium include a semiconductor or solid-state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a magnetic hard disk, and an optical disk belong. Current examples of optical disks include a compact disk read-only memory (CD-ROM), a CD-RW, a digital video disk (DVD), and a Blu-Ray disk.

The computer readable storage medium may be a physical device that can retain and store instructions for use by an instruction execution system. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media include the following: a removable computer diskette, a hard drive, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a removable compact disk read-only memory (CD-ROM), a DVD (digital versatile disc), a memory stick, a floppy disk, a mechanically coded device such as for example, punch cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, is not intended to be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through an optical fiber cable). ) or electrical signals transmitted through a wire.

Computer-readable program instructions described herein may be transferred from a computer-readable storage medium to respective computing/processing devices or via a network such as the Internet, a local area network, a wide area network, and/or a wireless network to an external computer or device external storage device can be downloaded. The network may include copper transmission cables, fiber optic transmission cables, wireless transmission, routing computers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing/processing unit.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or either source code or object code which are written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++ or similar, as well as traditional procedural programming languages such as the “C” programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA), may execute the computer-readable program instructions by reading state information of the use computer-readable program instructions to personalize the electronic circuits to carry out aspects of the present invention.

Aspects of the present invention are described herein with reference to flowcharts and/or block diagrams of methods, devices (systems) and computer programs products according to embodiments of the invention are described. It is noted that each block of the flowcharts and/or the block diagrams or diagrams, as well as combinations of blocks in the flowcharts and/or the block diagrams or diagrams, can be executed using computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that the instructions executed via the processor of the computer or other programmable data processing device provide a means for implementing the in Generate functions/steps defined in the block or blocks of the flowcharts and/or the block diagrams or diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can control a computer, a programmable data processing device, and/or other devices to function in a particular manner, such that the computer-readable storage medium , on which instructions are stored, a product of manufacture, including instructions which implement aspects of the function/step specified in the block or blocks of the flowchart and/or the block diagrams or diagrams.

The computer-readable program instructions may also be loaded onto a computer, other programmable data processing device, or other device to cause a series of process steps to be executed on the computer, other programmable device, or other device to be executed on a computer Process so that the instructions executed on the computer, other programmable device or other device implement the functions/steps defined in the block or blocks of the flowcharts and / or the block diagrams or diagrams.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this context, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for performing the specified logical function(s). In some alternative embodiments, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown one after the other may in reality be executed largely simultaneously, or the blocks may sometimes be executed in reverse order depending on the relevant functionality. It should also be noted that each block of the block diagrams and/or the flowcharts, as well as combinations of blocks in the block diagrams or diagrams and/or the flowcharts, can be implemented by special hardware-based systems that implement the specified functions or the specified Perform step, or execute combinations of specialized hardware and computer instructions.

The terminology used herein is intended solely to describe certain embodiments and is not to be construed as limiting the invention. As used herein, the singular forms "a", "an" and "the", "the", "the" shall also include the plural forms unless the context clearly indicates otherwise. It is further noted that the terms “comprising” and/or “comprising” when used in this specification denote the presence of specified features, integers, steps, operations, elements and/or components or but does not exclude the addition of one or more other/further features, integers, steps, operations, elements, components and/or groups thereof.

The corresponding structures, materials, operations and equivalents of any means or steps plus functional elements in the following claims are intended to include any structure, material or operation for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been made for purposes of illustration and explanation, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the invention. The embodiments are chosen and described in order to best explain the principles of the invention and its practical application and to enable others skilled in the art to understand the invention in terms of various embodiments with various modifications as may be applicable to each intended use.

• 1. Durch einen Computer ausgeführtes Verfahren zur Wiederherstellung nach einem Absturz für verknüpfte Datenbanken, wobei die verknüpften Datenbanken eine Quellendatenbank und eine zugehörige Zieldatenbank aufweisen, wobei ausgewählte, an ein Datenbankverwaltungssystem gerichtete Abfragen, welches die Quellendatenbank aufweist, zur Verarbeitung an ein Datenbankverwaltungssystem übertragen werden, das die Zieldatenbank aufweist, wobei das Verfahren umfasst
  • - Synchronisieren von ausgewählten Teilen vom Inhalt von Tabellen der Quellendatenbank mit jeweiligen Teilen vom Inhalt von Tabellen der Zieldatenbank,
  • - Anwenden, während des Synchronisierens, von Änderungen an der Quellendatenbank auf einen speicherinternen Zieldatenbankteil des Datenbankverwaltungssystems, das die Zieldatenbank aufweist, und
  • - asynchrones Speichern von persistent angewandten Änderungen an dem speicherinternen Zieldatenbankteil in einem persistenten Zieldatenbankspeicher,
  • - Wiederherstellen, nach einem Datenbankabsturz auf dem Zieldatenbanksystem, des speicherinternen Zieldatenbankteils mit der in dem persistenten Zieldatenbankspeicher verfügbaren aktuellsten Momentaufnahme und
  • - Anwenden, nach dem Datenbankabsturz auf dem Zieldatenbanksystem, von Änderungen aus der Wiederherstellungsprotokolldatei der Quellendatenbank, die einen späteren Zeitstempel als die in dem persistenten Zieldatenbankspeicher verfügbare aktuellste Momentaufnahme haben, auf den speicherinternen Zieldatenbankteil.
• 2. Verfahren nach Ausführungsform 1, wobei das Synchronisieren aufweist:
  • - Lesen von Einträgen einer Wiederherstellungsprotokolldatei, die sich auf die Quellendatenbank bezieht, und Anwenden der gelesenen Einträge auf die Zieldatenbank.
• 3. Verfahren nach Ausführungsform 1 oder 2, wobei die Quellendatenbank für Transaktionen optimiert und/oder wobei die Quellendatenbank ein zeilenorientiertes relationales Datenbankverwaltungssystem ist.
• 4. Verfahren nach einer der vorhergehenden Ausführungsformen, wobei die Zieldatenbank für Analyseoperationen optimiert und/oder die Zieldatenbank eine spaltenorientierte Datenbank ist.
• 5. Verfahren nach einer der vorhergehenden Ausführungsformen, das auch umfasst
  • - Verzögern, im Falle eines Absturzes der Zieldatenbank, von Abfragen an die Zieldatenbank, bis eine Wiederherstellung der Zieldatenbank beendet ist.
• 6. Verfahren nach einer der vorhergehenden Ausführungsformen, wobei Metadaten, welche die ausgewählten Tabellen definieren, Teil der Wiederherstellungsprotokolldatei sind.
• 7. Verfahren nach einem der vorhergehenden Ausführungsformen, wobei das Speichern von persistent angewandten Änderungen aufweist
  • - Warten, bis eine vorher festgelegte Anzahl von Änderungen in dem speicherinternen Zieldatenbankteil abgeschlossen wurde.
• 8. Verfahren nach einer der vorstehenden Ausführungsformen, wobei das Wiederherstellen von Tabellen des speicherinternen Zieldatenbankteils ein Priorisieren des Wiederherstellens gemäß einer Option aufweist, die aus der aus einer Datennutzung, einer Abfragepriorität und einer Datenpriorität bestehenden Gruppe ausgewählt wird.
• 9. Verfahren nach Ausführungsform 8, wobei das Priorisieren der Wiederherstellung gemäß der Datennutzung aufweist
  • - Verwalten eines Zählers für jede Tabelle in der Zieldatenbank, wobei der Zählerwert des Zählers anzeigt, wie viele Abfragen auf die zugehörige Tabelle warten, und
  • - zunächst erfolgendes Wiederherstellen der Datenbanktabelle mit dem höchsten Zählerwert zuerst.
• 10. Verfahren nach Ausführungsform 8 oder 9, wobei das Priorisieren der Wiederherstellung gemäß der Abfragepriorität aufweist
  • - zunächst erfolgendes Wiederherstellen der Datenbanktabellen, die Abfragen mit der höchsten Priorität empfangen.
• 11. Verfahren nach einer der Ausführungsformen 8 bis 10, wobei das Priorisieren der Wiederherstellung gemäß der Datenpriorität aufweist
  • - Verwalten von zwei Gruppen von Datenbanktabellen, wobei sich jede Gruppe auf eine einzelne Gruppe von Benutzern bezieht, und
  • - zunächst erfolgendes Wiederherstellen der Datenbanktabellen der Gruppe, die eine höher konfigurierte Gruppenpriorität hat.
• 12. Verfahren nach einer der vorhergehenden Ausführungsformen, das auch umfasst
  • - Ermitteln des Datenvolumens, das für eine nächste wiederherzustellende Tabelle wiederhergestellt werden soll,
  • - Wiederherstellen der Tabelle unter Verwendung einer Wiederherstellungsstrategie in Abhängigkeit von dem wiederherzustellenden Volumen, wobei die Wiederherstellungsstrategie eine inkrementelle Aktualisierungsstrategie oder eine Strategie zum Aktualisieren von Massendaten ist.
• 13. Verknüpftes Datenbanksystem mit Wiederherstellung nach einem Absturz für verknüpfte Datenbanken, wobei die verknüpften Datenbanken eine Quellendatenbank und eine zugehörige Zieldatenbank aufweisen, wobei ausgewählte Teile vom Inhalt von Tabellen der Quellendatenbank mit jeweiligen Teilen des Inhalts der Tabellen der Zieldatenbank synchronisiert werden, wobei das verknüpfte Datenbanksystem aufweist
  • - einen Prozessor und einen per Datenaustausch mit dem Prozessor verbundenen Hauptspeicher, wobei der Hauptspeicher Programmcodeteile speichert, die, wenn sie ausgeführt werden, dem Prozessor ermöglichen,
  • - ausgewählte Teile des Inhalts der Tabellen der Quellendatenbank mit jeweiligen Teilen des Inhalts von Tabellen der Zieldatenbank zu synchronisieren,
  • - während des Synchronisierens Änderungen an der Quellendatenbank auf einen speicherinternen Zieldatenbankteil des Datenbankverwaltungssystems, das die Zieldatenbank aufweist, anzuwenden und
  • - persistent angewandte Änderungen an dem speicherinternen Zieldatenbankteil asynchron in einem persistenten Zieldatenbankspeicher zu speichern,
  • - nach einem Datenbankabsturz auf dem Zieldatenbanksystem den speicherinternen Zieldatenbankteil mit der in dem persistenten Zieldatenbankspeicher verfügbaren aktuellsten Momentaufnahme wiederherzustellen und
  • - nach dem Datenbankabsturz auf dem Zieldatenbanksystem Änderungen aus der Wiederherstellungsprotokolldatei der Quellendatenbank, die einen späteren Zeitstempel als die in dem persistenten Zieldatenbankspeicher verfügbare aktuellste Momentaufnahme haben, auf den speicherinternen Zieldatenbankteil anzuwenden.
• 14. Verknüpftes Datenbanksystem nach Ausführungsform 13, wobei die Programmcodeteile dem Prozessor auch ermöglichen,
  • - die Einträge einer Wiederherstellungsprotokolldatei, die sich auf die Quellendatenbank bezieht, für das Synchronisieren zu lesen und die gelesenen Einträge auf die Zieldatenbank anzuwenden.
• 15. Verknüpftes Datenbanksystem nach Ausführungsform 13 oder 14, wobei die Quellendatenbank für Transaktionen optimiert und/oder wobei die Quellendatenbank ein zeilenorientiertes relationales Datenbankverwaltungssystem ist.
• 16. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 15, wobei die Zieldatenbank für Analyseoperationen optimiert und/oder die Zieldatenbank eine spaltenorientierte Datenbank ist.
• 17. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 16, wobei die Programmcodeteile dem Prozessor auch ermöglichen,
  • - im Falle eines Absturzes der Zieldatenbank Abfragen an die Zieldatenbank zu verzögern, bis eine Wiederherstellung der Zieldatenbank beendet ist.
• 18. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 17, wobei Metadaten, welche die ausgewählten Tabellen definieren, Teil der Wiederherstellungsprotokolldatei sind.
• 19. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 18, wobei die Programmcodeteile dem Prozessor auch ermöglichen,
  • - auf das Speichern von persistent angewandten Änderungen zu warten, bis eine vorher festgelegte Anzahl von Änderungen in dem speicherinternen Zieldatenbankteil abgeschlossen wurde.
• 20. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 19, wobei das Wiederherstellen von Tabellen des speicherinternen Zieldatenbankteils ein Priorisieren des Wiederherstellens gemäß einer Option aufweist, die aus der aus einer Datennutzung, einer Abfragepriorität und einer Datenpriorität bestehenden Gruppe ausgewählt wird.
• 21. Verknüpftes Datenbanksystem nach Ausführungsform 21, wobei die Programmcodeteile dem Prozessor für das Priorisieren der Wiederherstellung gemäß der Datennutzung auch ermöglichen,
  • - einen Zähler für jede Tabelle in der Zieldatenbank zu verwalten, wobei der Zählerwert des Zählers anzeigt, wie viele Abfragen auf die zugehörige Tabelle warten, und
  • - zunächst die Datenbanktabelle mit dem höchsten Zählerwert zuerst wiederherzustellen.
• 22. Verknüpftes Datenbanksystem nach Ausführungsform 20 oder 21, wobei die Programmcodeteile dem Prozessor für das Priorisieren der Wiederherstellung gemäß der Abfragepriorität auch ermöglichen,
  • - zunächst die Datenbanktabellen wiederherzustellen, die Abfragen mit der höchsten Priorität empfangen.
• 23. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 20 bis 22, wobei die Programmcodeteile dem Prozessor für das Priorisieren der Wiederherstellung gemäß der Datenpriorität auch ermöglichen,
  • - zwei Gruppen von Datenbanktabellen zu verwalten, wobei sich jede Gruppe auf eine einzelne Gruppe von Benutzern bezieht, und
  • - zunächst die Datenbanktabellen der Gruppe wiederherzustellen, die eine höher konfigurierte Gruppenpriorität hat.
• 24. Verknüpftes Datenbanksystem nach einer der Ausführungsformen 13 bis 15, wobei die Programmcodeteile dem Prozessor auch ermöglichen,
  • - das Datenvolumen zu ermitteln, das für eine nächste wiederherzustellende Tabelle wiederhergestellt werden soll,
  • - die Tabelle unter Verwendung einer Wiederherstellungsstrategie in Abhängigkeit von dem wiederherzustellenden Volumen wiederherzustellen, wobei die Wiederherstellungsstrategie eine inkrementelle Aktualisierungsstrategie oder eine Strategie zum Aktualisieren von Massendaten ist.
• 25. Computerprogrammprodukt für ein verknüpftes Datenbanksystem mit Wiederherstellung nach einem Absturz für verknüpfte Datenbanken, wobei die verknüpften Datenbanken eine Quellendatenbank und eine zugehörige Zieldatenbank aufweisen, wobei ausgewählte Teile vom Inhalt von Tabellen der Quellendatenbank mit jeweiligen Teilen des Inhalts von Tabellen der Zieldatenbank synchronisiert werden, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium mit damit verkörperten Programmanweisungen aufweist, wobei die Programmanweisungen durch ein oder mehrere Datenverarbeitungssysteme oder Controller ausführbar sind, um das eine oder die mehreren Datenverarbeitungssysteme dazu zu veranlassen,
  • - einen Prozessor und einen per Datenaustausch mit dem Prozessor verbundenen Hauptspeicher, wobei der Hauptspeicher Programmcodeteile speichert, die, wenn sie ausgeführt werden, dem Prozessor ermöglichen,
  • - ausgewählte Teile vom Inhalt von Tabellen der Quellendatenbank mit jeweiligen Teilen vom Inhalt von Tabellen der Zieldatenbank zu synchronisieren,
  • - während des Synchronisierens Änderungen an der Quellendatenbank auf einen speicherinternen Zieldatenbankteil des Datenbankverwaltungssystems, das die Zieldatenbank aufweist, anzuwenden und
  • - persistent angewandte Änderungen an dem speicherinternen Zieldatenbankteil asynchron in einem persistenten Zieldatenbankspeicher zu speichern,
  • - nach einem Datenbankabsturz auf dem Zieldatenbanksystem den speicherinternen Zieldatenbankteil mit der in dem persistenten Zieldatenbankspeicher verfügbaren aktuellsten Momentaufnahme wiederherzustellen und
  • - nach dem Datenbankabsturz auf dem Zieldatenbanksystem Änderungen aus der Wiederherstellungsprotokolldatei der Quellendatenbank, die einen späteren Zeitstempel als die in dem persistenten Zieldatenbankspeicher verfügbare aktuellste Momentaufnahme haben, auf den speicherinternen Zieldatenbankteil anzuwenden.

In brief, the concept according to the invention can be summarized in the following embodiments:

• 1. A computer-implemented crash recovery method for linked databases, the linked databases comprising a source database and an associated target database, wherein selected queries directed to a database management system comprising the source database are transmitted to a database management system for processing, which the target database has, the method comprising
  • - synchronizing selected parts of the contents of tables in the source database with respective parts of the contents of tables in the target database,
  • - Apply, during synchronization, changes to the source database to an in-memory target database portion of the database management system having the target database, and
  • - asynchronously storing persistently applied changes to the in-memory target database part in a persistent target database store,
  • - Restore, after a database crash on the target database system, the in-memory target database portion with the most recent snapshot available in the target database persistent storage and
  • - Apply, after the database crash on the target database system, to the in-memory target database portion changes from the source database recovery log file that have a later timestamp than the most recent snapshot available in the target database persistent storage.
• 2. Method according to embodiment 1, wherein synchronizing comprises:
  • - Reading entries from a recovery log file related to the source database and applying the read entries to the target database.
• 3. The method according to embodiment 1 or 2, wherein the source database is optimized for transactions and/or wherein the source database is a row-oriented relational database management system.
• 4. Method according to one of the preceding embodiments, wherein the target database is optimized for analysis operations and/or the target database is a column-oriented database.
• 5. Method according to one of the preceding embodiments, which also includes
  • - In the event of a target database crash, delay queries to the target database until a target database recovery is complete.
• 6. The method according to any one of the preceding embodiments, wherein metadata defining the selected tables is part of the recovery log file.
• 7. Method according to one of the preceding embodiments, wherein saving persistently applied changes
  • - Wait for a predetermined number of changes to be completed in the in-memory target database part.
• 8. The method of any of the preceding embodiments, wherein restoring tables of the in-memory target database portion includes prioritizing the restoring according to an option selected from the group consisting of data usage, query priority, and data priority.
• 9. The method of embodiment 8, comprising prioritizing recovery according to data usage
  • - Maintain a counter for each table in the target database, where the counter value of the counter shows how many queries are waiting on the associated table, and
  • - restoring the database table with the highest counter value first.
• 10. The method of embodiment 8 or 9, wherein prioritizing recovery according to query priority
  • - first restoring the database tables that receive queries with the highest priority.
• 11. The method of any of embodiments 8 to 10, comprising prioritizing recovery according to data priority
  • - Manage two groups of database tables, each group relating to a single group of users, and
  • - first restoring the database tables of the group that has a higher configured group priority.
• 12. Method according to one of the preceding embodiments, also comprising
  • - Determine the volume of data to be restored for a next table to be restored,
  • - Restore the table using a recovery strategy depending on the volume to be restored, where the recovery strategy is an incremental update strategy or a bulk data update strategy.
• 13. A linked database system with crash recovery for linked databases, the linked databases comprising a source database and an associated target database, wherein selected portions of the contents of tables of the source database are synchronized with respective portions of the contents of the tables of the target database, the linked database system having
  • - a processor and a main memory connected to the processor via data exchange, the main memory storing parts of program code which, when executed, enable the processor to
  • - synchronize selected parts of the content of the tables of the source database with respective parts of the content of tables of the target database,
  • - during synchronization, apply changes to the source database to an in-memory target database portion of the database management system having the target database and
  • - save persistently applied changes to the in-memory target database part asynchronously in a persistent target database storage,
  • - after a database crash on the target database system, restore the in-memory target database portion with the most recent snapshot available in the target database persistent storage and
  • - After the database crash on the target database system, apply changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage to the in-memory target database part.
• 14. Linked database system according to embodiment 13, wherein the program code parts also enable the processor to
  • - read the entries of a recovery log file related to the source database for synchronization and apply the read entries to the target database.
• 15. The linked database system of embodiment 13 or 14, wherein the source database is optimized for transactions and/or wherein the source database is a row-oriented relational database management system.
• 16. Linked database system according to one of embodiments 13 to 15, wherein the target database is optimized for analysis operations and/or the target database is a column-oriented database.
• 17. Linked database system according to one of embodiments 13 to 16, wherein the program code parts also enable the processor to
  • - In the event of a crash of the target database, to delay queries to the target database until a recovery of the target database has been completed.
• 18. A linked database system according to any one of embodiments 13 to 17, wherein metadata defining the selected tables is part of the recovery log file.
• 19. Linked database system according to one of embodiments 13 to 18, wherein the program code parts also enable the processor to
  • - wait to save persistently applied changes until a predetermined number of changes have been completed in the in-memory target database part.
• 20. The linked database system of any one of embodiments 13 to 19, wherein restoring tables of the in-memory target database portion includes prioritizing the restoring according to an option selected from the group consisting of data usage, query priority, and data priority.
• 21. Linked database system according to embodiment 21, wherein the program code parts are assigned to the processor for prioritizing the data also enable production according to data usage,
  • - maintain a counter for each table in the target database, where the counter value of the counter indicates how many queries are waiting on the associated table, and
  • - first restore the database table with the highest counter value first.
• 22. A linked database system according to embodiment 20 or 21, wherein the program code portions also enable the processor to prioritize recovery according to query priority,
  • - first restore the database tables that receive queries with the highest priority.
• 23. An associated database system according to any one of embodiments 20 to 22, wherein the program code portions also enable the processor to prioritize recovery according to data priority,
  • - manage two groups of database tables, each group relating to a single group of users, and
  • - first restore the database tables of the group that has a higher configured group priority.
• 24. Linked database system according to one of embodiments 13 to 15, wherein the program code parts also enable the processor to
  • - determine the volume of data to be restored for a next table to be restored,
  • - restore the table using a recovery strategy depending on the volume to be restored, wherein the recovery strategy is an incremental update strategy or a bulk data update strategy.
• 25. Computer program product for a linked database system with crash recovery for linked databases, the linked databases comprising a source database and an associated target database, wherein selected portions of the contents of tables of the source database are synchronized with respective portions of the contents of tables of the target database, wherein the computer program product has a computer-readable storage medium with program instructions embodied therein, the program instructions being executable by one or more data processing systems or controllers in order to cause the one or more data processing systems to do so,
  • - a processor and a main memory connected to the processor via data exchange, the main memory storing parts of program code which, when executed, enable the processor to
  • - synchronize selected parts of the contents of tables in the source database with respective parts of the contents of tables in the target database,
  • - during synchronization, apply changes to the source database to an in-memory target database portion of the database management system having the target database and
  • - save persistently applied changes to the in-memory target database part asynchronously in a persistent target database storage,
  • - after a database crash on the target database system, restore the in-memory target database portion with the most recent snapshot available in the target database persistent storage and
  • - After the database crash on the target database system, apply changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage to the in-memory target database part.

Claims (25)

A computer-implemented crash recovery method for linked databases, the linked databases comprising a source database and an associated target database, wherein selected queries directed to a database management system comprising the source database are transmitted for processing to a database management system comprising the target database, the method comprising: synchronizing selected portions of the contents of tables of the source database with respective portions of the contents of tables of the target database; Apply, during synchronization, changes to the source database to an in-memory target database portion of the database management system that has the target database; asynchronously storing persistently applied changes to the in-memory target database portion in a persistent target database store; After a database crash on the target database system, recovering the in-memory target database portion with the most recent snapshot available in the target database persistent storage; and applying, after the database crash on the target database system, to the in-memory target database portion changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage. Procedure according to Claim 1 , wherein synchronizing comprises: reading entries of a recovery log file related to the source database and applying the read entries to the target database. Procedure according to Claim 1 , where the source database is optimized for transactions or where the source database is a row-oriented relational database management system. Procedure according to Claim 1 , where the target database is optimized for analysis operations or the target database is a column-oriented database. Procedure according to Claim 1 , which also includes: In the event of a target database crash, delaying queries to the target database until a recovery of the target database is complete. Procedure according to Claim 1 , where metadata defining the selected tables is part of the recovery log file. Procedure according to Claim 1 , where saving persistently applied changes comprises: waiting until a predetermined number of changes have completed in the in-memory target database part. Procedure according to Claim 1 wherein restoring tables of the in-memory target database portion includes prioritizing the restoring according to an option selected from the group consisting of data usage, query priority, and data priority. Procedure according to Claim 8 wherein prioritizing recovery according to data usage comprises: maintaining a counter for each table in the target database, the counter value of the counter indicating how many queries are waiting on the associated table; and restoring the database table with the highest count value first. Procedure according to Claim 8 , wherein prioritizing restore according to query priority includes: first restoring the database tables that receive queries with the highest priority. Procedure according to Claim 8 , wherein prioritizing recovery according to data priority includes: managing two groups of database tables, each group relating to a single group of users: and first restoring the database tables of the group that has a higher configured group priority. Procedure according to Claim 1 , which also includes: determining the volume of data to be restored for a next table to be restored: restoring the table using a restore strategy depending on the volume to be restored, the restore strategy being an incremental refresh strategy or a bulk data refresh strategy. A linked database system with crash recovery for linked databases, the linked databases comprising a source database and an associated target database, wherein selected portions of the contents of tables of the source database are synchronized with respective portions of the contents of the tables of the target database, the linked database system comprising: a processor and a main memory connected to the processor via communication, the main memory storing parts of program code which, when executed, enable the processor to: - synchronize selected parts of the contents of the tables of the source database with respective parts of the contents of tables of the target database; apply changes to the source database to an in-memory target database portion of the database management system having the target database during synchronization; and asynchronously store persistently applied changes to the target database in-memory portion in a target database persistent store: after a database crash on the target database system, restore the target database in-memory portion with the most current snapshot available in the target database persistent store; and after the database crash on the target database system, apply changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage to the in-memory target database portion. Linked database system according to Claim 13 , wherein the program code parts also enable the processor to: read the entries of a recovery log file relating to the source database for synchronization and apply the read entries to the target database. Linked database system according to Claim 13 , where the source database is optimized for transactions or where the source database is a row-oriented relational database management system. Linked database system according to Claim 13 , where the target database is optimized for analysis operations or the target database is a column-oriented database. Linked database system according to Claim 13 , whereby the program code parts also enable the processor: in the event of a crash of the target database, to delay queries to the target database until a recovery of the target database has been completed. Linked database system according to Claim 13 , where metadata defining the selected tables is part of the recovery log file. Linked database system according to Claim 13 , wherein the program code portions also enable the processor to: wait to save persistently applied changes until a predetermined number of changes have been completed in the in-memory target database portion. Linked database system according to Claim 13 wherein restoring tables of the in-memory target database portion includes prioritizing the restoring according to an option selected from the group consisting of data usage, query priority, and data priority. Linked database system according to Claim 20 , wherein the program code parts also enable the processor to prioritize recovery according to data usage: maintain a counter for each table in the target database, the counter value of the counter indicating how many queries are waiting for the associated table; and first restore the database table with the highest counter value first. Linked database system according to Claim 20 , wherein the program code portions for prioritizing recovery according to query priority also enable the processor to: first recover the database tables that receive queries with the highest priority. Linked database system according to Claim 20 , wherein the program code parts also enable the processor for prioritizing recovery according to data priority to: maintain two groups of database tables, each group relating to a single group of users; and first restore the database tables of the group that has a higher configured group priority. Linked database system according to Claim 13 , wherein the program code parts also enable the processor to: determine the volume of data to be restored for a next table to be restored; and restore the table using a restore strategy depending on the volume to be restored, the restore strategy being an incremental update strategy or a bulk data update strategy. Computer program product for a linked database system with crash recovery for linked databases, the linked databases comprising a source database and an associated target database, wherein selected portions of the contents of tables of the source database are synchronized with respective portions of the contents of tables of the target database, the computer program product a computer-readable storage medium with program instructions embodied therein, the program instructions being executable by one or more data processing systems or controllers to process the one or more data processing systems to cause: a processor and a main memory connected to the processor via data exchange, the main memory storing parts of program code which, when executed, enable the processor to: selected parts of the contents of tables of the source database with respective parts of the contents of tables of the synchronize target database; apply changes to the source database to an in-memory target database portion of the database management system having the target database during synchronization; and asynchronously store persistently applied changes to the in-memory target database portion in a persistent target database store; after a database crash on the target database system, restore the in-memory target database portion with the most recent snapshot available in the target database persistent storage; and after the database crash on the target database system, apply changes from the recovery log file of the source database that have a later timestamp than the most recent snapshot available in the target database persistent storage to the in-memory target database portion.

Images