Abstract: Techniques are provided for handling distributed transactions in shared-nothing database systems where one or more of the nodes have access to a shared persistent storage. Rather than coordinate the distributed transaction using a two-phase commit protocol, the coordinator of the distributed transaction uses a one-phase commit protocol with those participants that have access to the transaction status information maintained by the coordinator. The transaction status information may reside, for example, in the redo log of the coordinator. In the case that the coordinator fails, those participants can determine the state of the distributed transaction based on information stored on the shared disk. In addition, the coordinator is able to determine whether it is possible to commit the distributed transaction based on information that is stored on the shared disk by the participants, without those participants entering a formal “prepared” state.

Abstract: An improved method, mechanism, and system for implementing, generating, and maintaining records, such as redo records and redo logs in a database system, are disclosed. Multiple sets of records may be created and combined into a partially ordered (or non-ordered) group of records, which are later collectively ordered or sorted as needed to create an fully ordered set of records. With respect to a database system, redo generation bottleneck is minimized by providing multiple in-memory redo buffers that are available to hold redo records generated by multiple threads of execution. When the in-memory redo buffers are written to a persistent storage medium, no specific ordering needs to be specified with respect to the redo records from the different in-memory redo buffers. While the collective group of records may not be ordered, the written-out redo records may be partially ordered based upon the ordered redo records from within individual in-memory redo buffers.

Abstract: Various techniques are described for improving the performance of a shared-nothing database system in which at least two of the nodes that are running the shared-nothing database system have shared access to a disk. Specifically, techniques are provided for changing the ownership of data in a shared-nothing database dynamically, based on factors such as which node would be the most efficient owner relative to the performance of a particular operation. Once determined, the ownership of the data may be changed permanently to the new owner, or temporarily for the duration of the particular operation.

Abstract: Various techniques are described for improving the performance of a shared-nothing database system in which at least two of the nodes that are running the shared-nothing database system have shared access to a disk. Specifically, techniques are provided for recovering the data owned by a failed node using multiple recovery nodes operating in parallel. The data owned by a failed node is reassigned to recovery nodes that have access to the shared disk on which the data resides. The recovery logs of the failed node are read by the recovery nodes, or by a coordinator process that distributes the recovery tasks to the recovery nodes.

Abstract: Various techniques are described for improving the performance of a multiple node system by allocating, in two or more nodes of the system, partitions of a shared cache. A mapping is established between the data items managed by the system, and the various partitions of the shared cache. When a node requires a data item, the node first determines which partition of the shared cache corresponds to the required data item. If the data item does not currently reside in the corresponding partition, the data item is loaded into the corresponding partition even if the partition does not reside on the same node that requires the data item. The node then reads the data item from the corresponding partition of the shared cache.

Abstract: Techniques are provided for handling distributed transactions in shared-nothing database systems where one or more of the nodes have access to a shared persistent storage. Rather than coordinate the distributed transaction using a two-phase commit protocol, the coordinator of the distributed transaction uses a one-phase commit protocol with those participants that have access to the transaction status information maintained by the coordinator. The transaction status information may reside, for example, in the redo log of the coordinator. In the case that the coordinator fails, those participants can determine the state of the distributed transaction based on information stored on the shared disk. In addition, the coordinator is able to determine whether it is possible to commit the distributed transaction based on information that is stored on the shared disk by the participants, without those participants entering a formal “prepared” state.

Abstract: Various techniques are described for improving the performance of a shared-nothing database system in which at least two of the nodes that are running the shared-nothing database system have shared access to a disk. Specifically, techniques are provided for changing the ownership of data in a shared-nothing database without changing the location of the data on persistent storage. Because the persistent storage location for the data is not changed during a transfer of ownership of the data, ownership can be transferred more freely and with less of a performance penalty than would otherwise be incurred by a physical relocation of the data. Various techniques are also described for providing fast run-time reassignment of ownership. Because the reassignment can be performed during run-time, the shared-nothing system does not have to be taken offline to perform the reassignment.

Abstract: A method and system for propagating commit times between a plurality of database servers that have access to a common database is provided. According to the method, each database server is associated with a logical clock. In response to initiating a commit of a transaction executing on a database server, a commit time for the transaction is determined and broadcast to one or more other database servers. According to one aspect, upon receiving the commit time at the one or more other database servers, the database servers compare the transmitted commit time to the time indicated by their logical clock. If the commit time is greater than the time indicated by their logical clock, the database server sets its logical time to reflect a time that is at least as recent as the time reflected by the transmitted commit time.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.

Abstract: A method and mechanism is described for reliably transmitting messages over an unreliable transport mechanism. A sender transmits a first message over an unreliable mechanism to a receiver, and a second message that identifies the first is transported over a reliable transport mechanism to the receiver. When the receiver receives the second message, the receiver determines whether it has received the first message. If not, the receiver requests retransmission of the first message.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.

Abstract: A method and mechanism is described for reliably transmitting messages over an unreliable transport mechanism. A sender transmits a first message over an unreliable mechanism to a receiver, and a second message that identifies the first is transported over a reliable transport mechanism to the receiver. When the receiver receives the second message, the receiver determines whether it has received the first message. If not, the receiver requests retransmission of the first message.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.

Abstract: Techniques are provided for determining which data item version to supply to a query. According to the techniques, the determination is made by associating a new field, which indicates the time a data item version was current, with each data item version; associating a new field with each query, which indicates the last change that the query must see made by the transaction to which the query belongs; and determining which data item version to use to answer the query based, in part, on a comparison between the values of the two new fields.

Abstract: A method and apparatus are provided for improving the performance associated with transferring a data item and obtaining a lock in a multi-node system by interpreting the block transfer message as a lock grant message. Typically when a Holder of a data item transfers a data item (e.g. block) to a Requestor of that data item, the Holder will down-convert its lock for that data item and send a message to the Master of this data item indicating that a down-convert has been performed. Subsequently, the Master sends a lock grant message to the Requestor of the data item to inform the Requestor that it has been granted a lock for the data item. By interpreting the block transfer message as a lock grant message, the down-convert message and the lock grant message can be eliminated, which results in improved performance.

Abstract: Techniques are provided for managing caches in a system with multiple caches that may contain different copies of the same data item. Specifically, techniques are provided for coordinating the write-to-disk operations performed on such data items to ensure that older versions of the data item are not written over newer versions, and to reduce the amount of processing required to recover after a failure. Various approaches are provided in which a master is used to coordinate with the multiple caches to cause a data item to be written to persistent storage. Techniques are also provided for managing checkpoints associated with the caches, where the checkpoints are used to determine the position at which to begin processing recovery logs in the event of a failure.

Abstract: Techniques are provided for managing caches in a system with multiple caches that may contain different copies of the same data item. Specifically, techniques are provided for coordinating the write-to-disk operations performed on such data items to ensure that older versions of the data item are not written over newer versions, and to reduce the amount of processing required to recover after a failure. Various approaches are provided in which a master is used to coordinate with the multiple caches to cause a data item to be written to persistent storage. Techniques are also provided for managing checkpoints associated with the caches, where the checkpoints are used to determine the position at which to begin processing recovery logs in the event of a failure.

Abstract: A method and apparatus are provided for transferring a resource from the cache of one database server to the cache of another database server without first writing the resource to disk. When a database server (Requestor) desires to modify a resource, the Requestor asks for the current version of the resource. The database server that has the current version (Holder) directly ships the current version to the Requestor. Upon shipping the version, the Holder loses permission to modify the resource, but continues to retain the resource in memory. When the retained version of the resource, or a later version thereof, is written to disk, the Holder can discard the retained version of the resource. Otherwise, the Holder does not discard the retained version. Using this technique, single-server failures are recovered without having to merge the recovery logs of the various database servers that had access to the resource.