The present invention relates to database management systems and in particular, to query and change propagation scheduling for a heterogeneous database system.
Big data analytics is a process for examining large data sets to determine patterns, correlations, trends, and other information. An emerging trend in big data analytic applications is to use a secondary database system to offload large analytic queries from a primary database system, in order to boost query processing performance. The secondary database system may act as a query processing system that does not support all features of a standard database system. For example, the secondary database system may not be able to directly receive database statements or data changes from a client application. Rather, the secondary database system may rely on the primary database system to be ACID (Atomicity, Consistency, Isolation, Durability) compliant, as expected in standard database systems.
The secondary database system may store a copy of data on which queries received at the primary database system execute. Data changes are received and executed on the primary database system. New or updated data must be added to the database of the secondary database system, and deleted data must be removed.
A possible method for propagating changes to the secondary database is propagating changes on an as-needed, on-demand basis, when data is targeted by a query. Although on-demand propagation may spread out the computing cost of propagating changes, it increases the response time required when executing a query.
Another possible method is to propagate changes as soon as they are received or committed in the primary database system. This results in a faster query response time compared to on-demand propagation, but results in high overhead for the database system when large amounts of changes are received within a short amount of time by the primary database system.
A third possible method is to schedule change propagation at specific times or at regular intervals. However, this method does not guarantee that secondary database system will have up-to-date data prior to executing a query in the secondary database system. Thus, this method does not guarantee that a query will produce accurate results.
However, for data analytics queries, such as those performed for big data analytics, data consistency is required in order for a query to produce accurate results. Furthermore, since the goal of using of a secondary system is to increase query execution efficiency, query performance cannot be significantly affected by change propagation. Thus, a method for change propagation that maintains both data consistency and query execution efficiency is required.
Additionally, most systems that use a particular propagation method require users to configure the primary and secondary database system and select a particular change propagation method based on what the user expects the database systems' workload and data change pattern to be. Once the secondary database system is configured, it may be difficult or impossible to switch between different propagation methods if the workload and/or data change pattern is not as expected.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In the drawings:
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
General Overview
Techniques are described for efficient query processing and data change propagation at a secondary database system. As described above, a secondary database system may be configured to execute queries, or portions thereof, received at a primary database system. Database changes made at the primary database system are copied to the secondary database system.
The primary database system includes a scheduler process that determines when, and if, queries and database changes should be sent to the secondary database system. One or more tasks are created based on a query or data change received at the primary database system. The one or more tasks are sent to the scheduler process.
The scheduler process determines whether a task depends on any other task. If a task depends on another task, then the other task needs to be processed first. For example, if a query targets a database object that was updated by a data change, then the data change needs to be made at the secondary database system before the query can be executed by the secondary database system.
Based on the task dependencies, the scheduler process can determine an order for tasks to be processed. The scheduler process may also determine whether a query should be executed at primary database system or sent to the secondary database system, based on the total time required, including propagating data changes to the secondary database system.
Thus, the database system can flexibly schedule queries and data changes in order to minimize query execution time. For example, queries that do not rely on an update can be executed before other database updates, and data changes that are not needed by any queries can be delayed until other queries are executed.
System Overview
Primary database system 100 is also connected to a secondary database system 140, which may be an offload database system for primary database system 100. In an embodiment, secondary database system 140 is configured to execute queries, or parts of queries, more efficiently than primary database system 100. Secondary database system 140 is connected to database 150. Database 150 may be stored on one or more disks to which secondary database system 150 has access. Database 150 may store a copy of at least a portion of the data stored in database 130. In an embodiment, database 150 is an asynchronous replica of database 130. As used herein, an asynchronous replica refers to a replica database wherein data may be first written to a primary database and acknowledged as being completed before being copied to a secondary database.
In an embodiment, secondary database system 140 is not configured to receive and/or handle database queries such as SQL statements from end users. Client 110 does not connect directly to secondary database system 140, or send queries or changes directly to secondary database system 140. Rather, queries and data changes from client 110 are received at primary database system 100. Primary database system 100 determines whether to send any queries, or portions thereof, to secondary database system 140 for processing. Data changes are made to database 130, and then reproduced in or copied to database 150.
Primary database system 100 also comprises a scheduler process 120. As described in further detail below, when primary database system 100 receives a query, scheduler process 120 determines if the query, or a portion thereof, should be executed by secondary database 140. Scheduler process 120 determines when, and in what order, the queries (or portions of queries) and data changes should be sent to the secondary database system 140.
As used herein, “scheduler process” refers to a database process that schedules queries and data changes. The scheduler process schedules queries and data changes to be sent to the secondary database system. In an embodiment, the scheduler process also schedules queries and data changes for execution by the primary database system.
In an embodiment, the scheduler process is a database process running on the primary database system. In an embodiment, the scheduler process is a background process that receives queries and data changes from one or more foreground database processes that receive and process queries and database updates. For example, a foreground database process may include a query coordinator or a query optimizer. The scheduler process determines if, and when, a query or database update should be sent to the secondary database system, and communicates scheduling decisions to the one or more foreground database processes. In another embodiment, the scheduler process may be the same process, or part of a group of processes, that receives and processes queries and database updates for the primary database system.
In an embodiment, the scheduler process is configured to send queries and database changes directly to the secondary database system. In another embodiment, the scheduler process communicates with a foreground process to cause queries or database changes to be sent to the secondary database system.
Task Overview
The scheduler process receives queries and data changes to be sent to the secondary database system as one or more jobs or tasks. As referred to herein, a task is a unit of work that could be sent to, and processed by, the secondary database system. The scheduler process receives two types of tasks: query tasks and update tasks.
A task may comprise task data including: one or more target database objects, the size and/or number of database objects, the amount of time required to process the task at the primary database system, the amount of time required to process the task at the secondary database system, the time at which the corresponding query or data change was received by the primary database system, the time at which the task was created, the time at which a task was received by the scheduler process, and/or a target time for completing the task (a task “deadline”).
In an embodiment, each task includes data that indicates an order in which the task was received. For example, the task may include one or more timestamps, or values, which indicate the time at which the corresponding query or data change was received by the primary database system, the task was generated by the database system, and/or when the task was received by the scheduler process.
The scheduler process maintains a task list and a priority queue. In an embodiment, the task list and priority queue are stored in memory assigned to the scheduler process. In another embodiment, the task list and priority queue are stored in memory shared by other database processes or are stored on a persistent disk.
The task list stores a list of tasks received by the scheduler process. In an embodiment, task data for each task is stored in the task list in association with the task.
The priority queue indicates an order in which tasks should be processed. In an embodiment, each task is associated with a priority value and tasks in the priority queue are stored in order of priority value. When the scheduler process sends a task to the secondary database, it selects one or more tasks from the front of the priority queue.
Query Tasks
A query task is a query, or a portion of a query, that may be offloaded to a secondary database system for processing. The query task may comprise data indicating the data objects targeted by the query task. The query task may also include data indicating an estimated cost for processing the query task in the primary database system and/or an estimated cost for processing the query task in the secondary database system.
A single query may be divided into a plurality of query tasks, based on the data required by the query. For example, database 150 may store a copy of only a portion of the data from database 130. The primary database system 100 may receive a query that targets some data that is in database 150, and some data that is only in database 130. A query task may be generated for the portion of the query that targets data stored in database 150, while the portion of the query that targets data not copied in database 150 is processed at the primary database system.
To execute a query, a DBMS first generates a query execution plan. An execution plan generated by a DBMS defines operations to be performed to execute a query and an order for performing the operations, known as plan operations. When a database instance receives a query, a query coordinator formulates a query execution plan for executing the query.
In an embodiment, a query optimizer determines whether one or more portions of the query could be executed more efficiently by the secondary database system. The query optimizer may determine the one or more portions based on, for example, the structure and contents of the query, the database objects targeted by the query, the database objects stored in the secondary database, and the types of queries that the secondary database system is configured to process. The query optimizer generates a query task for each of the one or more portions, and sends the query task to the scheduler process. For the purpose of illustrating a clear example, techniques are described with reference to queries, but may be used with portions of queries.
Update Tasks
An update task is a set of data changes to be propagated to the secondary database system. Unlike query tasks, data changes are made at both the primary database system and the secondary database system. The update task may be generated after a change has been committed in the primary database system, or generated when a data change, such as a DML (data manipulation language) statement, is received by the primary database system.
The update task may comprise data indicating changes or deletions made to the primary database. The update task may also include data indicating an estimated cost for processing the update task in the secondary database system.
In an embodiment, the data indicating data changes includes one or more identifiers associated with one or more respective database objects. For example, the data may include a plurality of row identifiers. The data may indicate the changes, additions, or deletions to be made for each respective database object. The identifiers and the changes are sent to the secondary database system as part of sending an update task to the secondary database system for processing. When the update task received by the secondary database system, the secondary database system may use the data to determine which database objects to update and what data should be modified, added, or deleted.
Task Dependency
The scheduler process determines if any dependencies exist between received tasks. If a first task depends on a second task, then the second task needs to be processed before the first task may be processed. For example, if a query depends on a database object that was updated before the query was received, then the update needs to be propagated to the secondary database system before the query can be executed at the secondary database system.
A task dependency exists when a task targets a database object that is modified by a previously received update task. A database object may include a row, a table, or a table partition. For example, assume a first update task targets a particular table. If an update task or query task, received after the first update task, also targets the particular table, then the update task or query task depends on the first update task. In contrast, if an update task or query task is received after a previous query task, the update task or query task would not depend on the previous query task, since no data was modified. Similarly, if the first update task is processed before the query or update task is received, then the query or update task does not depend on the first update task, since the data change has already been propagated.
In an embodiment, the task list includes data that indicates task dependencies. For example, the data may indicate, for each task, which tasks in the task list it depends upon. In another embodiment, the database system stores a separate mapping that indicates task dependencies. For example, the database system may store a directed graph, where each node of the graph corresponds to a task, and the edges of the graph indicate a dependency between two nodes.
Referring to
Based on the order in which the tasks are received, the scheduler process determines what task dependencies, if any, exists between the tasks. In an embodiment, the scheduler process determines an order in which tasks are received based on a timestamp value associated with the task. The timestamp value may indicate when the task was generated or when the query or data change was received. As an example, query task 212 may be associated with a timestamp value indicating time T1. In another embodiment, the scheduler process stores each task in the task list in the order in which it was received by the scheduler process.
If a task targets a database object that was not targeted by a previously received update task, then the task does not depend on any tasks. For example, query task 212 is received before any update tasks that targets the “lineItem” table, so it does not depend on any tasks. Similarly, update tasks 202 and 206 were received before any updates that target their respective tables, so update task 202 and 206 also do not depend on any tasks.
If a task is received after an update task and targets the same database object as the update task, then it depends on the update task. For example, update task 204 is received after update task 202 and both update tasks target the “lineItem” table. Thus, update task 204 depends on update task 202.
A task may depend, either directly or indirectly, on more than one update tasks. For example, query task 218 is received after update task 204 and also targets the “lineItem” table. Thus, query task 218 depends on update task 204. Query task 218 also indirectly depends on update task 202, since update task 204 depends on update task 202. Thus, query task 218 requires both update task 202 and update task 204 to process prior to being executed.
As another example, query task 214 is received after update task 202 and update task 206. Query task 214 targets the “lineItem” table, which was updated by update task 202. Query task 214 also targets the “customer” table, which was updated by update task 206. Thus, query task 214 depends on both update task 202 and update task 206.
Task Cost
Each task may be associated with a task cost. A task cost is an estimated amount of time for a task to be processed by a database system.
The task cost for an update task is an estimated amount of time for propagating the update to the secondary database system. In an embodiment, the cost is based on the initial cost of populating the secondary database system. When the secondary database system is first configured and initialized, data is copied from the primary database system to the secondary database system. Based on the amount of data copied from the primary database system and the amount required to copy the data, the primary database system can compute an average time for propagating data. For example, a number of rows may initially be copied to the secondary database system and an average amount of time per row may be calculated. An estimated amount of time for an update task may be computed based on the average amount of time per row and the number of rows targeted by the update task.
In an embodiment, the database system may update the average time for data propagation by tracking the amount of time taken by each update task and the amount of data targeted by each update task. The updated average time may be used for estimating a cost for subsequent update tasks.
The task cost for a query task is an estimated execution cost for the query. A query task may be associated with two execution costs: an execution cost for executing the query in the primary database system and an execution cost for executing the query in the secondary database system.
An execution cost for executing a query task may be calculated by a query optimizer. In an embodiment, the process scheduler requests the execution cost from the query optimizer after it receives a task. In another embodiment, the query optimizer determines whether a query is a candidate for processing in the secondary database system. The query optimizer may determine that the query is a candidate for processing in the secondary database system if the execution cost for executing in the secondary database system is less than the execution cost for executing in the primary database system. The task data for the query task may include the primary database system execution cost and the secondary database system execution cost.
In an embodiment, the execution cost for a query task includes the cost of propagating changes to database objects required by the query task. If one or more tasks need to be processed prior to processing the query task, the execution cost of each of the one or more tasks is added to the execution cost for processing the query task. In an embodiment, the scheduler process determines task dependencies for a task and calculates an updated secondary database system execution cost based on task dependencies for the query task. For example, referring to query task 218, the total task cost includes the execution cost of the query at the secondary database system, as well as the task cost for update task 202 and update task 204.
Scheduling Tasks
When the scheduler process receives a query task, it determines either: 1) the query task should be sent to the secondary database system; 2) the query task should be processed in the primary database system; or 3) the query task should wait before processing. Waiting to process the query task may include waiting for other query tasks to be processed and/or waiting for database updates to be propagated to the secondary database system.
At step 300, the scheduler process receives a task. The scheduler process adds the received task and task data to the task list. In an embodiment, the scheduler process adds data indicating a time at which the task was received to the task data. For the purpose of illustration, assume scheduler process 120 receives query task 218.
At step 302, the scheduler process determines if the received task depends on any previously received tasks. As described above, the task dependencies are used to determine an estimated execution time for processing the task on the secondary database system. The scheduler process stores the dependency data in a task dependency mapping. In the present example, scheduler process 120 determines that query task 218 depends on task 204, which depends on task 202.
At step 304, the scheduler process determines the task costs for the task. If the task is a query task, the scheduler process determines the execution cost for processing the task at the primary database system and the secondary database system. In an embodiment, the scheduler process requests the execution costs for the query task from a query optimizer. In another embodiment, the execution cost for the query task is stored in the task data received by the scheduler process.
As described above, the execution cost for a query task on the secondary database system includes the costs for any update tasks that the query task depends on. Based on the dependencies determined in step 302, the scheduler process determines the total execution cost for processing the task at the secondary database system. In the present example, the total execution cost for task 218 includes the task cost for task 204 and the task cost for task 202.
At step 306, the scheduler process determines whether to execute a task in a primary database system or a secondary database system. An update task is always processed by the secondary database system. A query task may be processed by a secondary database system or the primary database system based on the respective execution costs.
In an embodiment, each task is associated with a deadline. The scheduler process may determine the deadline based on the task cost and store the deadline in task data. As referred to herein, a deadline is a time by which a task should be executed. The deadline for a query task is based on the execution cost for the primary database system. For example, the deadline for query task may be the time at which the query task is received, plus the primary database execution cost.
The deadline for an update task is based on the tasks that depend on the update task. If one or more tasks depend on the update task, then the deadline for the update task is the shortest deadline from the respective deadlines of the one or more tasks. In an embodiment, if the received task depends on an update task, then the deadline for the update task may be updated based on the deadline for the received task. If no task depends on the update task, then the update task has no deadline. In an embodiment, if the task has no deadline, then the deadline may be indicated in task data by a large value.
The current time, or the time at which the task was received, plus the total execution cost for processing a query task on the secondary database system, is compared with the deadline to determine whether the query task will meet the deadline. If a query task will not meet the deadline, then the scheduler process determines that the query task should be processed in the primary database system. For example, if the current time plus the total execution cost at secondary database system for query task 218 will exceed the deadline, then scheduler process 120 determines that task 218 should be executed at the primary database system.
If a query task will meet the deadline, then the scheduler process determines that the task should be executed in the secondary database system. In an embodiment, when the scheduler process determines that a task should be sent to the secondary database system, it sends the task to the secondary database system or notifies a foreground process that the task should be sent to the secondary database system.
In another embodiment, the scheduler process adds tasks that will be sent to the secondary database system to a priority queue. Each task is associated with a priority value and tasks in the priority queue are sorted based on the priority value. The scheduler process may be configured to assign priorities to tasks based on optimization goals for the database systems, such as maximizing secondary database system usage and minimizing query execution time.
The priority value of a task may also be based on the task deadline. For example, the priority value may be the inverse of the task deadline, such that tasks with an earlier deadline may be added to the front of the queue, while tasks with a later deadline or no deadline (i.e., an update task with no dependent tasks) may be added to the end of the queue.
In an embodiment, the scheduler process adds a task to the priority queue when it is ready to be sent to the secondary database system. A task is ready to be sent if it does not depend on any other tasks. If a task depends on another task, the task remains in the task list and is not added to the priority queue. Once the task it depends on is removed from the priority queue, the scheduler process adds the task to the priority queue.
Completeting Scheduled Tasks
After tasks are added to the priority queue, the scheduler process periodically selects one or more tasks to be sent to the secondary database system.
At step 400, the scheduler process selects one or more tasks from the priority queue to send to the secondary database system. In an embodiment, the number of tasks is based on the number of tasks the secondary database system can process concurrently. For example, if the secondary database system processes tasks serially, then the scheduler process may select a single task. If the secondary database system processes tasks in parallel, for example, if the secondary database system is a multi-node database system, then the scheduler process may select a plurality of tasks to be processed in parallel.
In an embodiment, the scheduler process sends the task to the secondary database system directly. In another embodiment, the scheduler process notifies a foreground database process of the scheduling decision, and the foreground database process sends the task to the secondary database.
At step 402, the one or more selected tasks are removed from the task list and the priority queue. In an embodiment, the tasks are removed from the task list after the secondary database system has indicated that the tasks were completed. For example, the secondary database system may send a message to the primary database system when a data change has been completed or when a query has finished processing. As another example, the secondary database system may send the results for a query to the primary database system when it has finished processing the query.
At step 404, the task dependencies for remaining tasks are updated. Updating the task dependencies may include determining which tasks depended on the completed task and re-calculating their estimated cost based on the actual time taken to complete the task, removing the completed task from a task dependency mapping, and/or adding newly received tasks to the priority queue.
For example, if a subsequently received task requires a database object that was updated by the completed task, the received task would not depend on the completed task, since the completed task has been removed from the task list and the task dependency mapping. In other words, the cost of processing the received task at the secondary database system would not include the cost of processing the completed task, since the task has already been completed.
At step 406, the scheduler process updates the priority queue to determine if remaining query tasks should still be sent to the secondary database system. In an embodiment, the scheduler process determines whether each query task could still be processed before their respective deadline. The scheduler process may compare the deadline for each query task with the current time and estimated time for processing in the secondary database system. If the estimated processing time exceeds the deadline, then the scheduler process may determine that the query task should be processed at the primary database system.
In an embodiment, the scheduler process may notify a foreground process that the task should be processed at the primary database system. In another embodiment, the scheduler process schedules the task to be processed by the primary database system.
In an embodiment, if the scheduler process determines that the query task should be processed at the primary database system, the query task is removed from the task list and the priority queue. The deadline for update tasks that the query task depended on are updated, if necessary, and the priority queue may be re-sorted based on the updated deadlines.
If tasks remain in the priority queue, the process returns to step 400 to select one or more new tasks to process.
DBMS Overview
Embodiments of the present invention are used in context of DBMSs. Therefore, a description of a DBMS is useful.
A DBMS manages one or more databases. A DBMS may comprise one or more database servers. A database comprises database data and a database dictionary that are stored on a persistent memory mechanism, such as a set of hard disks. Database data may be stored in one or more database containers. Each container contains records. The data within each record is organized into one or more fields. In relational DBMSs, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented database, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
A database block, also referred to as a data block, is a unit of persistent storage. A database block is used by a database server to store database records (e.g., to store rows of a table, to store column values of a column). When records are read from persistent storage, a database block containing the record is copied into a database block buffer in RAM memory of a database server. A database block usually contains multiple rows, and control and formatting information (e.g., offsets to sequences of bytes representing rows or other data structures, list of transactions affecting a row). A database block may be referenced by a database block address.
A multi-node database management system is made up of interconnected nodes that share access to the same database or databases. Typically the nodes are interconnected via a network and share access, in varying degrees, to shared storage, e.g. shared access to a set of disk drives and data blocks stored thereon. The nodes in the multi-node database system may be in the form of a group of computers (e.g. work stations, personal computers) that are interconnected via a network. Alternately, the nodes may be the nodes of a grid, which is composed of nodes in the form of server blades interconnected with other server blades on a rack.
Each node in a multi-node database system may host a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computation resources being dedicated to performing a particular function on behalf of one or more clients.
Hardware Overview
According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the 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 persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.
For example,
Computer system 500 also includes a main memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504. Such instructions, when stored in non-transitory storage media accessible to processor 504, render computer system 500 into a special-purpose machine that is customized to perform the operations specified in the instructions.
Computer system 500 further 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.
Computer system 500 may be coupled via bus 502 to a display 512, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to bus 502 for communicating information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
Computer system 500 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such 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, hard-wired circuitry may be used in place of or in combination with software instructions.
The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.
Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, 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 infra-red data communications.
Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 502. Bus 502 carries the data to main memory 506, from which processor 504 retrieves and executes the instructions. The instructions received by main memory 506 may optionally be stored on storage device 510 either before or after execution by processor 504.
Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network 522. For example, communication interface 518 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 520 typically provides data communication through one or more networks to other data devices. For example, network link 520 may provide a connection through local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526. ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528. Local network 522 and Internet 528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 520 and through communication interface 518, which carry the digital data to and from computer system 500, are example forms of transmission media.
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, a server 530 might transmit a requested code for an application program through Internet 528, ISP 526, local network 522 and communication interface 518.
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.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.
Number | Name | Date | Kind |
---|---|---|---|
4507751 | Gawlick et al. | Mar 1985 | A |
4710926 | Brown et al. | Dec 1987 | A |
4782325 | Jeppsson et al. | Nov 1988 | A |
4945474 | Elliott et al. | Jul 1990 | A |
5095421 | Freund | Mar 1992 | A |
5146571 | Logan | Sep 1992 | A |
5182752 | DeRoo et al. | Jan 1993 | A |
5233618 | Gilder et al. | Aug 1993 | A |
5241675 | Sheth et al. | Aug 1993 | A |
5263156 | Bowen et al. | Nov 1993 | A |
5287496 | Chen et al. | Feb 1994 | A |
5327556 | Mohan | Jul 1994 | A |
5329628 | Yomamoto et al. | Jul 1994 | A |
5333265 | Orimo et al. | Jul 1994 | A |
5333316 | Champagne et al. | Jul 1994 | A |
5355477 | Strickland et al. | Oct 1994 | A |
5369757 | Spiro et al. | Nov 1994 | A |
5388196 | Pajak et al. | Feb 1995 | A |
5418940 | Mohan | May 1995 | A |
5423037 | Hvasshovd | Jun 1995 | A |
5454102 | Tang et al. | Sep 1995 | A |
5487164 | Kirchhofer et al. | Jan 1996 | A |
5553279 | Goldring | Sep 1996 | A |
5555404 | Torbjørnsen et al. | Sep 1996 | A |
5559991 | Kanfi | Sep 1996 | A |
5574906 | Morris | Nov 1996 | A |
5581753 | Terry et al. | Dec 1996 | A |
5581754 | Terry et al. | Dec 1996 | A |
5588012 | Oizumi | Dec 1996 | A |
5603024 | Goldring | Feb 1997 | A |
5613113 | Goldring | Mar 1997 | A |
5696775 | Nemazie et al. | Dec 1997 | A |
5717893 | Mattson | Feb 1998 | A |
5734898 | He | Mar 1998 | A |
5742792 | Yanai et al. | Apr 1998 | A |
5778430 | Ish et al. | Jul 1998 | A |
5805799 | Fredrickson et al. | Sep 1998 | A |
5806076 | Ngai et al. | Sep 1998 | A |
5870758 | Bamford et al. | Feb 1999 | A |
5870759 | Bauer et al. | Feb 1999 | A |
5870763 | Lomet | Feb 1999 | A |
5893930 | Song | Apr 1999 | A |
5924096 | Draper et al. | Jul 1999 | A |
5956731 | Bamford et al. | Sep 1999 | A |
5960436 | Chang et al. | Sep 1999 | A |
5974427 | Reiter | Oct 1999 | A |
5983277 | Heile et al. | Nov 1999 | A |
5991771 | Falls et al. | Nov 1999 | A |
6009432 | Tarin | Dec 1999 | A |
6009542 | Koller et al. | Dec 1999 | A |
6014669 | Slaughter et al. | Jan 2000 | A |
6026406 | Huang et al. | Feb 2000 | A |
6044367 | Wolff | Mar 2000 | A |
6067550 | Lomet | May 2000 | A |
6094708 | Hilla et al. | Jul 2000 | A |
6098190 | Rust et al. | Aug 2000 | A |
6151607 | Lomet | Nov 2000 | A |
6192377 | Ganesh et al. | Feb 2001 | B1 |
6226650 | Mahajan | May 2001 | B1 |
6272500 | Sugita | Aug 2001 | B1 |
6298319 | Heile et al. | Oct 2001 | B1 |
6298425 | Whitaker et al. | Oct 2001 | B1 |
6324661 | Gerbault et al. | Nov 2001 | B1 |
6353835 | Lieuwen | Mar 2002 | B1 |
6393485 | Chao et al. | May 2002 | B1 |
6438724 | Cox et al. | Aug 2002 | B1 |
6446234 | Cox et al. | Sep 2002 | B1 |
6449623 | Bohannon et al. | Sep 2002 | B1 |
6516327 | Zondervan et al. | Feb 2003 | B1 |
6523032 | Sunkara | Feb 2003 | B1 |
6529906 | Chan | Mar 2003 | B1 |
6535869 | Housel, III | Mar 2003 | B1 |
6560743 | Plants | May 2003 | B2 |
6574717 | Ngai et al. | Jun 2003 | B1 |
6691139 | Ganesh et al. | Feb 2004 | B2 |
6728879 | Atkinson | Apr 2004 | B1 |
6732125 | Autrey et al. | May 2004 | B1 |
6751616 | Chan | Jun 2004 | B1 |
6775681 | Ballamkonda | Aug 2004 | B1 |
6804671 | Loaiza et al. | Oct 2004 | B1 |
6839751 | Dietz et al. | Jan 2005 | B1 |
6886084 | Kawashima et al. | Apr 2005 | B2 |
6980988 | Demers et al. | Dec 2005 | B1 |
7003694 | Anderson et al. | Feb 2006 | B1 |
7024656 | Ahad | Apr 2006 | B1 |
7076508 | Bourbonnais et al. | Jul 2006 | B2 |
7080075 | Chan | Jul 2006 | B1 |
7136970 | Yoshiya et al. | Nov 2006 | B2 |
7149769 | Lubbers et al. | Dec 2006 | B2 |
7149858 | Kiselev | Dec 2006 | B1 |
7155463 | Wang et al. | Dec 2006 | B1 |
7222136 | Brown et al. | May 2007 | B1 |
7228354 | Chambliss et al. | Jun 2007 | B2 |
7237027 | Raccah et al. | Jun 2007 | B1 |
7246275 | Therrien et al. | Jul 2007 | B2 |
7257689 | Baird | Aug 2007 | B1 |
7284151 | Chandrasekaran | Oct 2007 | B2 |
7287034 | Wong et al. | Oct 2007 | B2 |
7290017 | Wang et al. | Oct 2007 | B1 |
7293011 | Bedi | Nov 2007 | B1 |
7363538 | Joydip et al. | Apr 2008 | B1 |
7370068 | Pham et al. | May 2008 | B1 |
7464113 | Girkar et al. | Dec 2008 | B1 |
7599967 | Girkar et al. | Oct 2009 | B2 |
7600063 | Loaiza | Oct 2009 | B2 |
7627612 | Ahal et al. | Dec 2009 | B2 |
7627614 | Hu et al. | Dec 2009 | B2 |
7644084 | Rapp | Jan 2010 | B2 |
7734580 | Lahiri et al. | Jun 2010 | B2 |
7761425 | Erickson et al. | Jul 2010 | B1 |
7822717 | Kappor et al. | Oct 2010 | B2 |
7895216 | Longshaw et al. | Feb 2011 | B2 |
7966293 | Owara et al. | Jun 2011 | B1 |
7996363 | Girkar et al. | Aug 2011 | B2 |
8024396 | Seddukhin | Sep 2011 | B2 |
8286182 | Chan | Oct 2012 | B2 |
8364648 | Sim-Tang | Jan 2013 | B1 |
8433684 | Munoz | Apr 2013 | B2 |
8468320 | Stringham | Jun 2013 | B1 |
8473953 | Bourbonnais | Jun 2013 | B2 |
8478718 | Ranade | Jul 2013 | B1 |
8560879 | Goel | Oct 2013 | B1 |
8615578 | Hu et al. | Dec 2013 | B2 |
8694733 | Krishnan et al. | Apr 2014 | B2 |
8832142 | Marwah et al. | Sep 2014 | B2 |
8838919 | Shi et al. | Sep 2014 | B2 |
8856484 | Ben-Tsion et al. | Oct 2014 | B2 |
8868492 | Garin et al. | Oct 2014 | B2 |
8868504 | Aranna et al. | Oct 2014 | B2 |
8930312 | Rath | Jan 2015 | B1 |
9026679 | Shmuylovich | May 2015 | B1 |
9077579 | Chu | Jul 2015 | B1 |
9146934 | Hu et al. | Sep 2015 | B2 |
9244996 | Bourbonnais | Jan 2016 | B2 |
9767178 | Srivastava et al. | Sep 2017 | B2 |
20020049950 | Loaiza et al. | Apr 2002 | A1 |
20020091718 | Bohannon et al. | Jul 2002 | A1 |
20020112022 | Kazar et al. | Aug 2002 | A1 |
20020133508 | LaRue et al. | Sep 2002 | A1 |
20020143755 | Wynblatt et al. | Oct 2002 | A1 |
20020165724 | Blankesteijn | Nov 2002 | A1 |
20030046396 | Richter et al. | Mar 2003 | A1 |
20030061227 | Baskins | Mar 2003 | A1 |
20030061537 | Cha et al. | Mar 2003 | A1 |
20030126114 | Tedesco | Jul 2003 | A1 |
20030140050 | Li | Jul 2003 | A1 |
20030140288 | Loaiza et al. | Jul 2003 | A1 |
20030212660 | Kerwin | Nov 2003 | A1 |
20030217064 | Walters | Nov 2003 | A1 |
20030217071 | Kobayashi et al. | Nov 2003 | A1 |
20040003087 | Chambliss et al. | Jan 2004 | A1 |
20040062106 | Ramesh et al. | Apr 2004 | A1 |
20040193570 | Yaegar | Sep 2004 | A1 |
20040243578 | Chan | Dec 2004 | A1 |
20040267809 | East et al. | Dec 2004 | A1 |
20050005083 | Ozdemir | Jan 2005 | A1 |
20050022047 | Chandrasekaran | Jan 2005 | A1 |
20050038831 | Souder et al. | Feb 2005 | A1 |
20050055380 | Thompson et al. | Mar 2005 | A1 |
20050120025 | Rodriguez et al. | Jun 2005 | A1 |
20050165798 | Cherkauer et al. | Jul 2005 | A1 |
20060004691 | Sifry | Jan 2006 | A1 |
20060015542 | Pommerenk | Jan 2006 | A1 |
20060047713 | Gornshtein | Mar 2006 | A1 |
20060064405 | Jiang et al. | Mar 2006 | A1 |
20060080646 | Aman | Apr 2006 | A1 |
20060112222 | Barall | May 2006 | A1 |
20060129595 | Sankaran | Jun 2006 | A1 |
20060168585 | Grcevski | Jul 2006 | A1 |
20060173833 | Purcell et al. | Aug 2006 | A1 |
20060200497 | Hu et al. | Sep 2006 | A1 |
20060212481 | Stacey et al. | Sep 2006 | A1 |
20060212573 | Loaiza | Sep 2006 | A1 |
20060224551 | Lariba-Pey | Oct 2006 | A1 |
20060242513 | Loaiza et al. | Oct 2006 | A1 |
20070038689 | Shinkai | Feb 2007 | A1 |
20070083505 | Ferrari et al. | Apr 2007 | A1 |
20070100912 | Pareek et al. | May 2007 | A1 |
20070156957 | MacHardy et al. | Jul 2007 | A1 |
20070174292 | Li | Jul 2007 | A1 |
20070226277 | Holenstein et al. | Sep 2007 | A1 |
20070239680 | Oztekin et al. | Oct 2007 | A1 |
20080005112 | Shavit | Jan 2008 | A1 |
20080016074 | Ben-dyke et al. | Jan 2008 | A1 |
20080059492 | Tarin | Mar 2008 | A1 |
20080104283 | Shin et al. | May 2008 | A1 |
20080126846 | Vivian et al. | May 2008 | A1 |
20080147599 | Young-Lai | Jun 2008 | A1 |
20080162587 | Auer | Jul 2008 | A1 |
20080177803 | Fineberg et al. | Jul 2008 | A1 |
20080222311 | Lee | Sep 2008 | A1 |
20080228835 | Lashley et al. | Sep 2008 | A1 |
20080244209 | Seelam et al. | Oct 2008 | A1 |
20080256143 | Reddy et al. | Oct 2008 | A1 |
20080256250 | Wakefield et al. | Oct 2008 | A1 |
20080281784 | Zane et al. | Nov 2008 | A1 |
20080281865 | Price et al. | Nov 2008 | A1 |
20090024384 | Kobayashi et al. | Jan 2009 | A1 |
20090034377 | English et al. | Feb 2009 | A1 |
20090063591 | Betten et al. | Mar 2009 | A1 |
20090119295 | Chou et al. | May 2009 | A1 |
20090182746 | Mittal et al. | Jul 2009 | A1 |
20090248756 | Akidau | Oct 2009 | A1 |
20090268903 | Bojinov et al. | Oct 2009 | A1 |
20090307290 | Barsness et al. | Dec 2009 | A1 |
20100036843 | MacNaughton et al. | Feb 2010 | A1 |
20100082646 | Meek | Apr 2010 | A1 |
20100082648 | Potapov | Apr 2010 | A1 |
20100122026 | Umaamageswaran et al. | May 2010 | A1 |
20100145909 | Ngo | Jun 2010 | A1 |
20100211577 | Shimuzu et al. | Aug 2010 | A1 |
20100235335 | Heman et al. | Sep 2010 | A1 |
20100250549 | Muller et al. | Sep 2010 | A1 |
20100318495 | Yan | Dec 2010 | A1 |
20100318570 | Narasinghanallur et al. | Dec 2010 | A1 |
20110004586 | Cherryholmes et al. | Jan 2011 | A1 |
20110029569 | Ganesh et al. | Feb 2011 | A1 |
20110060724 | Chan | Mar 2011 | A1 |
20110066791 | Goyal et al. | Mar 2011 | A1 |
20110087633 | Kreuder et al. | Apr 2011 | A1 |
20110087637 | Sundaram et al. | Apr 2011 | A1 |
20110099179 | Balebail | Apr 2011 | A1 |
20110138123 | Aditya et al. | Jun 2011 | A1 |
20110145207 | Agrawal et al. | Jun 2011 | A1 |
20110231362 | Attarde et al. | Sep 2011 | A1 |
20110238655 | Clorain et al. | Sep 2011 | A1 |
20110307450 | Hahn et al. | Dec 2011 | A1 |
20120054158 | Hu et al. | Mar 2012 | A1 |
20120054533 | Shi et al. | Mar 2012 | A1 |
20120109926 | Novik et al. | May 2012 | A1 |
20120173515 | Jeong et al. | Jul 2012 | A1 |
20120278282 | Lu | Nov 2012 | A1 |
20120284228 | Ghosh | Nov 2012 | A1 |
20120323849 | Garin et al. | Dec 2012 | A1 |
20120323971 | Pasupuleti | Dec 2012 | A1 |
20130085742 | Baker et al. | Apr 2013 | A1 |
20130117237 | Thomsen et al. | May 2013 | A1 |
20130132674 | Sundrani | May 2013 | A1 |
20130185270 | Brower | Jul 2013 | A1 |
20130198133 | Lee | Aug 2013 | A1 |
20130212068 | Talius et al. | Aug 2013 | A1 |
20140040218 | Kimura et al. | Feb 2014 | A1 |
20140059020 | Hu et al. | Feb 2014 | A1 |
20140075493 | Krishnan et al. | Mar 2014 | A1 |
20140095452 | Lee et al. | Apr 2014 | A1 |
20140095530 | Lee et al. | Apr 2014 | A1 |
20140095546 | Kruglikov et al. | Apr 2014 | A1 |
20140164331 | Li et al. | Jun 2014 | A1 |
20140258241 | Chen | Sep 2014 | A1 |
20140279840 | Chan et al. | Sep 2014 | A1 |
20150032694 | Rajamani et al. | Jan 2015 | A1 |
20150088811 | Hase et al. | Mar 2015 | A1 |
20150088822 | Raja et al. | Mar 2015 | A1 |
20150088824 | Kamp et al. | Mar 2015 | A1 |
20150088830 | Kamp | Mar 2015 | A1 |
20150088926 | Chavan et al. | Mar 2015 | A1 |
20150089125 | Mukherjee et al. | Mar 2015 | A1 |
20150089134 | Mukherjee et al. | Mar 2015 | A1 |
20150120659 | Srivastava et al. | Apr 2015 | A1 |
20150120780 | Jain | Apr 2015 | A1 |
20150254240 | Li et al. | Sep 2015 | A1 |
20150317183 | Little | Nov 2015 | A1 |
20160179867 | Li et al. | Jun 2016 | A1 |
20160292167 | Tran | Oct 2016 | A1 |
20170116252 | Krishnaswamy | Apr 2017 | A1 |
20170116298 | Ravipati | Apr 2017 | A1 |
20180046550 | Chang | Feb 2018 | A1 |
20180046691 | Barsness | Feb 2018 | A1 |
20180121511 | Li | May 2018 | A1 |
20180165324 | Krishnaswamy | Jun 2018 | A1 |
Number | Date | Country |
---|---|---|
0 503 417 | Sep 1992 | EP |
050180 | Sep 1992 | EP |
2 608 070 | Jun 2013 | EP |
1 332 631 | Oct 1973 | GB |
2505 185 | Feb 2014 | GB |
59-081940 | May 1984 | JP |
02-189663 | Jul 1990 | JP |
08-235032 | Sep 1996 | JP |
10-040122 | Feb 1998 | JP |
10-240575 | Sep 1998 | JP |
WO 2007078444 | Jul 2007 | WO |
Entry |
---|
Ramez Elmasri; Fundamentals of Databse Systems; 2000; Addison-Wesly; pp. 580-628 and 771-786 (Year: 2000). |
Ramex Elmasri; The Fundamentals of Database Systems; Peason; 2003; Fourth Edition; pp. 1-1029 (Year: 2003). |
WenlieXie; Asynchronous Large-Scale Graph Processing Made Easy; Academia; 2013; pp. 1-13 (Year: 2013). |
S. Guirguis, M. A. Sharaf, P. K. Chrysanthis, A. Labrinidis, and K. Pruhs, “Adaptive scheduling of web transactions”, In ICDE, dated 2009, 13 pages. |
Oracle, “Oracle Database In-Memory”, Oracle White Paper, Oracle 2014, updated Feb. 2019, 44 pages. |
G. Buttazzo, M. Spuri, and F. Sensini. “Value vs. deadline scheduling in overload conditions”, In Proc. of RTSS '95, dated 1995, 10 pages. |
B. Schroeder and M. Harchol-Balter. “Web servers under overload: How scheduling can help”, ACM Trans. Inter. Tech., 6(1):20-52, dated 2006, 20 pages. |
W. Cao and D. Aksoy. “Beat the clock: a multiple attribute approach for scheduling data broadcast”. In MobiDE '05, pp. 89-96, 2005, 8 pages. |
D.-Z. He, F.-Y. Wang, W. Li, and X.-W. Zhang. “Hybrid earliest deadline first preemption threshold scheduling for real-time systems”. In ICMLC, dated 2004, 6 pages. |
Teschke, et al., “Concurrent Warehouse Maintenance Without Comprising Session Consistency”, 1998, 10 pages. |
Vassilakis et al., “Implementation of Transaction and Concurrency Control Support in a Temporal DBMS” Information Systems, vol. 23, No. 5, 1998, 16 pages. |
Bober et al., “On Mixing Queries and Transactions Via Multiversion Locking”, IEEE, 1992, 11 pages. |
Mohan et al., “Efficient and Flexible Methods for Transient Versioning of Records to Avoid Locking by Reading-Only Transactions”, XP 000393583, IBM Almaden Research Center, Dated Feb. 6, 1992, 11 pages. |
Rajeev Kumar et al., Oracle DBA, A Helping Hand, Container Database and Pluggable Database (CDB & PDB), retrieved from the internet on Dec. 4, 2013, 2 pages. |
Preimesberger, Chris, “Oracle Profits Up, but Revenues Slip” Oracle, dated Sep. 20, 2012, 2 pages. |
Oracle Help Center, “Database 2 Day + Data Replication and Integration Guide”, 3 Accessing and Modifying Information in Multiple Databases, dated 2016, 14 pages. |
Oracle Base, Multitenant: Create and Configure a Pluggable Database (PDB) in Oracle Database 12c Release 1 (12.1), dated Jan. 8, 2014, 16 pages. |
Muhammad Anwar, “How to Install Oracle 12c Multitenant Pluggable Database”, Dated Feb. 24, 2012, 27 pages. |
Garcia-Molina et al., “Database System Implementation”, dated Jan. 1, 2000, 84 pages. |
Francisco Munoz et al., “Oracle Database 12c Backup and Recovery Survival Guide”, dated Sep. 24, 2013, 8 pages. |
Dominic Betts et al., “Developing Multi-Tenant Applications for the Cloud”, 3rd Edition, Microsoft, 2012, 246 pages. |
Das et al., “Albatross: Lightweight Elasticity in Shared Storage Databases for the Cloud Using Live Data Migration”, Proceedings of the VLDB Endowment, vol. 4 No. 8 Copyright, dated 2011, 12 pages. |
Anonymous: “Oracle-Base—Multitenant: Overview of Container Databases (CDB) and Pluggable Databases (PDB)”, dated Mar. 3, 2014, 4 pages. |
Anonymous, :An Oracle White Paper Oracle Database Appliance: Migration Strategies, dated Jun. 2012, 14 pages. |
Zhe, Li, et al., “PERF join: an alternative to two-way semijoin and Bloomjoin” Proceedings of the 1995 ACM, New York. NY, US., 1995, pp. 187-144. |
Shao et al., “Clotho: Decoupling Memory Page Layout from Storage Organization”, Proceedings of the 30th VLDB Conference, Toronto, Canada, 2004, 12 pages. |
Schaffner et al., “A Hybrid Row-Column OLTP Database Architecture for Operational Reporting”, dated Aug. 24, 2008, 14 pages. |
Ramamurthy, Ravishankar, “A Case for Fractured Mirrors” Proceedings of the 28th VLDB Conference, dated, 2002, 12 pages. |
Phipps, Colin:, “Mapping Deflated Files”, Internet Article, dated Jan. 6, 2013, http://zsync.moria.org.uk/paper/ch03s02.html, 3 pages. |
Oracle Database Administrator's Guide, 11g Release 2 (11.2), Chapter 26, Feb. 2010, 54 pages. http://download.oracle.com/docs/cd/E11882_01/server.112/e10595.pdf. |
Oracle Database Administrator's Guide, 10g Release 2 (10.2), Chapter 24, May 2006, 34 pages. http://download.oracle.com/docs/cd/B19306_01/server.102/b14231.pdf. |
O'Neil, P., et al., “Multi-table joins through bitmapped join indices”, SIGMOD Record, ACM, New York, NY, US, vol. 24, No. 3, Sep. 1, 1995, pp. 8-11, ISSN: 0163-5808. |
Nirmesh, Malviya, “Recovery Algorithms for In-Memory OLTP Databases”, Master of Science Thesis, dated Jul. 1, 2012, 66 pages. |
Loizos, M., et al., “Improving distributed join efficiency with extended bloom filter operations”, Advanced Networking and Applications, 2007. AINA '07., 21st international Conf. IEEE, May 1, 2007. |
Mackert, F. Lothar et al., “R* optimizer validation and performance evaluation for local queries” SIGMOD Record, ACM, New York, NY, US., vol. 15, No. 2, Jun. 1, 1986, pp. 84-95, ISSN: 0163-5808. |
IBM, “A Scheduling Algorithm for Processing Mutually Exclusive Workloads in a Multi-System Configuration”, dated Aug. 19, 2002, IEEE, 3 pages. |
Zhang Ho et al., “In-Memory Big Data Management and Processing: A Survery”, IEEE Transactions on Knowledge and Data Engineering, vol. 27, No. 7, dated Jul. 31, 2015, 30 pages. |
Vishal Sikka et al., “Efficient Transaction Processing in SAP Hana Database”, Proceedings of the 2012, International Conference on Management of Data, dated Jan. 31, 2012, 12 pages. |
Farber et al., “SAP HANA Database—Data Management for Modern Business Applications”, SIGMOD Record, dated Dec. 2011, vol. 40, No. 4, 8 pages. |
Khalid Sayood:, “Introduction to data Compression”, Morgan Kaufmann Publisher, dated Dec. 1996, 4 pages. |
Nadimpalli, Rajeev, “How to Run Two or More Databases in Different Time Zones on the Same Machine”, dated May 2002, 7 pages. |
Antoni Cau, et al., “Specifying Fault Tolerance within Stark's Formalism,” 1993, IEEE, pp. 392-401. |
IBM Corp., “IBM OS/2 Extended Edition Configuration,” Feb. 1990, IBM Technical Disclosure Bulletin, vol. 32, No. 9B, pp. 446-451. |
Alapati, S., Backing Up Databases. In: Expert Oracle Database 11g Administration, Apress, dated 2009, pp. 1-70. |
Oracle, “Oracle Data Guard”, Concepts and Administration 12c Release 1 (12.1), dated Nov. 2015, 50 pages. |
Oracle, “Oracle Active Data Guard”, Real-Time Protection and Availability, Oracle White Paper, dated Oct. 2015, 22 pages. |
Oracle, “Maximum Availability Architecture”, Oracle Best Practices for High Availability, dated Sep. 2011, 42 pages. |
Werner Vogels, “Eventually Consistent”, CACM, dated Dec. 19, 2007, 4 pages. |
V Sikka et al., Efficient Transaction Processing in SAP HANA Database: the End of a Column Store Myth, SIGMOD dated 2012, 11 pages. |
Oracle® Flashback Technologies, http://www.oracle.com/technetwork/database/features/availability/flashbackoverview-082751.html, last viewed on Dec. 5, 2019, 3 pages. |
Oracle® TimesTen In-Memory Database and TimesTen Application-Tier Database Cache, www.oracle.com/technetwork/database/databasetechnologies/timesten/overview/index.html, viewed on Dec. 5, 2019, 1pg. |
Oracle Help Center, Oracle® TimesTen Application-Tier Database Cache User's Guide: Read-only Cache Groups, http://stdoc.us.oracle.com/12/12102/TTCAC/define.htm#TTCAC211, viewed on Dec. 5, 2019, 10 pages. |
Ma et al., On benchmarking online social media analytical queries. In First International Workshop on Graph Data Management Experiences and Systems (GRADES '13). ACM, Article, dated 2013, 7 pages. |
Labrinidis et al., “Balancing Performance and Data Freshness in Web Database Servers”, VLDB dated 2003, 12 pages. |
Jeff Erickson, In-Memory Acceleration for the Real-Time Enterprise,http://www.oracle.com/us/corporate/features/database-in-memoryoption/index.html, last viewed on Dec. 5, 2019, 4 pages. |
Gary Marchionini, Exploratory Search: From Finding to Understanding. Communications. ACM 49, 4, dated Apr. 2006, pp. 41-46. |
Number | Date | Country | |
---|---|---|---|
20180157710 A1 | Jun 2018 | US |