Volatile database caching in database accelerators

Abstract

A computer-implemented method is provided for crash recovery for linked databases, the linked databases including a source database and an associated target database, where selected portions of the contents of tables in the source database are synchronized with respective portions of the contents of tables in the target database, whereby selected queries for a database management system including the source database are transferred to a database management system including the target database for processing. Additionally, the method includes synchronizing portions of the contents of selected tables in the target database with portions of the contents of selected tables in the source database by reading entries in a recovery log file relating to the source database and applying the read entries to the target database.

Description

Technical Field

[0001] The present invention generally relates to a method for crash recovery for a database, and more particularly to a computer-implemented method for crash recovery for a linked database. The present invention further relates to a linked database system having crash recovery for a linked database, and a computer program product.

Background Art

[0002] Managing large amounts of data continues to be an ongoing challenge for enterprise IT (information technology) organizations. This is both (i) in terms of the ever-increasing amount of data, and (ii) in terms of diverse data. Enterprise IT systems store large amounts of semi-structured data and so-called unstructured data in addition to conventional structured data. Further, to meet the growing industrial requirements for data analysis, special database systems optimized for analytical processing have been introduced in addition to conventional transaction-oriented databases. On the other hand, attempts have been made to perform all analytical processing in conventional transaction databases. However, it has become clear that analytical processing has too strong and unpredictable an impact on the performance of online transaction processing.

[0003] As a result, a clever combination of a transaction-oriented database management system and an analysis-optimized database management system has been introduced. An example of such a combined product is based on the IBM DB2 (registered trademark of IBM) Analytics Accelerator (IDAA: IBM DB2 Analytics Accelerator) architecture.

[0004] On the other hand, a full-fledged row-based database management system (DBMS) may act as the application endpoint for data manipulation language (DML) operations and query execution. Using heuristic decision criteria and rules, the query optimizer may transparently determine whether the query should be executed in the source DBMS, particularly for online transaction processing, or offloaded to the target DBMS, particularly for online analytical processing.

[0005] The target DBMS may be a full-fledged column-based database management system that maintains shadow copies of a selected set of source DBMS tables. Strategies for creating shadow copies in the target DBMS may include transferring data stored in one or more tables in the source DBMS to the target DBMS at a given point in time. However, query data in the target DBMS may become outdated if the load occurred some time ago and the corresponding source tables were modified in the meantime. Therefore, table contents are typically adapted incrementally as changes are recorded in the corresponding source database tables.

[0006] Both database systems implement transaction mechanisms to guarantee the ACID (atomic, consistent, isolated, durable) properties of their respective databases. That is, concurrent modifications may be appropriately isolated by locking techniques, consistency checks may ensure that the database state moves from one consistent state to another, and logging techniques, such as writing to logs, may be implemented to guarantee atomicity and durability against transactional changes.

[0007] However, guaranteeing ACID properties can incur significant overhead when the source database is modified by the current transaction. In particular, logging slows down the processing of insert / update / delete (IUD) statements because the change record must be written to persistent storage before the transaction can continue. Adding this persistence layer with transaction logging is relatively slow compared to the frequently used in-memory processing of changes to database table contents. On the other hand, crash recovery is required to restore the most recent consistent state of each database in the event of failure.

[0008] In database accelerator scenarios such as those involving IDAA, the target accelerator database simply mirrors a snapshot of the source database. That is, the source database may act as the master of data, or data operations via IUDs may be handled by the source database management system, and the changes may be replicated to the target database via update technologies. Thus, the accelerator database may act as a cache for storing partitions of the source database that may require high-speed analytical operations.

[0009] In this technological context, several disclosures already exist. The document in Patent Document 1 describes a hardware accelerator that helps a host database system process its queries. This hardware accelerator includes a purpose-specific processing element that can receive database query / operation tasks in the form of machine code database instructions, execute them in hardware without software, and return the query / operation results to the host system.

[0010] In addition, the document in Patent Document 2 describes a distributed database system that enables high-speed crash recovery. Upon recovery from a database head node failure, a connection may be established with one or more storage nodes of a distributed storage system that stores data for the database implemented by that database head node. Upon establishing the connection with the storage nodes, the database may be made available for access, for example, to various access requests.

[0011] However, all traditional combined databases, optimized for transactions on one side and for analytical processing on the other, may require a known overhead to maintain persistent recovery logs, which can significantly slow down the combined database's performance. Therefore, reducing the required overhead may be necessary to achieve higher performance values ​​for combined transactional / analytic database management systems. [Prior art documents] [Patent Documents]

[0012] [Patent Document 1] U.S. Patent No. 9 141 670 (B2) [Patent Document 2] U.S. Patent Application Publication No. 2014 / 0 279 930(A1) [Overview of the Initiative]

[0013] According to one aspect of the present invention, a computer-based method for crash recovery for a linked database may be provided. The linked database may include a source database and an associated target database, and selected portions of the table contents of the source database may be synchronized with the respective portions of the table contents of the target database. Selected queries against a database management system including the source database may be transferred to a database management system including the target database for processing. This method may include synchronizing selected portions of the table contents in the target database with selected portions of the table contents in the source database by reading entries in a recovery log file related to the source database and applying the read entries to the target database.

[0014] According to another aspect of the present invention, a linked database system having crash recovery for linked databases may be provided. The linked database may include a source database and an associated target database, and selected portions of the table contents of the source database may be synchronized with the respective portions of the table contents of the target database. Furthermore, selected queries against a database management system including the source database may be transferred to a database management system including the target database for processing.

[0015] A linked database system may include a processor and memory communicatively coupled to the processor, the memory storing a program code portion, which, when executed, allows the processor to read entries in a recovery log file related to the source database and apply the read entries to the target database, thereby synchronizing a portion of the contents of a selected table in the target database with a portion of the contents of a selected table in the source database.

[0016] The proposed computer implementation methods for crash recovery against linked databases may offer numerous advantages, technical benefits, contributions, or improvements, or a combination thereof.

[0017] The overhead associated with maintaining a linked database may be significantly reduced. This is because the target database and its associated database management system do not bear the burden of maintaining their own transaction or recovery logs, or both. Therefore, maintaining persistent data storage for the target database, which can slow down the target database's performance, is not required. The fact that the target database is typically used as an analytical system, i.e., for OLAP operations, and that it can often run in memory, means that it is not necessary to constantly update persistent data storage to maintain a history of transactions performed.

[0018] Traditionally, each database, i.e., the source and target databases, may have its own associated recovery log file containing metadata for the definitions of tables in its respective database. In the event of a crash, the source database's recovery log file may be used to recover the target database, thus completely avoiding the overhead and performance degradation of the OLAP-mode target database. Therefore, the source and target databases do not need to have the same database support infrastructure, for example, as part of their respective database management systems, and may have different support components. This allows the set of support components for the source database to be more feature-rich, while the target database may not have to include transaction log files or recovery log files, or both, containing their respective metadata. However, in an optional embodiment, metadata for the database table definitions may also be stored as part of the database management system for the target database. In either case, both database systems may implement transaction mechanisms to guarantee the ACID (Atomicity, Consistency, Isolation, Durability) properties of the databases.

[0019] Additional embodiments applicable to the method and related systems will be described below.

[0020] According to one useful embodiment of this method, the source database may be optimized for transactions, i.e., online transactional processing (OLTP). This may efficiently support the operational backbone of enterprise IT (information technology) operations.

[0021] According to an acceptable embodiment of this method, the source database may be a row-oriented relational database. This type of database is optimized for high-speed read, write, and modify operations on the data within the database. Row-oriented databases may also be effective for generating reports. However, this type of database is not optimal for analytical operations.

[0022] According to an advanced embodiment of this method, the target database may be optimized for analytical operations, i.e., online analytical processing (OLAP). According to a further embodiment, this type of database may be a column-oriented database. This database may support queries with many dependencies and cross-correlations considerably better than OLTP-optimized database systems.

[0023] According to one further improved embodiment of this method, the target database may be an in-memory database. Since OLAP applications and queries may need to compare a lot of data from many different database tables, data caching has proven to be too slow. Therefore, storing all or almost all data in memory may be a good way to reduce response times, even for unoptimized self-service OLAP query applications.

[0024] According to a further developed embodiment, the method may also include delaying queries to the target database until the recovery of the target database is complete in case of a crash of the target database. Thus, queries to the target database, or queries redirected to the target database, are not ignored. Those queries may be blocked until the target database can be operational for querying again. During that time, according to a more intelligent embodiment of the method, queries targeting the target database may be executed in the source database during the recovery of the target database.

[0025] Thus, the user may not be required to stop queries to the linked database system and may only experience a slower performance. This feature may be configurable.

[0026] According to a further useful embodiment of the method, the recovery of the target database may be performed by a bulk load of data from the source database. Such a bulk load may be related only to a part of the content of a table, i.e., only those configured to be synchronized in the target database.

[0027] According to an optional embodiment, the method may also include initializing the target database by a direct bulk load process of data from the source database to the target database. Additionally here, only selected content of selected parts of the table may be bulk loaded. This may be faster than using the recovery log file of the source database for the initial recovery load of the target database. Thus, the recovery log file may be used only during regular operation and updates of the target database, or to recover this database in case of a crash of the source database, or both.

[0028] According to an advantageous embodiment of this method, the metadata defining the selected table may be part of the recovery log file. This may enable the recovery of the target database after a crash using a regular update mechanism for the target database.

[0029] According to another advantageous embodiment of this method, the target database management system may not include a recovery log file. Thus, the only recovery log file for the linked database may be that of the source database. This may ensure that the target database can always be reconstructed according to the current state of the source database after a crash. Additionally, this may make the recovery process "simpler" as it does not require the collation of the recovery log files of the source and target databases. Also, disk space may be saved as there may be no need to save the recovery log file for the target database.

[0030] A further embodiment may take the form of a computer program product accessible from a computer-usable medium or computer-readable medium providing program code for use by, or in relation to, a computer or any instruction execution system. A computer-usable medium or computer-readable medium for the purposes of this description may be any device that can include means for storing, communicating, propagating, or transporting a program for use by, or in relation to, an instruction execution system, apparatus, or device.

[0031] The embodiments of the present invention are described with reference to different subject matter. In particular, some embodiments are described with reference to method-type claims, while others are described with reference to apparatus-type claims. However, those skilled in the art will infer from the above and below descriptions that, unless otherwise indicated, any combination of features relating to different subject matter, in addition to any combination of features relating to one type of subject matter, is also disclosed in this document, particularly any combination of features relating to method-type claims and features relating to apparatus-type claims.

[0032] The embodiments defined above and further embodiments of the present invention will become apparent from the examples of embodiments described below, and will be described with reference to the examples of embodiments, but the present invention is not limited thereto.

[0033] A preferred embodiment of the present invention will be described as merely an example with reference to the following drawings. [Brief explanation of the drawing]

[0034] [Figure 1] This is a block diagram showing an embodiment of a computerized method of the present invention for crash recovery against a linked database. [Figure 2] This is a block diagram showing an embodiment of a linked database. [Figure 3] A block diagram showing embodiments of how the target database is synchronized. [Figure 4] This is a block diagram showing an embodiment of a linked database system. [Figure 5] Figure 4 shows an embodiment of a computer system including a linked database system. [Modes for carrying out the invention]

[0035] In the context of this description, the following conventions, terms, or expressions, or combinations thereof, may be used.

[0036] The term "crash recovery" may refer to the process of reconstructing the database state to what it was before the crash occurred. When the crash occurred, the data may be unavailable or inconsistent.

[0037] The term “linked database” may refer to at least two databases that are closely related to each other. In the context of this document, a linked database may be defined as a database that may store at least partially the same data. On the other hand, the primary database in such a pair may be optimized for different tasks than the secondary database.

[0038] The terms "source database" or "primary database" may refer to a database optimized for high-speed transactions, such as online transaction processing. However, a database optimized in this way—for high-speed read, write, and update operations on data—may be slow when executing complex queries involving a large number of tables or data, such as in online analytical processing. In addition, online analytical processing can slow down online transaction processing. Therefore, a highly optimized database management system for the type of database mentioned above may function as a tandem system.

[0039] The terms “target database” or “secondary database” may refer to a second database in such a tandem of databases optimized for different tasks. In the context of the concepts described herein, the target database may be optimized for online analytical processing. The target database may store at least some of the tables and some of the data in the source database.

[0040] The term “selected portion of table contents” may refer to the portion or partition of data in a table in the primary database that can be synchronously copied and stored in the target database.

[0041] The term "synchronized" may indicate that the data in the target database, which is selected to be synchronized between the first and second databases, may be continuously updated based on the state of the data in the source database. This may apply to all operations performed on the data in the target database, namely insertion, update, and deletion.

[0042] The term “selected query” may refer to a specific type of query directed to a linked database that, based on the nature of the query, is considered better executed by one of the databases, particularly the target database. For example, when the query type relates to online analytical processing, the query may be forwarded to the target database and may not be executed by the source database.

[0043] The term "database management system" may typically refer to a combination of hardware and software, and an operational / management system implemented in at least one associated database that stores data.

[0044] The term "recovery log file" may refer to a set of file protocol operations performed in a database, particularly all operations that modify data, namely insertion, update, and delete operations. Recovery log files may be designed to allow for a complete reconstruction of the database. Therefore, the database table definitions may also be part of the recovery log file.

[0045] The term "metadata" may refer to data about data, particularly definition data for tables in a database, and potentially the relationships between them.

[0046] A detailed description of the drawings is given below. All instructions in the drawings are schematic. First, a block diagram of an embodiment of the computer implementation method of the present invention for crash recovery against a linked database is given. Then, further embodiments and embodiments of a linked database system having crash recovery against a linked database will be described.

[0047] Figure 1 shows a block diagram of a preferred embodiment of the computer implementation method 100 of the present invention for crash recovery against a linked database, designed, for example, according to the IDAA architecture. The linked database includes providing a source or primary database and an associated target or secondary database as a linked database (102). Selected portions of the table contents of the source database, i.e., portions that are not the complete database, are synchronized with the respective portions of the table contents of the target database. Only the portions of tables and data stored in the selected tables need to be stored in the target database on which queries can be executed.

[0048] Selected queries against the database management system, including the source database, such as primarily OLAP queries, are transferred to the database management system containing the target database for processing. This can be understood as "offloading," for example. In this way, the source database is freed from the burden of the OLAP queries.

[0049] This method 100 then includes reading entries in the recovery log files related to the source database and applying the read entries to the target database to synchronize a portion of the contents of a selected table in the target database with a portion of the contents of a selected table in the source database (104). For this purpose, the database management portion of the target database system may be used.

[0050] This ensures that changes made by IUD (Insert, Update, Delete) transactions are applied only to the in-memory representation of the data, where those changes can be immediately accessed by database queries offloaded to the accelerator, regardless of whether they have already been stored in persistent media. This allows transactions to continue without additional delays or OLAP overhead.

[0051] Figure 2 shows a block diagram of a linked database embodiment 200. The primary or source database 202 receives OLTP queries 210 and OLAP queries 214. Queries identified as OLAP queries 214 are migrated or offloaded 222 to a secondary or target database 206. The source database 202 contains several tables 204 and associated storage data. The target database 206 also contains tables in its database table 208 that represent at least a subset of the database tables 204 of the source database 202, and at least a subset of their data.

[0052] After the OLAP operation is performed by the target database 206, the data is returned 224, and the OLAP output 220 is returned to the requesting program or process. The OLTP query 210 is executed directly in the source database 202 and returned to the requesting program or process as OLTP output 212. Therefore, neither the OLTP nor the source database 202 is slowed down by any resource-intensive OLAP query and can operate at its own peak performance.

[0053] Because the data organization in the target database 206 may differ, for example, being column-oriented instead of row-oriented in the source or OLTP database 202, the target database may return OLAP results 224 considerably faster than the source database 202.

[0054] Figure 3 shows a block diagram of Embodiment 300 illustrating how the target database can be synchronized by the concepts proposed herein. The source database management system 302 controls the operation of the source database 202 and its associated tables 204 (compare with Figure 2). The same applies to the target database management system 308 for the target database 206 and associated tables 208.

[0055] The source database management system 302 also maintains a recovery log file 306 for the source database 202. A log reader or log file reader 314 that reads the recovery log file 306 provides this data to the apply unit 316, which then applies the changes made to the source database (i.e., insertions, updates, and deletions) to a selected set of selected tables and data in the target database 206. The selected set of selected tables and data may be a subset of the relevant tables and data in the source database 202, as predefined. The apply unit 316 can optimize the application of changes to the target database 206 depending on the OLAP queries being executed. A log buffer 318 may be useful for this purpose.

[0056] For performance reasons, a bulk load operation 312 may be performed from source database 202 to target database 206 in order to initialize the target database 206.

[0057] Figure 4 shows a block diagram of an embodiment of linked database system 400. This linked database system enables crash recovery to the linked database of the linked database system. The linked database includes a source database system 406 and an associated target database system 408. Thereafter, selected portions of the table contents of the source database are synchronized with the respective portions of the table contents of the target database. In addition, selected queries against a database management system (not shown) including the source database system 406 are transferred to a database management system (not shown) including the target database for processing.

[0058] The linked database system 400 includes a processor 402 and a memory 404 communicatively coupled to the processor, the memory 404 storing a program code portion, which, when executed, allows the processor 402 to read entries in a recovery log file related to the source database by, for example, a log reader 410, and to apply the read entries to the target database by, for example, an apply unit 412, thereby enabling a synchronization unit to synchronize a portion of the contents of a selected table in the target database with a portion of the contents of a selected table in the source database.

[0059] Furthermore, all modules and units of the linked database system may be interconnected in a one-to-one manner to exchange signals, data, or both. Alternatively, modules and units, particularly the processor 402, memory 404, source database system 406, target database system 408, log reader 410, and application unit 412, may also be interconnected by the linked database system's internal bus system 414.

[0060] Embodiments of the present invention may be implemented with substantially any type of computer, regardless of whether the platform is suitable for storing or executing program code or both. Figure 5 shows, as an example, a computer system 500 suitable for executing program code according to the proposed method.

[0061] Computer System 500 is merely an example of a suitable computer system, and whether or not Computer System 500 is capable of implementing or performing any or both of the functions described above, it is not intended to imply any limitation on the scope of use or functionality of the embodiments of the present invention described herein. Computer System 500 has components that operate with a number of other general-purpose or specific-purpose computer system environments or configurations. Examples of well-known computer systems, environments, or configurations, or combinations thereof, that may be suitable for use with Computer System / Server 500 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 that include any of the above systems or devices. Computer System / Server 500 may also be described in the general context of computer system executable instructions, such as program modules, that are executed by Computer System 500. Generally, a program module may include routines, programs, objects, components, logic, and data structures that perform a specific task or implement a specific abstract data type. The computer system / server 500 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may reside in both local and remote computer system storage media, including memory storage devices.

[0062] As shown in the drawings, the computer system / server 500 is shown in the form of a general-purpose computer device. The components of the computer system / server 500 may include, but are not limited to, one or more processors or processing units 502, system memory 504, and a bus 506 that connects various system components, including the system memory 504, to the processor 502. The bus 506 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 the various bus architectures. Examples, though not an exhaustive list, of such architectures include the Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. The computer system / server 500 typically contains various computer system-readable media. These media may be any available media accessible by the computer system / server 500, and may include both volatile and non-volatile media, and removable and non-removable media.

[0063] System memory 504 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 508 or cache memory 510 or both. The computer system / server 500 may further include other removable / non-removable volatile / non-volatile computer system storage media. For example, a storage system 512 may be provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown, and commonly referred to as a “hard drive”). A magnetic disk drive may be provided for reading from and writing to a removable non-volatile magnetic disk (e.g., a “flexible disk”), and an optical disk drive may be provided for reading from or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such cases, each may be connected to the bus 506 by one or more data medium interfaces. As will be further shown and described below, the memory 504 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0064] For example, but not limited to, a program / utility having a set (at least one) of program modules 516, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory 504. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a network-forming environment. Program modules 516 generally perform functions or methods, or both, of the embodiments of the present invention described herein.

[0065] The computer system / server 500 may also communicate with one or more external devices 518, such as a keyboard, pointing device, or display 520; one or more devices that enable a user to interact with the computer system / server 500; or any device that enables the computer system / server 500 to communicate with one or more other computer devices (e.g., a network card, modem); or a combination thereof. Such communication may occur via an input / output (I / O) interface 514. Furthermore, the computer system / server 500 may communicate with one or more networks via a network adapter 522, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof. As shown, the network adapter 522 may communicate with other components of the computer system / server 500 via a bus 506. It should be understood that other hardware and / or software components, or both, may be used with the computer system / server 500, although 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 archival storage systems.

[0066] In addition, a linked database system 400 having crash recovery for linked databases may be attached to the bus system 506.

[0067] The descriptions of various embodiments of the present invention are provided for illustrative purposes only and are not intended to be exhaustive or restrictive to the embodiments disclosed. Many modifications and changes will become apparent to those skilled in the art without departing from the scope of the embodiments described. The terminology used herein has been selected to best describe the principles of the embodiments, their practical applications, or technical improvements to the art available on the market, or to enable those else skilled in the art to understand the embodiments disclosed herein.

[0068] The present invention may be embodied as a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or a combination of mediums) having computer-readable program instructions for causing a processor to perform an aspect of the present invention.

[0069] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for propagation. Examples of computer-readable media may include semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random-access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W), DVD, and Blu-ray(R) discs.

[0070] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may be, but is 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 preferred combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, flexible disks, mechanically coded devices such as punch cards or grooved structures with recorded instructions, and any preferred combination thereof. Computer-readable storage media as used herein should not be interpreted as transient signals in themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0071] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or they may be downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers those computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0072] The computer-readable program instructions for performing the 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 source code or object code written in any combination of one or more programming languages, the programming languages ​​including object-oriented programming languages ​​such as Smalltalk or C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may all run on the user's computer, or partially run on the user's computer as a standalone software package, or partially run on the user's computer and partially on a remote computer, or all run on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or a connection to an external computer may be made (for example, via the Internet using an Internet service provider). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by using state information of computer-readable program instructions to personalize the electronic circuit to perform aspects of the present invention.

[0073] In this specification, aspects of the present invention are described with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0074] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a specific-purpose computer, or other programmable data processing device for generating a machine, thereby creating a means for instructions executed through the processor of that computer or other programmable data processing device to implement functions / operations specified in one or more blocks of a flowchart or block diagram, or both. These computer-readable program instructions may also be stored in a computer-readable storage medium capable of instructing a computer, programmable data processing device, or other device, or a combination thereof, to function in a particular manner, thereby including a product in which the computer-readable storage medium storing the instructions contains instructions that implement modes of functions / operations specified in one or more blocks of a flowchart or block diagram, or both.

[0075] Computer-readable program instructions may also be loaded into a computer, another programmable data processing device, or another device, causing the computer, the other programmable device, or the other device to perform a series of operational steps to generate a process implemented in the computer, the other programmable device, or the other device, thereby enabling the instructions executed in that computer, the other programmable device, or the other device to implement functions / operations specified in one or more blocks of a flowchart or block diagram, or both.

[0076] The flowcharts or block diagrams or both in the drawings 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 regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, which contains one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, the functions shown within a block may occur in a different order than that shown in the drawings. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or, depending on the functions involved, these blocks may sometimes be executed in reverse order. In addition, it will be noted that each block in the block diagram or flowchart diagram or both, and any combination of blocks in the block diagram or flowchart diagram or both, may be implemented by a purpose-specific hardware-based system that performs a specified function or operation, or executes a particular combination of purpose-specific hardware and computer instructions.

[0077] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the invention. The singular forms “a,” “an,” and “the” used herein are intended to include the plural form unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” or “comprising” as used in this specification identify the presence of a described feature, integer, step, operation, element, or component, or combination thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combination thereof.

[0078] All means or step-plus-functional elements in the following claims are intended to include any structures, materials, or actions to perform their function in combination with other specifically claimed elements. While the description of the invention is provided for illustrative and explanatory purposes, it is not intended to be exhaustive or limiting to the disclosed form of the invention. Many modifications and changes will become apparent to those skilled in the art without departing from the scope of the invention. The embodiments have been selected and described to best illustrate the principles and practical applications of the invention and to enable understanding of the invention in various embodiments with various modifications suitable for specific uses anticipated by others skilled in the art.

[0079] The concept of the present invention as proposed herein may be summarized in the following items.

[0080] 1. A computer implementation method for crash recovery against a linked database, wherein the linked database includes a source database and an associated target database, and selected portions of the table contents of the source database are synchronized with the respective portions of the table contents of the target database. Selected queries against a database management system containing the source database are transferred to a database management system containing the target database for processing, and this method is used. - This includes reading entries from recovery log files related to the source database and applying the read entries to the target database, thereby synchronizing a portion of the contents of selected tables in the target database with a portion of the contents of selected tables in the source database.

[0081] 2. A method according to item 1, wherein the source database is optimized for transactions.

[0082] 3. The method according to item 2, wherein the source database is a row-oriented relational database.

[0083] 4. A method based on any of the preceding items, wherein the target database is optimized for the analysis operation.

[0084] 5. The method according to item 4, wherein the target database is a column-oriented database.

[0085] 6. A method according to item 4 or 5, wherein the target database is an in-memory database.

[0086] 7. A method according to any of the preceding items, - This includes delaying queries against the target database until recovery is complete in the event of a target database crash.

[0087] 8. A method according to item 7, wherein the recovery of the target database is performed by bulk loading data from the source database.

[0088] 9. A method according to item 7 or 8, wherein queries targeting the target database are executed in the source database during the recovery of the target database.

[0089] 10. A method according to any of the preceding items, - This also includes initializing the target database through a direct bulk load process of data from the source database to the target database.

[0090] 11. A method according to any of the preceding items, wherein the metadata defining the selected table is part of the recovery log file.

[0091] 12. A method according to any of the preceding items, wherein the target database management system does not include recovery logs.

[0092] 13. A linked database system having crash recovery for linked databases, wherein the linked database includes a source database and an associated target database, selected portions of the table contents of the source database are synchronized with the respective portions of the table contents of the target database, selected queries against a database management system including the source database are transferred to a database management system including the target database for processing, and this linked database system, - It includes a processor and memory communicatively coupled to the processor, the memory storing the program code portion, and when this program code portion is executed, the processor... - This allows you to read entries from recovery log files related to the source database and apply those entries to the target database, thereby synchronizing a portion of the contents of a selected table in the target database with a portion of the contents of a selected table in the source database.

[0093] 14. A linked database system according to item 13, wherein the source database is optimized for transactions.

[0094] 15. A linked database system according to item 14, wherein the source database is a row-oriented relational DBMS.

[0095] 16. A linked database system according to any of items 13-15, wherein the target database is optimized for analytical operations.

[0096] 17. A linked database system according to item 16, wherein the target database is a column-oriented database.

[0097] 18. A linked database system according to item 16 or 17, wherein the target database is an in-memory database.

[0098] 19. A linked database system according to any of items 13-18, in which, in addition, when a portion of the program code stored in memory is executed, the processor, - In the event of a target database crash, this feature allows queries against the target database to be delayed until the target database has recovered.

[0099] 20. A linked database system as defined in item 19, where the recovery of the target database is a bulk load of data from the source database.

[0100] 21. A linked database system according to item 19 or 20, in which, in addition, when a portion of the program code stored in memory is executed, the processor, - This feature allows queries targeting a target database to be executed in the source database while the target database is in recovery mode.

[0101] 22. A linked database system according to item 13 or 21, in which, in addition, when a portion of the program code stored in memory is executed, the processor, - This allows the target database to be initialized by a direct bulk load process of data from the source database to the target database.

[0102] 23. A linked database system according to item 13 or 22, in which the metadata defining the selected tables is part of the recovery log file.

[0103] 24. A linked database system according to item 13 or 23, wherein the target database management system does not include recovery logs.

[0104] 25. A computer program product for crash recovery against linked databases, wherein the linked database includes a source database and an associated target database, selected portions of the table contents of the source database are synchronized with the respective portions of the table contents of the target database, and selected queries against a database management system including the source database are transferred to a database management system including the target database for processing. The computer program product includes a computer-readable storage medium having program instructions to be implemented, and the program instructions are executable by one or more computer systems or controllers, so that the one or more computer systems - This process involves reading entries from recovery log files related to the source database and applying the read entries to the target database, thereby synchronizing the contents of selected tables in the target database with the contents of selected tables in the source database.

Claims

1. A computer implementation method for crash recovery against a linked database, wherein the linked database comprises a source database and an associated target database, a selected portion of the contents of a table in the source database is synchronized with the respective portions of the contents of the table in the target database, and a selected query to a database management system including the source database is transferred to the database management system including the target database for processing. In the event of a crash of the target database, queries against the target database will be delayed until the recovery of the target database is complete. During the recovery of the target database, a query targeting the target database is executed in the source database. Reading entries in the recovery log files related to the source database, and applying the read entries to the target database, thereby synchronizing the portion of the contents of the selected table in the target database with the portion of the contents of the selected table in the source database. Methods that include...

2. The method according to claim 1, wherein the source database is optimized for transaction processing.

3. The method according to claim 2, wherein the source database is a row-oriented relational database.

4. The method according to claim 1, wherein the target database is optimized for analysis operations.

5. The method according to claim 4, wherein the target database is a column-oriented database.

6. The method according to claim 4, wherein the target database is an in-memory database.

7. The method according to claim 1, wherein the recovery of the target database is performed by a bulk load of data from the source database.

8. The method according to claim 1, further comprising initializing the target database by a direct bulk load process of data from the source database to the target database.

9. The method according to claim 1, wherein the metadata defining the selected table is part of the recovery log file.

10. The method according to claim 1, wherein the target database management system does not include a recovery log.

11. A linked database system, wherein the linked database includes a source database and an associated target database, wherein selected portions of the contents of tables in the source database are synchronized with the respective portions of the contents of tables in the target database, and selected queries to a database management system including the source database are transferred to the database management system including the target database for processing. The processor includes a memory that is communicably coupled to the processor, and the processor is In the event of a crash of the target database, queries against the target database will be delayed until the recovery of the target database is complete. When the target database is in recovery mode, the source database executes a query targeting the target database, and The system is configured to read entries in the recovery log files related to the source database and to apply the read entries to the target database, thereby synchronizing the portion of the contents of a selected table in the target database with the portion of the contents of the selected table in the source database. Linked database system.

12. The linked database system according to claim 11, wherein the source database is optimized for transaction processing.

13. The linked database system according to claim 12, wherein the source database is a row-oriented relational database.

14. The linked database system according to claim 11, wherein the target database is optimized for analytical operations.

15. The linked database system according to claim 14, wherein the target database is a column-oriented database.

16. The linked database system according to claim 14, wherein the target database is an in-memory database.

17. The linked database system according to claim 11, wherein the recovery of the target database is performed by a bulk load of data from the source database.

18. The aforementioned processor, Initializing the target database by a direct bulk load process of data from the source database to the target database. The linked database system according to claim 11, configured to further perform the following:

19. The linked database system according to claim 11, wherein the metadata defining the selected table is part of the recovery log file.

20. The linked database system according to claim 11, wherein the target database management system does not include a recovery log.

21. A computer program for crash recovery against a linked database, the computer program causing a processor to perform the method according to any one of claims 1 to 10.

Images