Diskless active data protection as cache

Abstract

Techniques are described herein for integrating a front end database cache ("IIDC") that provides a cache for in-memory, consistent, and automatic management of primary database data. The IIDC includes a database server instance that (a) caches data blocks from a source database managed by a second database server instance, and (b) performs recovery on the cached data using a redo record for the database data. The IIDC instance implements relational algebra and is configured to run queries of any complexity on cached database data. Any cache miss results in the IIDC instance obtaining the desired chunk (s) from a second database server instance that manages the source database that provides the IIDC instance with the latest version of the requested data chunk (s) available to the second instance. Because the redo records are used to continuously update the data blocks in the IIDC cache, the IIDC ensures the consistency of query results.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is related to the following applications, the entire contents of each of which are incorporated herein by reference as if fully set forth herein:

[0003] U.S. Application No. 14 / 072,739, filed on November 5, 2013, now U.S. Patent No. 9,146,934, issued on September 29, 2015, entitled “Reduced Disk Space Standby”; and

[0004] U.S. Application No. 11 / 818,975, filed on January 29, 2007, now U.S. Patent No. 7,734,580, issued on June 8, 2010, entitled “Readable Physical Storage Replica And Standby Database System”. Technical Field

[0005] The present invention relates to improving database scalability and, more particularly, to providing an automatically managed cache in front of a primary database. Background Art

[0006] Modern web applications often require large-scale database scalability. In order to provide lower access latency, many applications place a cache in front of the main database. Such caches are generally implemented on the client side and are therefore not maintained by the database management system that manages the main database. Current popular products (such as Redis and Memcached) allow applications to query the main database and store the query results (with expiration times) in a key-value store in the client-side memory. Subsequent queries can be satisfied based on the contents of the client-side key-value store, and as long as the data is not expired, the query will return the cached data.

[0007] Generally speaking, database applications need to implement relational algebra in order to query data in the client-side cache, while client-side cache systems generally do not implement relational algebra. Database applications generally also need to manage data residing in the client-side cache, such as via an expiration time associated with the cached data. However, the use of an expiration time does not guarantee that the data cached in the primary database has not changed after the cached data is obtained from the primary database. Therefore, client-side cache management causes stale data to be included in the cache and used by the database application. In other words, the client-side cache system does not guarantee the consistency of query results. For example, a database application performs a join on two tables stored in the client-side cache. If the two tables are not brought into the client-side cache at the exact same time, the join result cannot guarantee internal consistency. In addition, a query on the client-side cache system may retrieve data that is older than the data retrieved by the previous query on the client-side cache system. For example, a first table is stored in the client-side cache at the first time and a second table is stored in the client-side cache at a later time. Before updating either table, the database application queries the second table and then queries the first table, in which case the second (more recent) query may return older data than the first query.

[0008] Some stale data may be acceptable for database application functions. For example, when a user is just browsing a flight reservation system, the system can show stale flight data, such as data from one second ago. However, when the user requests to book a flight, this will modify the database data, and the reservation function requires the latest data, because modifying stale data may result in violation of ACID consistency properties and corrupted data.

[0009] Another way to improve the scalability of a master database is to create one or more physical or logical replicas of the master database. Each replica of the master database stores at least a portion of the master database data in a persistent storage device, maintaining its consistency by applying redo information from the master database. Database replicas implement relational algebra and are able to process queries of any complexity on the replicated portion of the database data. However, database replicas require a large amount of resources that are not required by client-side caching systems, such as persistent storage space for the replicated data and processing power to apply redo information to the stored data.

[0010] Yet another approach to improving the scalability of a primary database is described in the "Reduced Disk Space Standby" patent referenced above. Specifically, a diskless database server instance is configured to pull information directly from a persistently stored copy of the primary database data without involving a database server instance (a "standby" instance) that maintains the replicated data. Because the diskless instance directly accesses the replicated data stored in persistent storage, the diskless instance cannot access the latest version of the data blocks residing in the buffer cache of the standby instance. The standby instance can be configured to notify the diskless instance which data blocks in the replicated database data have changed since a given timestamp. The diskless instance generally responds to these messages by invalidating any data blocks in its cache that correspond to the updated data blocks. Therefore, after the diskless instance receives information that a data block in the replicated database data has been updated, any cached version of the block must be re-acquired from the replicated database data to satisfy any query that uses the data block, which is a slow and expensive process that increases the cost of running queries by the diskless instance.

[0011] The techniques described herein are configured to address the database scalability issues identified above.

[0012] The methods described in this section are methods that could be employed, but are not necessarily methods that have been previously conceived or employed. Therefore, unless otherwise indicated, it should not be assumed that any of the methods described in this section are considered prior art simply because they are included in this section. In addition, it should not be considered that any of the methods described in this section are well-understood, routine, or conventional simply because they are included in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In the figure:

[0014] Figure 1 An example network configuration including a database management system is depicted.

[0015] Figure 2 Depicted is an example flow chart for applying redo records to cached data blocks and obtaining data blocks into the cache to satisfy queries.

[0016] Figure 3A-3C Depicts data managed by a database management system, including main database data and data cached by an integrated front-end database caching system.

[0017] Figure 4A-4B Describes a listener-based architecture for a database management system.

[0018] Figure 5is a block diagram illustrating a computer system upon which various embodiments may be implemented.

[0019] Figure 6 A block diagram of a basic software system that can be used to control the operation of a computer system. DETAILED DESCRIPTION

[0020] In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the technology described herein. However, it is apparent that the technology described herein can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the technology described herein.

[0021] 1. General Overview

[0022] This article describes a technology for an integrated front-end database cache ("IIDC") that provides an in-memory, consistent, and automatically managed cache for primary database data. The IIDC includes a database server instance that (a) caches data blocks from a source database managed by a second database server instance, and (b) performs recovery on the cached data using redo records for the database data. The IIDC instance implements relational algebra and is configured to run queries of any complexity on the cached database data. Any cache miss causes the IIDC instance to obtain the required (one or more) blocks from the second database server instance that manages the source database, which can be a primary database server instance or a standby database server instance that manages a physical copy of the primary database. This second database server instance provides the IIDC instance with the latest version of the (one or more) requested data blocks available to the second instance.

[0023] The IIDC instance receives and applies redo records indicating changes made to the primary database data to the database data cached in the IIDC buffer cache. Therefore, the cached blocks retain their values ​​over time and do not need to be re-acquired to obtain the latest version of the blocks, which increases the value of the cached database data and reduces the resources required to maintain the cached data. Because redo records are used to continuously update the data blocks in the IIDC cache, the IIDC can ensure the consistency of query results without the intervention of any client-side logic. Specifically, queries executed by the IIDC always return consistent data, regardless of the complexity of the query, because the IIDC is managed by the database server instance. In addition, because the IIDC maintains a query logical timestamp that indicates the logical timestamp of the redo fully applied in the IIDC buffer cache, queries executed later will never return data older than the results returned for queries executed earlier. It is guaranteed that queries executed later return the latest query results as of the time when the later query is executed.

[0024] Furthermore, because the IIDC does not maintain a copy of the source database data, the IIDC can be established without requiring persistent storage resources sufficient to store the database data, as a physical or logical copy of the source database would require.

[0025] 2. Integrated front-end database cache

[0026] Figure 1 An example network configuration 100 is depicted that includes a database management system (DBMS) 110 communicatively connected to a client device 180 via a network 160. The network 160 may be implemented in any manner to facilitate communications between entities.

[0027] The DBMS 110 includes a master database server instance ("master instance") 122 running on a computing device 120. The master instance 122 is a collection of memory and processing that interacts with and manages a master database 132 and a buffer cache 128 within a persistent storage 130, which is implemented at least in part in a byte-addressable memory (such as DRAM or PMEM) of the computing device 120. The DBMS 110 also includes an IIDC database server instance ("IIDC instance") 152 running on a computing device 150. The IIDC instance 152 is a collection of memory and processing that maintains cached database data within an IIDC buffer cache 158, which is implemented at least in part in a byte-addressable memory of the computing device 150. The IIDC instance 152 uses the cached data to satisfy queries on the database data, as described in further detail below. The computing device 120 and the computing device 150 may be located at the same physical location or may be located at different physical locations. This article uses an example network configuration 100 to demonstrate the technology, but the IIDC technology described in this article is not limited to Figure 1 For example, the master database 132 of the DBMS 110 can be maintained using multiple database server instances, such as using Oracle Real Application Clusters (RAC). In this case, the master database server instance 122 will be one of the multiple master database server instances in the master database cluster.

[0028] Unlike instances that maintain logical or physical copies, IIDC instances 152 do not maintain any portion of the source database data (e.g., from master database 132) in persistent storage. However, IIDC instances 152 may extend cache information from the byte-addressable memory of IIDC buffer cache 158 to the flash cache portion of IIDC buffer cache 158 implemented in persistent storage of computing device 150 ( Figure 1 In addition, the IIDC instance 152 may store certain files (such as temporary files for sorting, configuration files, trace files, etc.) in a persistent storage device of the computing device 150.

[0029] The IIDC instance 152 satisfies the query using only data in the IIDC buffer cache 158. If the required database block is not in the IIDC buffer cache 158, the IIDC instance 152 obtains the block from the database server instance that manages the source database. Once the block is in the IIDC buffer cache 158, it is automatically updated with any applicable redo information from the source database.

[0030] Figure 2 An example flow chart 200 for applying redo records to cached data blocks and acquiring the data blocks into the cache to satisfy a query is depicted. Specifically, at step 202, a database server instance receives a plurality of redo records for changes made to a primary database. At step 204, the database server instance automatically applies the plurality of redo records to change at least a portion of the primary database data stored in a buffer cache to generate first updated database data in the buffer cache. The database server instance executes a query on the first updated database data, including steps 206-210. Specifically, at step 206, it is detected that the buffer cache does not store one or more data blocks of the primary database required for the query. At step 208, in response to detecting that the buffer cache does not store the one or more data blocks required for the query, one or more data blocks are acquired from a second database server instance into the buffer cache to generate second updated database data in the buffer cache. Moreover, at step 210, query results are generated using the second updated database data stored in the buffer cache. The techniques depicted in flow chart 200 are described in further detail below.

[0031] The ability of the IIDC instance 152 to reliably satisfy queries is based on the IIDC instance's access to the source database data. For example, in the case where the source database of the IIDC instance 152 is the primary database 132, if the network 160 is severed or if the primary database instance 122 fails, then queries issued to the IIDC instance 152 will fail if the required blocks are not completely located in the IIDC buffer cache 158. Nevertheless, the IIDC instance 152 itself will remain operational in the event of a network or source database outage. When the primary database instance 122 is restored, the IIDC instance 152 is configured to reestablish its state and continue to use data from the primary database 132 to serve queries.

[0032] 2.1.IIDC satisfies the query

[0033] The database application 182 running on the client device 180 can issue queries to the master database 132, which are satisfied by the IIDC instance 152. For example, the database application 182 establishes a database session with the DBMS 110 to execute database commands from the application 182. The database session includes a specific connection through which the client can issue database requests. The connection configuration is further described in detail below. The connection used by the database application 182 can be established directly with the target database server instance, or can be established based on the database server instance being part of a target instance cluster (such as a master database cluster that maintains the master database 132). The database application 182 can indicate that the IIDC instance 152 can execute a given query by including a query hint (such as "cache_ok") or by issuing a query via a connection with an attribute indicating that the IIDC instance 152 can execute the query (such as a "read_only" attribute indicating that all queries issued via the connection are read-only queries).

[0034] For example, application 182 issues the following query 1 via a connection to IIDC instance 152 indicating that the query can be executed by IIDC:

[0035] Query 1

[0036] SELECT Name

[0037] FROM EMP

[0038] WHERE Salary>100,000

[0039] IIDC instance 152 uses data in IIDC buffer cache 158 to satisfy queries. For illustration, Figure 3A A state 300 of data in DBMS 110 is depicted, wherein primary database 132 includes dictionary 310 stored in data blocks 312A, 314A, and 316A, and also includes table "EMP" 320 stored in data blocks 322A, 324A, and 326A. A data block is a unit of space allocation within a persistent storage device or byte-addressable memory. A data block can be any size, such as 2 kilobytes (KB), and can be organized into higher-level space allocation units, such as extents (e.g., groups of data blocks) and segments (e.g., groups of extents). According to various embodiments, segments are used by DBMS 110 to store tables or table partitions. (For additional information on space allocation, see "Data Blocks, Extents, and Segments" in Oracle Database Online Documentation 10g Release 2 (10.2), the entire contents of which are incorporated herein by reference as if fully set forth herein.)

[0040] continue Figure 3A , EMP 320 is stored on a segment in persistent storage 130 that includes data blocks 322A, 324A, and 326A, while dictionary 310 is stored on a different segment in persistent storage 130 that includes data blocks 312A, 314A, and 316A. IIDC instance 152 receives the above example Query 1 and resolves the reference to “EMP” using dictionary data block copies 312A, 314A, and / or 316A in IIDC buffer cache 158 to identify the block (e.g., block 322A) needed to satisfy Query 1. In the example data state 300, IIDC buffer cache 158 includes block copy 322A, and IIDC instance 152 uses the cached block copy 322A to satisfy Query 1.

[0041] Queries to the IIDC instance 152 return committed data as current as the redo apply lag. Because it is implemented by a database server instance, the IIDC instance 152 supports any query supported by the DBMS 110. In general, queries to the IIDC instance 152 will always succeed as long as (1) the IIDC instance has not crashed and (2) the IIDC redo apply lag is within the maximum apply threshold (e.g., if the user has set the maximum threshold).

[0042] Cache Miss

[0043] When a query satisfied by an IIDC instance 152 requires a "cache miss" for a data block that is not in the IIDC buffer cache 158, the IIDC instance 152 obtains the required data block from a source database, such as from a master instance 122 that manages a master database 132. According to various embodiments, the source database for the IIDC instance 152 is instead a physical database of the master database 132, and the IIDC instance 152 obtains the required data block from a database server instance that manages a replica of the database.

[0044] For example, application 182 issues the following query 2 via the example connection described above:

[0045] SELECT *

[0046] FROM EMP

[0047] IIDC instance 152 receives example query 2 and resolves references to “EMP” using dictionary data block copies 312A, 314A, and / or 316A in IIDC buffer cache 158 to identify blocks (e.g., data blocks 322A, 324A, and 326A) needed to satisfy query 2. In example data state 300, IIDC buffer cache 158 includes only block copy 322A for table “EMP.” Thus, in response to detecting this cache miss, IIDC instance 152 requests data blocks 324A and 326A from master instance 122. Master instance 122 responds to the request by sending the latest versions of data blocks 324A and 326A to IIDC instance 152 via network 160. Master instance 122 sends the latest versions of data blocks that either reside in buffer cache 128 or reside in persistent storage 130. Figure 3B An updated data state 350 is depicted, wherein the IIDC buffer cache 158 stores received data block copies 324A and 326A. Once the required data block is in the IIDC buffer cache 158, the IIDC instance 152 satisfies Query 2 using the cached block copies 322A, 324A, and 326A.

[0048] According to various embodiments, the IIDC instance 152 authenticates with the primary instance 122 and requests the required data block from the primary instance. Thus, according to various embodiments, the IIDC instance 152 utilizes the block transfer protocol with a proxy task process that maintains a persistent connection between the IIDC instance 152 and the primary instance 122. In addition, if the source database is a physical copy of the primary database 132, the IIDC instance 152 authenticates with the standby database instance that manages the copy and requests the required block from the standby database instance. The standby database instance responds to the request with the latest version of the requested data block, whether the latest version is from the buffer cache of the standby database instance or from the persistent storage device storing the physical copy of the primary database 132.

[0049] Many times, database applications repeatedly use the same data blocks, which results in a relatively low frequency of cache misses when the IIDC is in a stable state. Using an appropriate replacement strategy for the IIDC buffer cache 158 can further reduce the frequency of cache misses.

[0050] 2.2.1. Cluster Cache Misses for Primary Database Server Instances

[0051] According to various embodiments, when a cluster of master database server instances is used to maintain the master database 132, the IIDC instance 152 may choose to retrieve data blocks from a particular master database server instance of the cluster, for example, for efficiency reasons. For example, when a particular master database server instance of the cluster is associated with a particular database object, any blocks belonging to the particular database object that are cached by the master database cluster are located in the buffer cache of the particular instance. Database affinity can be any of a number of levels, including per file, per object, per pluggable database, etc. In this document, references to data blocks associated with a particular database server instance refer to any level of database affinity involving these data blocks.

[0052] According to an embodiment, the IIDC instance 152 tracks the association mapping information for the instances of the primary database cluster and uses the association mapping information to determine which primary server instance to obtain the data block from. Using the association mapping information to select the database server instance from which to retrieve the data block allows the requested data block to be retrieved from the buffer cache of the instance (when possible), which is much faster than retrieving the data block from a persistent storage device or from the buffer cache of another database server instance of the primary cluster.

[0053] According to various embodiments, the IIDC instance 152 makes a best effort to maintain the association mapping information. For example, in the absence of association mapping information for a particular database object, the IIDC instance 152 attempts to obtain the required data block from any database server instance of the primary database cluster. In response, the database server instance returns association information for the target database object, either with or without the requested data block. If the association information is returned without the requested data block, the IIDC instance 152 then requests the required block from the database server instance indicated in the received association information. The IIDC instance 152 also updates the association mapping information to include the received association mapping.

[0054] According to various embodiments, IIDC instance 152 includes in buffer cache 158 data blocks storing association mapping information maintained within primary database 132. When any association mapping is changed by DBMS 110, one or more redo records are generated to reflect the change, and IIDC instance 152 applies these one or more redo records to the cached data, thereby maintaining the association information.

[0055] 2.3. Applying Redo Records

[0056] Once a block is cached in the IIDC buffer cache 158, the IIDC instance 152 automatically updates the block by applying redo records that record the changes made to the block in the primary database 132. Thus, the cached data remains up to date without the IIDC instance 152 having to periodically obtain updated data blocks from the source database, and transactionally consistent data is always returned for each query to the IIDC instance 152. In addition, the redo stream may include other information that is not specific to a particular database block and that the IIDC instance 152 applies to the data in the IIDC buffer cache 158, such as special redo markers. For example, there are redo markers that teach the standby database system how to invalidate certain metadata cache entries (e.g., library cache entries). According to various embodiments, the IIDC instance 152 is configured to apply redo information that is not specific to data blocks to other types of database server instances in a similar manner.

[0057] For example, one or more redo records describing changes performed within the primary database 132 are generated and stored in a redo log 134 in the persistent storage 130. These redo records are sent to the IIDC instance 152 by one of the following: the primary instance 122, a listener service that captures the redo log 134, or another database server instance that has access to the redo records in the primary database 132 (such as an instance that maintains a physical copy of the primary database 132). When the IIDC instance 152 receives any redo records applicable to data blocks that are not in the IIDC buffer cache 158, the IIDC instance 152 discards these redo records. When a data block expires and is removed or replaced according to any kind of replacement strategy, no data for the block is stored in the persistent storage. The IIDC instance 152 is capable of processing queries that reflect the consistent state of the primary database 132 no later than the latest readable query time, which is calculated by the IIDC instance 152 based on the redo records that have been applied to the cached data blocks.

[0058] To illustrate, Figure 3CAn updated data state 360 ​​is depicted, in which data blocks 314 and 326 have been updated from version A to version B (i.e., as indicated by updated labels "314B" and "326B"). Redo log 134 includes redo record 362 recording changes made to block 314 and redo record 364 recording changes made to block 326. According to an embodiment, primary instance 122 sends redo records 362 and 364 to IIDC instance 152, which applies the changes recorded in these redo records to copies of blocks 314 and 326 in IIDC buffer cache 158 (as depicted by block copies 314B and 326B in IIDC buffer cache 158). In addition, it is possible for IIDC instance 152 to obtain updated versions of data blocks residing in IIDC buffer cache 158 prior to receiving redo records indicating one or more changes made to previously cached versions of the blocks. Given that the IIDC instance 152 returns committed results as of the query logic timestamp maintained by the instance, this scenario does not affect the correctness of the database query results returned by the IIDC instance 152. If the actual block content contains changes beyond the applicable query logic timestamp (e.g., the delta between block 326B and block 326A), then the necessary undo will be applied before returning the results of the database query.

[0059] 2.4. Preheating

[0060] For most workloads, when the IIDC buffer cache 158 is in a steady state full of data blocks, fetching blocks on demand and using a least recently used (LRU) buffer replacement policy results in efficient cache management. However, when the IIDC buffer cache 158 is spinning up, especially immediately after startup or when restarting after a crash event, reading blocks into the buffer cache one by one will take a long time to fill up the cache and result in many cache misses.

[0061] To reduce the number of cache misses when the IIDC instance 152 is first started, the instance pre-fetches blocks to speed up cache warming. According to various embodiments, during startup shortly after the IIDC buffer cache 158 is opened, a pre-warming mechanism is used to extend each single read of a data block (e.g., associated with a cache miss) to fetch additional data blocks, such as retrieving 1 megabyte (MB) of data, or retrieving data within the range boundaries of the fetched data blocks, etc. The pre-warming mechanism is particularly helpful for kernel common library (KGL) object population during startup, and continues to fill the IIDC buffer cache 158 for any workload until the buffer cache is full.

[0062] In addition, according to various embodiments, the IIDC instance 152 periodically records identification information (such as data block addresses and OBJDs, which will be described in further detail below) for blocks in the IIDC buffer cache 158 as snapshots in a metadata file on the local disk. When the IIDC instance 152 is next started, if the IIDC instance 152 is reconnected back to the same source database and / or associated with the same service (also described in further detail below), the IIDC instance 152 preheats the buffer cache by obtaining the blocks identified in the stored metadata file from the source database server instance.

[0063] 3. Using IIDC's sample database system configuration

[0064] Applications 182 can directly connect to IIDC instances 152, similar to how applications connect to standby database server instances. Applications 182 can also directly connect to services exported by all or a subset of IIDC instances within a DBMS. The following will further describe in detail the various ways to configure a database system using IIDC, including static configuration, unified configuration, and partitioned configuration.

[0065] 3.1. Static Configuration

[0066] According to the static configuration, the application 182 maintains two direct connections, one to the IIDC instance 152 and one to the master instance 122. Read-only queries that do not need to see the latest data are issued via the connection to the IIDC instance 152, while other queries are issued via the connection to the master instance 122. In such an embodiment, the application 182 is responsible for splitting the read and write traffic between the two physical connections.

[0067] 3.2. Unified Configuration

[0068] According to the unified configuration, the application 182 maintains a single logical connection with the DBMS, while the client driver internally maintains two physical connections for each logical connection with the DBMS: one to the master instance 122 and one to the IIDC instance 152. The application 182 uses code markings (such as setReadOnly(true) calls and setReadOnly(false) calls) to mark some sections of the code as "read-only", or more precisely, "read-only with hysteresis allowed". The client driver automatically sends SQL statements in the "read-only" code blocks to the IIDC instance 152 via the physical connection to the IIDC instance.

[0069] In a unified configuration, all IIDC instances in a DBMS support the same one or more IIDC services, where each service represents a pattern that identifies a specific data set in a source database. IIDC instances support services that can be configured using standard methods (such as DBMS_SERVICE for database instances). The use of services by IIDC instances allows client drivers (such as database connection drivers for database applications 182) to utilize IIDC without explicitly specifying an IIDC instance. Therefore, the database configuration can be adjusted without adjusting the database application client. Remote listeners connect client sessions to IIDC instances that support IIDC services, either randomly or based on load.

[0070] According to various embodiments, the services supported by the IIDC instance are different from those supported by the primary database itself. This is because queries to the IIDC do not see the latest data, but instead see committed data with redo application lag. The IIDC design recognizes this difference and configures the IIDC instance to have its own services.

[0071] To illustrate the unified configuration, Figure 4A A network configuration 400 is depicted that includes the database application 182 and a second database application 402 communicatively coupled to a listener service 420. The listener service 420 (named "l_sales") is configured to route database commands from the client database application to one of the following instances: the IIDC instance 152, the second IIDC instance 410, or the primary instance 122. Thus, each of the IIDC instance 152, the second IIDC instance 410, and the primary instance 122 indicates that l_sales is a remote listener for those instances.

[0072] As shown, both database applications 182 and 402 have established connections with DBMS 110, with a service_name attribute value of "sales". According to the unified configuration, master instance 122 is associated with a service named "sales", and both IIDC instances 152 and 410 are associated with the same service named "c_sales". Listener service 420 can access information (e.g., maintained by master instance 122) indicating that the c_sales service is the IIDC peer of the sales service.

[0073] According to various embodiments, the listener service 402 notifies the client applications 182 associated with the sales service and the database connectivity drivers of 402 that c_sales is the IIDC peer of the sales service. For example, the listener service 420 notifies the JDBC (Java Database Connectivity) driver of the database application 182 and the JDBC driver of the database application 402 that c_sales is the IIDC peer of the sales service. Based on this information, each JDBC driver opens two connections, one to the master instance 122 of the sales service and one to any IIDC instance that supports the c_sales service. To illustrate, the JDBC driver of the database application 182 establishes a connection with the master instance 122 and establishes a connection with the IIDC instance 152. Any SQL statements within the "read-only" code block are sent to the IIDC instance 152, and any other SQL statements are sent to the master instance 122 via the established connection.

[0074] According to various embodiments, in a unified configuration, client sessions are evenly distributed between IIDC instances by a listener service. In this configuration, all IIDC instances will cache more or less the same data set.

[0075] 3.3. Partition Configuration

[0076] According to the partitioned configuration, as with the unified configuration, the application 182 maintains a single logical connection with the DBMS and uses code tags to mark some sections of the code as "read-only". In addition, in the partitioned configuration, service association can be used to divide the work between different IIDC instances that cache data for the same source database. This can help solve the common situation where the main database instance is implemented using powerful computing resources, while the associated IIDC instances are implemented using less powerful resources. For such IIDC instances, it can be challenging to cache all the data used within the main database.

[0077] When a master database with multiple associated IIDC instances is associated with multiple services representing substantially different sets of database objects, different IIDC instances can be associated with different cache type services associated with different services of the master database to divide cache requirements between the IIDC instances. Thus, different workloads are directed to different IIDC instances using services so that different IIDC instances cache different data sets. With a partitioned configuration, the effective aggregate cache size of all IIDC instances can be much larger than a single IIDC instance. Thus, using multiple IIDC instances to cache data for a single source database, a partitioned configuration can cache much more data in memory than a unified configuration.

[0078] The set of database objects identified by different services may be different or may have one or more common database objects. Furthermore, multiple database instances may be associated with one or more of the same services, and a database instance may be associated with multiple services.

[0079] To illustrate the partition configuration, Figure 4B A second network configuration 450 is depicted in which the master instance 122 is associated with services hr and sales. The sales service identifies a first set of database objects within the master database 132, and the hr service identifies a second set of database objects within the master database 132. The IIDC instance 152 is associated with the service c_sales, and the IIDC instance 410 is associated with the service c_hr, where c_hr is the IIDC counterpart of the hr service.

[0080] Database application 182 establishes a connection with a service_name attribute of "sales", indicating that the application requires information from a database object identified by the sales service. Database application 402 establishes a connection with a service_name attribute of "hr", indicating that the application requires information from a database object identified by the hr service. According to the above processing, database application 182 establishes a connection with the master instance 122 (associated with sales) and establishes a connection with the IIDC instance 152 (associated with c_sales). Database application 402 establishes a connection with the master instance 122 (associated with hr) and establishes a connection with the IIDC instance 410 (associated with c_hr). Therefore, the resources of each of the IIDC instances are concentrated on a specific database object within the master database 132, which reduces the possibility of cache misses and improves the efficiency of the IIDC instance caching mechanism.

[0081] 4. Stale dictionary data in IIDC

[0082] The IIDC instance 152 uses dictionary data cached in the IIDC buffer cache 158 to resolve references to database objects in received SQL statements. The use of cached dictionary data may be problematic when a cluster of database server instances is used to maintain a master database 132 (an example target database for the IIDC instance 152) and the cached dictionary data is stale. For example, each database object in the master database 132 is associated with a data object number (OBJD), which is used to determine a lock identifier for the database object. The lock identifier may be required to find the latest version of a block within the master database 132. Using a stale OBJD to find a block in the master database 132 may result in identifying a stale version of the requested data block, such as when the entry corresponding to a particular object is associated with a particular instance of the master database cluster that maintains the master database 132 (i.e., all buffers for that object are in the cache of a particular instance if cached anywhere).

[0083] According to various embodiments, in order to identify data blocks that may be stale due to stale dictionary data, when the IIDC instance 152 retrieves data blocks from the source database using the cached dictionary data, the IIDC instance 152 marks the retrieved data blocks as "potentially current" (as opposed to a "current" data block that is known to be the latest version of the data block as new as the redo apply lag). For example, when the IIDC instance 152 makes a block retrieval request, the master instance 122 reads the block with the potentially stale OBJD sent from the IIDC instance 152 in response to the IIDC request. The retrieved block is the latest block identified by the potentially stale OBJD, but may not be the latest version of the data block maintained by the master instance 122. Marking the block as "potentially current" facilitates the IIDC instance 152 to further review whether the block should be marked as "current" or should be discarded and re-retrieved.

[0084] Regardless of whether the response to the IIDC request is a stale data block, the retrieved "potentially current" data block is used to respond to the query that caused the cache miss. This is acceptable because the OBJD used to retrieve the "potentially current" data block is identified for the target query and is therefore sufficient to satisfy the query. If a second SQL statement also references the retrieved data block, then the retrieved data block can be used to satisfy the second SQL statement if the second SQL statement also includes the OBJD used to retrieve the "potentially current" data block. If the second SQL statement includes a different OBJD for the data block, then the SQL statement is parsed using the updated dictionary data stored in the IIDC buffer cache 158. In this case, the "potentially current" data block is known to be stale and is discarded from the IIDC buffer cache 158; the IIDC instance 152 requests the latest version of the data block from the master instance 122 using the updated dictionary data in the IIDC buffer cache 158.

[0085] In order to determine whether a "potentially stale" data block is "current" or stale, an attempt is made to recover the data block using redo records. The application of redo records requires a specific version of the data block that existed at the time the record was changed (the "initial state" of the redo record). According to various embodiments, for a "potentially current" cached data block, the IIDC instance 152 performs a detailed comparison of the attributes of the "potentially current" data block and the initial state indicated in the redo record. If the cached block matches the initial state description in the redo record, then the redo record is applied to the cached data block and the block is marked as "current" instead of "potentially current". Any future redo records for the "current" data block can be applied without a detailed determination of whether the data block matches the initial state information stored by the redo record. However, if the "potentially current" data block does not match the initial state information in the redo record, or it is unclear whether the "potentially current" data block matches the initial state information in the redo record, then the dictionary data is refreshed by applying the redo record to the cached data block storing the dictionary data or by retrieving the cached data block storing the dictionary data from the primary database. The updated dictionary data is used to request the latest version of the data block to replace the “potentially current” data block in the IIDC buffer cache 158 .

[0086] 5. Database Overview

[0087] Embodiments of the present invention are used in the context of a database management system (DBMS). Accordingly, a description of an example DBMS is provided.

[0088] Generally speaking, a server such as a database server is a combination of integrated software components and an allocation of computing resources such as memory, nodes, and processes on the nodes for executing the integrated software components, where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of the server's clients. A database server controls and facilitates access to a specific database, processing client requests to access the database.

[0089] A database includes data and metadata stored on a persistent storage mechanism such as a set of hard disks. Such data and metadata may be logically stored in a database, for example, according to a relational and / or object-relational database structure.

[0090] A user interacts with the database server of a DBMS by submitting commands to the database server that cause the database server to perform operations on the data stored in the database. A user may be one or more applications running on a client computer that interacts with the database server. Multiple users may also be collectively referred to as users in this article.

[0091] A database command or query can be in the form of a database statement. In order for a database server to process a database statement, the database statement must conform to a database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including a proprietary form of SQL supported by a database server such as Oracle (e.g., Oracle Database 11g). SQL data definition language ("DDL") instructions are issued to a database server to create or configure database objects, such as tables, views, or complex types. Data manipulation language ("DML") instructions are issued to a DBMS to manage data stored in a database structure. For example, SELECT, INSERT, UPDATE, and DELETE are common examples of DML instructions in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in an object-relational database.

[0092] When a database system commits a transaction, it transitions from one transaction-consistent state to another transaction-consistent state. A transaction-consistent state is when the database files managed by the database system reflect all changes made by committed transactions, but do not reflect any changes made by uncommitted transactions.

[0093] A logical time is associated with each consistent state. The logical time for a subsequent consistent state is later than the logical time for the previous consistent state. An example of a logical time is a system change number (SCN), sometimes called a "system commit number." Each commit of a transaction is associated with an SCN. Whenever a transaction is committed and / or a commit record for a transaction is generated, a counter for the SCN is incremented. The transaction and its commit record are associated with a new counter value or SCN. Transactions recorded with redo records are associated with the SCN to which they correspond.

[0094] Embodiments of the present invention are further described herein in the context of SCNs. However, the present invention is not limited to logical times in the form of SCNs. In order to process queries consistent with the state of the primary database 132 at a particular SCN, the IIDC instance 152 must apply redo records associated with all previous SCNs to all data blocks stored in the IIDC buffer cache 158. According to various embodiments, when the IIDC instance 152 determines that records for all SCNs prior to a particular SCN have been applied, it advances the latest readable SCN (i.e., the latest readable query time, also referred to herein as the "query logical timestamp") to that particular SCN.

[0095] In general, data is stored in one or more data containers in a database, each container contains records, and the data within each record is organized into one or more fields. In a relational database system, data containers are generally referred to as tables, records are referred to as rows, and fields are referred to as columns. In an object-oriented database, data containers are generally referred to as object classes, records are referred to as objects, and fields are referred to as attributes. Other database architectures may use other terms. The system implementing the present invention is not limited to any particular type of data container or database architecture. However, for the purpose of explanation, the examples and terms used in this article should be examples and terms that are generally associated with relational databases or object-relational databases. Therefore, the terms "table", "row" and "column" used in this article should refer to data containers, records and fields, respectively.

[0096] A multi-node database management system consists of interconnected nodes that share access to the same database. Typically, the nodes are interconnected via a network and share access to shared storage to varying degrees, such as shared access to a set of disk drives and data blocks stored thereon. The nodes in a multi-node database system may be in the form of a group of computers (e.g., workstations, personal computers) interconnected via a network. Alternatively, the nodes may be nodes of a grid consisting of nodes in the form of server blades interconnected to other server blades on a rack.

[0097] Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computing resources (such as memory, nodes, and processes on the nodes for executing the integrated software components on processors) that are dedicated to performing specific functions on behalf of one or more clients.

[0098] Resources from multiple nodes in a multi-node database system can be allocated to run the software of a particular database server. Each combination of software and allocation of resources from a node is a server referred to herein as a "server instance" or "instance." A database server can include multiple database instances, some or all of which run on separate computers (including separate server blades).

[0099] A client can issue a series of requests, such as requests to execute queries, to a DBMS by establishing a database session. A database session consists of a specific connection established for a client to a database server, through which a client can issue a series of requests. A database session process executes within a database session and handles requests issued by a client through a database session. A database session can generate an execution plan for a query issued by a database session client and marshal an apply process to execute the execution plan.

[0100] The database server may maintain session state data about a database session. The session state data reflects the current state of the session and may include the identity of the user for whom the session was established, the services used by the user, instances of object types, language and character set data, statistics about resource usage for the session, values ​​of temporary variables generated by the process executing the software within the session, storage of cursors, variables, and other information.

[0101] The database server includes multiple database processes. The database processes run under the control of the database server (i.e., can be created or terminated by the database server) and perform various database server functions. The database processes include processes that run within a database session established for a client.

[0102] A database process is an execution unit. A database process can be a computer system process or thread or a user-defined execution context, such as a user thread or fiber. Database processes can also include "database server system" processes that provide services and / or execute functions on behalf of the entire database server. Such database server system processes include listeners, garbage collectors, log writers, and recovery processes.

[0103] The database dictionary may include multiple data structures that store database metadata. For example, the database dictionary may include multiple files and tables. Portions of the data structures may be cached in the main memory of the database server.

[0104] When a database object is said to be defined by a database dictionary, the database dictionary contains metadata that defines the properties of the database object. For example, metadata in a database dictionary that defines a database table can specify the column names and data types of the columns, and one or more files or portions thereof that store data for the table. Metadata in a database dictionary that defines a procedure can specify the name of the procedure, its arguments, and the return and argument data types, and can include source code and its compiled version.

[0105] Database objects may be defined by a database dictionary, but the metadata in the database dictionary itself may only partially specify the properties of the database object. Other properties may be defined by data structures that are not considered part of the database dictionary. For example, a user-defined function implemented in a JAVA class may be defined in part by a database dictionary by specifying the name of the user-defined function and by specifying references to files containing the Java class source code (i.e., java files) and the compiled version of the class (i.e., class files).

[0106] Query optimization and execution planning

[0107] Query optimization generates one or more different candidate execution plans for a query, which are evaluated by the query optimizer to determine which execution plan should be used to evaluate the query.

[0108] An execution plan can be represented by a graph of interconnected nodes, referred to herein as operators or row sources, each node corresponding to a step of the execution plan, referred to herein as an execution plan operation. The hierarchical structure of the graph (i.e., a directed tree) represents the order in which the execution plan operations are executed and how data flows between each execution plan operation. Execution plan operators generate sets of rows (which may be referred to as tables) as output, and execution plan operations include, for example, table scans, index scans, sort-merge joins, nested-loop joins, filters, and importantly, full outer joins.

[0109] The query optimizer can optimize queries by transforming them. In general, transforming a query involves rewriting the query into another semantically equivalent query that should produce the same results and can potentially execute more efficiently, i.e., for which a potentially more efficient and less expensive execution plan can be generated. Examples of query transformations include view merging, subquery unnesting, predicate movement and pushdown, common subexpression elimination, outer join to inner join conversion, materialized view rewrite, and star transformation.

[0110] Hardware Overview

[0111] An application or instance (such as the main instance 122 or the IIDC instance 152) runs on a computing device and includes a combination of software and an allocation of resources from the computing device. Specifically, an application is a combination of integrated software components and an allocation of computing resources (such as memory), and / or a process on a computing device for executing the integrated software components on a processor, the combination of software and computing resources being dedicated to performing the described functions of the application.

[0112] According to one or more embodiments, one or more functions described herein as being attributed to any process may be implemented by Figure 1 In some embodiments, each of the techniques and / or functions described herein is automatically executed and can be implemented using one or more computer programs, other software elements, and / or digital logic in any of a general purpose computer or a special purpose computer while performing data retrieval, transformation, and storage operations involving interaction and transformation of the physical state of the computer's memory.

[0113] According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. Special-purpose computing devices may be hardwired to perform these techniques, or may include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these techniques), or may include one or more general-purpose hardware processors that are programmed to perform these techniques according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices may also combine customized hard-wired logic, ASICs, or FPGAs with custom programming to implement these techniques. Special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that combine hard-wiring and / or program logic to implement these techniques.

[0114] For example, Figure 5 is a block diagram illustrating a computer system 500 upon which embodiments of the present invention may be implemented. Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a hardware processor 504 coupled to bus 502 for processing information. Hardware processor 504 may be, for example, a general purpose microprocessor.

[0115] The computer system 500 also includes a main memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 502 for storing information and instructions to be executed by the processor 504. The main memory 506 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by the processor 504. These instructions, when stored in a non-transitory storage medium accessible to the processor 504, make the computer system 500 a special-purpose machine customized to perform the operations specified in the instructions.

[0116] Computer system 500 also includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504. A storage device 510, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to bus 502 for storing information and instructions.

[0117] The computer system 500 may be coupled to a display 512, such as a cathode ray tube (CRT), via the bus 502 for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to the bus 502 for communicating information and command selections to the processor 504. Another type of user input device is a cursor control 516, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 504 and for controlling cursor movement on the display 512. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0118] Computer system 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with a computer system to make or program computer system 500 into a special purpose machine. According to one embodiment, computer system 500 performs the techniques described herein in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. These instructions may be read into main memory 506 from another storage medium, such as storage device 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0119] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or cassette tapes.

[0120] Storage media are distinct from but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0121] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 504 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 500 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on the bus 502. The bus 502 transfers the data to the main memory 506, from which the processor 504 retrieves and executes the instructions. The instructions received by the main memory 506 may optionally be stored on the storage device 510 before or after being executed by the processor 504.

[0122] Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides bidirectional data communication coupled to network link 520, wherein network link 520 is connected to local network 522. For example, communication interface 518 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, communication interface 518 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN. A wireless link can also be implemented. In any such implementation, communication interface 518 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0123] The network link 520 typically provides data communication to other data devices through one or more networks. For example, the network link 520 can provide a connection to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526 through a local network 522. The ISP 526 in turn provides data communication services through a global packet data communication network, now commonly referred to as the "Internet" 528. Both the local network 522 and the Internet 528 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 520 and through the communication interface 518 (which carry the digital data to and from the computer system 500) are example forms of transmission media.

[0124] Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520, and communication interface 518. In the Internet example, server 530 can send the requested code for an application program through Internet 528, ISP 526, local network 522, and communication interface 518.

[0125] The received code may be executed by processor 504 as it is received, and / or stored in storage device 510 or other non-volatile storage for later execution.

[0126] Software Overview

[0127] Figure 6 6 is a block diagram of a basic software system 600 that may be used to control the operation of computer system 500. Software system 600 and its components (including their connections, relationships, and functions) are merely exemplary and are not meant to limit implementation of the example embodiment(s). Other software systems suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functions.

[0128] Software system 600 is provided for directing the operation of computer system 500. Software system 600, which may be stored on system memory (RAM) 506 and fixed storage (eg, hard disk or flash memory) 510, includes a kernel or operating system (OS) 610.

[0129] OS 610 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more applications, represented as 602A, 602B, 602C ... 602N, may be "loaded" (e.g., transferred from fixed storage 510 into memory 506) for execution by system 600. Applications or other software intended for use on computer system 500 may also be stored as a downloadable set of computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., a Web server, app store, or other online service).

[0130] The software system 600 includes a graphical user interface (GUI) 615 for displaying the software in a graphical manner (e.g.,

[0131] GUI 615 is used to receive user commands and data in the form of "clicks" or "touch gestures" (such as "clicks" or "touch gestures"). In turn, these inputs can be operated by system 600 according to instructions from operating system 610 and / or (one or more) applications 602. GUI 615 is also used to display the results of operations from OS 610 and (one or more) applications 602, based on which the user can provide additional input or terminate the session (e.g., log out).

[0132] The OS 610 may execute directly on the bare hardware 620 (e.g., the processor(s) 504) of the computer system 500. Alternatively, a hypervisor or virtual machine monitor (VMM) 630 may be inserted between the bare hardware 620 and the OS 610. In this configuration, the VMM 630 acts as a software "buffer" or virtualization layer between the OS 610 and the bare hardware 620 of the computer system 500.

[0133] VMM 630 instantiates and runs one or more virtual machine instances ("guests"). Each guest includes a "guest" operating system (such as OS 610), and one or more applications (such as (one or more) applications 602) designed to execute on the guest operating system. VMM 630 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0134] In some cases, VMM 630 can allow a guest operating system to run as if it were running directly on bare hardware 620 of computer system 500. In these instances, the same version of the guest operating system that is configured to execute directly on bare hardware 620 can also execute on VMM 630 without modification or reconfiguration. In other words, VMM 630 can provide full hardware and CPU virtualization to guest operating systems in some cases.

[0135] In other cases, the guest operating system may be specially designed or configured to execute on VMM 630 to improve efficiency. In these instances, the guest operating system is "aware" that it is executing on a virtual machine monitor. In other words, VMM 630 can provide paravirtualization to the guest operating system in some cases.

[0136] A computer system process includes an allocation of hardware processor time, and an allocation of memory (physical and / or virtual), an allocation of memory for storing instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing hardware processor state (e.g., contents of registers) between allocations of hardware processor time when the computer system process is not running. A computer system process runs under the control of an operating system and may run under the control of other programs executing on the computer system.

[0137] The purpose of presenting the above basic computer hardware and software is to illustrate the basic underlying computer components that can be used to implement the (one or more) example embodiments. However, the (one or more) example embodiments are not necessarily limited to any particular computing environment or computing device configuration. Instead, the (one or more) example embodiments can be implemented in any type of system architecture or processing environment that a person skilled in the art understands from this disclosure as being able to support the features and functions of the (one or more) example embodiments given herein.

[0138] cloud computing

[0139] The term "cloud computing" is used generally herein to describe a computing model that enables on-demand access to a shared pool of computing resources (such as computer networks, servers, software applications, and services) and which allows resources to be quickly provisioned and released with minimal management effort or service provider interaction.

[0140] A cloud computing environment (sometimes called a cloud environment or just a cloud) can be implemented in a variety of different ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the public. In contrast, a private cloud environment is generally intended for use by or within a single organization. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud includes two or more types of clouds (e.g., private, community, or public) bound together by data and application portability.

[0141] In general, the cloud computing model enables some of those responsibilities that might previously have been provided by an organization's own information technology department to instead be delivered as a service layer within a cloud environment for use by consumers (either internally or externally to the organization, depending on the public / private nature of the cloud). Depending on the specific implementation, the precise definition of the components or features provided by or within each cloud service layer may vary, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on a cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages ​​and development tools supported by a PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything under the runtime execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications, and / or provide processes, storage, networks, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), in which the consumer uses a database server or database management system running on a cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

[0142] In the foregoing specification, embodiments of the present invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Therefore, the specification and drawings should be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention and what the applicant intends to be the scope of the invention is the literal and equivalent range of the resulting claims in the specific form of the set of claims issued from this application, including any subsequent corrections.

Claims

1. A computer-implemented method comprising: The database server instance receives a plurality of redo records for changes made to a primary database; The database server instance automatically applies the plurality of redo records to make changes to at least a portion of the primary database data stored in the buffer cache to produce first updated database data in the buffer cache; The database server instance executes a query on the first updated database data, including: It was detected that the buffer cache does not store one or more data blocks from the primary database that are required by the query. In response to detecting that the buffer cache does not store the one or more data blocks required for the query, obtaining the one or more data blocks from the second database server instance into the buffer cache to generate second updated database data in the buffer cache, and generating results for the query using the second updated database data stored in the buffer cache; The method is performed by one or more computing devices. 2 . The computer-implemented method of claim 1 , wherein the retrieved one or more data blocks are the latest versions of the one or more data blocks in a master database.

3. The computer-implemented method of claim 1, wherein the second database server instance manages the primary database.

4. The computer-implemented method of claim 3, wherein the second database server instance retrieves the one or more data blocks from one or more of: a second buffer cache maintained by the second database server instance; or database data stored on a persistent storage device maintained by the second database server instance.

5. The computer-implemented method of claim 1 , wherein: The primary database is managed by a plurality of database server instances including a second database server instance; The method further includes: The database server instance maintains association mapping data that maps data blocks to database server instances in the plurality of database server instances; determining, based on the association mapping data, that the one or more data blocks are associated with a second database server instance; Wherein retrieving the one or more data blocks from the second database server instance into the buffer cache is performed in response to determining that the one or more data blocks are associated with the second database server instance based on the association mapping data.

6. The computer-implemented method of claim 1, wherein the second database server instance manages a standby database that is a replica of the primary database.

7. The computer-implemented method of claim 6, wherein the second database server instance retrieves the one or more data blocks from one or more of: a second buffer cache maintained by the second database server instance; or database data stored on a persistent storage device maintained by the second database server instance.

8. The computer-implemented method of claim 1, wherein the plurality of redo records are received from a database server instance managing a primary database.

9. The computer-implemented method of claim 1, wherein the plurality of redo records are received from a service other than a database server instance managing a primary database.

10. The computer-implemented method of claim 1, wherein the buffer cache is implemented at least in part within a byte-addressable memory.

11. The computer-implemented method of claim 1 , further comprising: After obtaining the one or more data blocks from the second database server instance into the buffer cache: receiving one or more redo records for a second change made to a particular data block of the one or more data blocks; and The one or more redo records are applied to make a second change to the particular data block stored in the buffer cache.

12. The computer-implemented method of claim 1 , further comprising: receiving one or more redo records for a second change made to the particular data block; as well as In response to determining that the particular data block is not within the buffer cache, the one or more redo records are discarded without making any changes reflected in the one or more redo records.

13. The computer-implemented method of claim 1 , further comprising: using cached dictionary data in a buffer cache to identify a particular data block of the one or more data blocks for querying; After acquiring the one or more data blocks into the buffer cache, marking the particular data block as potentially current; After marking the particular data block as potentially current, applying the first redo record to the particular data block based on a detailed comparison of the initial state information in the first redo record with the information for the particular data block; marking the particular data block as current based on applying the first redo record to the particular data block; After marking the particular data block as current, a second redo record is applied to the particular data block without performing a detailed comparison.

Images